I finally managed to have a small zfsroot on a 1 gig disk... with /usr, /var, /export/home on a secondary pool.
If you follow the zfs boot manual install instruction or use the 'zfs-actual-root-install.sh' script, make sure of the following: 1/ Do not create your zfs boot root right after your installation before you reboot. It will fail if you are in 32 bit mode and your system is a 64 bit machine. he screen is flooded with "init(1M) exited on fatal signal 9. See: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6423745 2/ Do not create your zfs boot root from another zfs root, it will fail too. the screen is flooded with "init(1M) exited on fatal signal 9" 3/ Do not create your zfs boot root from failsafe, again it will fail. (see log below) 4/ Create /usr/lib in your root partition and cp -p /usr/lib/libdiskmgt.so* to /zfsroot/usr/lib, make sure you have /var/run, /opt 5/ add the following entry to your /etc/vfstab : datapool/usr - /usr zfs - yes - datapool/var - /var zfs - yes - datapool/opt - /opt zfs - yes - As I said it's actually quite straightforward if you can avoid the above issues; Murphy's law chill, I hit each of the above problems in a row and when I asked for help Lori Alt went: "oh no /usr/lib/libdiskmgt.so is not a broken dependency... oh no it is not possible to have a separate /usr by "design". That wasn't really useful, was it? It seems there is also a bug with failsafe related to zfs boot, once I booted into failsafe to create the different partition and imported my rootpool and datapool with zpool import -f tank and when I finished I used 'zpool export' to umount everything. When I rebooted my zfs boot root, it panicked (see log below). I rebooted to my ufs root , imported my pools and my zfs boot was working again. Can someone look into that? module /platform/i86pc/kernel/amd64/unix: text at [0xfffffffffb800000, 0xfffffffffb8f5e63] data at 0xfffffffffbc00000 module /kernel/amd64/genunix: text at [0xfffffffffb8f5e70, 0xfffffffffbb18797] data at 0xfffffffffbc710c0 Loading kmdb... module /kernel/misc/amd64/kmdbmod: text at [0xfffffffffbb187a0, 0xfffffffffbba432f] data at 0xfffffffffbcd9040 module /kernel/misc/amd64/ctf: text at [0xfffffffffbba4330, 0xfffffffffbbae22f] data at 0xfffffffffbcf4358 SunOS Release 5.11 Version snv_73 64-bit Copyright 1983-2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. features: 10f7eff<cpuid,cx16,sse3,nx,asysc,sse2,sse,sep,pat,cx8,pae,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg> mem = 1048124K (0x3ff8f000) cpu0: initialized cpu module 'cpu.generic' root nexus = i86pc pseudo0 at root pseudo0 is /pseudo scsi_vhci0 at root scsi_vhci0 is /scsi_vhci isa0 at root pseudo-device: ppm0 ppm0 is /pseudo/[EMAIL PROTECTED] pci0 at root: space 0 offset 0 pci0 is /[EMAIL PROTECTED],0 /[EMAIL PROTECTED],0/pci1000,[EMAIL PROTECTED] (mpt0): Rev. 1 LSI, Inc. 1030 found. /[EMAIL PROTECTED],0/pci1000,[EMAIL PROTECTED] (mpt0): mpt0 Firmware version v1.3.41.32 (?) /[EMAIL PROTECTED],0/pci1000,[EMAIL PROTECTED] (mpt0): mpt0: IOC Operational. PCI-device: pci1000,[EMAIL PROTECTED], mpt0 mpt0 is /[EMAIL PROTECTED],0/pci1000,[EMAIL PROTECTED] sd2 at mpt0: target 1 lun 0 sd2 is /[EMAIL PROTECTED],0/pci1000,[EMAIL PROTECTED]/[EMAIL PROTECTED],0 /[EMAIL PROTECTED],0/pci1000,[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd2) online panic[cpu0]/thread=fffffffffbc25ba0: BAD TRAP: type=d (#gp General protection) rp=fffffffffbc46280 addr=f000ff53f000ff00 #gp General protection addr=0xf000ff53f000ff00 pid=0, pc=0xfffffffffba61bfd, sp=0xfffffffffbc46370, eflags=0x10286 cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6b8<xmme,fxsr,pge,pae,pse,de> cr2: 0 cr3: 2c00000 cr8: c rdi: fffffffffbccbc48 rsi: f000ff53f00100e0 rdx: c0 rcx: 60 r8: 0 r9: 0 rax: fffffffffbc25ba0 rbx: 0 rbp: fffffffffbc463b0 r10: ffffff00c6545fb8 r11: 0 r12: fffffffffbccbc48 r13: fffffffffbc287e0 r14: f000ff53f00100e0 r15: f000ff53f000ff00 fsb: 200000000 gsb: fffffffffbc26fd0 ds: 0 es: 0 fs: 0 gs: 0 trp: d err: 0 rip: fffffffffba61bfd cs: 30 rfl: 10286 rsp: fffffffffbc46370 ss: 38 fffffffffbc46160 unix:die+ea () fffffffffbc46270 unix:trap+3c0 () fffffffffbc46280 unix:_cmntrap+e9 () fffffffffbc463b0 genunix:turnstile_interlock+1d () fffffffffbc46450 genunix:turnstile_block+213 () fffffffffbc464c0 unix:mutex_vector_enter+340 () fffffffffbc46550 genunix:lookuppnat+bc () fffffffffbc466e0 genunix:vn_createat+107 () fffffffffbc46860 genunix:vn_openat+14d () fffffffffbc468b0 genunix:vn_open+2b () fffffffffbc46a10 zfs:spa_config_sync+134 () fffffffffbc46a80 zfs:spa_open_common+22e () fffffffffbc46ab0 zfs:spa_open+1c () fffffffffbc46b20 zfs:dsl_dsobj_to_dsname+3f () fffffffffbc46b70 zfs:parse_bootpath+68 () fffffffffbc46bc0 zfs:zfs_mountroot+e6 () fffffffffbc46be0 genunix:fsop_mountroot+1a () fffffffffbc46c10 genunix:rootconf+be () fffffffffbc46c60 genunix:vfs_mountroot+65 () fffffffffbc46c90 genunix:main+ce () fffffffffbc46ca0 unix:_locore_start+92 () panic: entering debugger (no dump device, continue to reboot) On 13/10/2007, at 4:03 PM, Torsten Paul Eichstädt wrote: I'm not an expert but in /etc/system there is an entry for root-dev (or root-device?). E.g. the Solaris Volume Manager SVM uses this to mount the /dev/md/dsk/* device at boot. IMHO this is equivalent to Linux pivot-root. When you put the root FS on ZFS, beware that all the libraries needed are already there. I was trapped by this some time ago, some libs were on /usr :/ Now I'm fine with UFS root on SVM mirror and /var on ZFS RAID 0+1 (mountpoint=legacy). FYI I'm on SPARC. Cheers, Paul This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss