/var has no problem being on a separate pool. Any reason why it assumes that root and /usr are on the same pool?
You're forcing me to sacrifice one or two disk and SATA/IDE port to support "zfs boot" when a 1 gig flashdisk costs less than 10$. / would fit nicely on it, /usr doesn't. I guess I'll have to track down all these broken dependencies myself or wait until 8 gig flashdisk are stocked again. On 05/10/2007, at 10:52 PM, Lori Alt wrote: > Kugutsumen wrote: >> Thanks, this is really strange. >> In your particular case you have /usr on the same pool as your >> rootfs and I guess that's why it is working for you. >> >> Alll my attempts with b64, b70 and b73 failed if /usr is on a >> separate pool. >> > > I'm not surprised that having /usr in a separate pool failed. > The design of zfs boot largely assumes that root, /usr, and > /var are all on the same pool, and it is unlikely that we would > do the work to support any other configuration any time soon. > > Lori > >> >> >>> Hi Kugutsumen, >>> >>> Not sure abt the bugs, I follow instruction at http:// >>> www.opensolaris.org/os/community/zfs/boot/zfsboot-manual >>> and create separate /usr, /opt and /var filesystem. >>> >>> Here is the vfstab: >>> #device device mount FS fsck >>> mount mount >>> #to mount to fsck point type pass >>> at boot options >>> # >>> fd - /dev/fd fd - no - >>> /proc - /proc proc - no - >>> /dev/dsk/c0d0s1 - - swap - no - >>> /devices - /devices devfs - no - >>> sharefs - /etc/dfs/sharetab sharefs - no - >>> ctfs - /system/contract ctfs - no - >>> objfs - /system/object objfs - no - >>> swap - /tmp tmpfs - yes - >>> /dev/dsk/c0d0p0:1 /dev/rdsk/c0d0p0:1 /windows/C >>> pcfs 2 yes >>> - >>> /dev/dsk/c0d0p0:2 /dev/rdsk/c0d0p0:2 /windows/D >>> pcfs 2 yes >>> - >>> /dev/dsk/c0d0p0:3 /dev/rdsk/c0d0p0:3 /windows/E >>> pcfs 2 yes >>> - >>> rootpool/rootfs - / zfs - no - >>> rootpool/rootfs/usr - /usr zfs - no - >>> rootpool/rootfs/var - /var zfs - no - >>> rootpool/rootfs/opt - /opt zfs - yes - >>> >>> The reason why I separate /usr, /opt, /var because I want to >>> compress them: >>> bash-3.00$ zfs get compressratio rootpool/rootfs/usr >>> NAME PROPERTY VALUE SOURCE >>> rootpool/rootfs/usr compressratio 1.65x - >>> bash-3.00$ zfs get compressratio rootpool/rootfs/var >>> NAME PROPERTY VALUE SOURCE >>> rootpool/rootfs/var compressratio 2.10x - >>> bash-3.00$ zfs get compressratio rootpool/rootfs/opt >>> NAME PROPERTY VALUE SOURCE >>> rootpool/rootfs/opt compressratio 1.66x >>> >>> My entire bootdisk only need 2.5GB (entire distribution): >>> bash-3.00$ zfs list rootpool/rootfs >>> NAME USED AVAIL REFER MOUNTPOINT >>> rootpool/rootfs 2.58G 1.85G 351M legacy >>> >>> To be able to rollback you need to create another boot >>> environment using snapshot and clone. I named the new zfs root >>> filesystem as rootpool/tx (planned to install Solaris trusted >>> extension on the new boot environment). >>> >>> bash-3.00$ zfs list -r rootpool/tx >>> NAME USED AVAIL REFER MOUNTPOINT >>> rootpool/tx 57.2M 1.85G 343M legacy >>> rootpool/tx/opt 30K 1.85G 230M legacy >>> rootpool/tx/usr 198K 1.85G 1.79G legacy >>> rootpool/tx/var 644K 1.85G 68.1M legacy >>> >>> If you want to rollback you need to boot to the clone BE then >>> rollback. >>> >>> Rgds, >>> Andre W. >>> >>> Kugutsumen wrote: >>> >>>> Please do share how you managed to have a separate ZFS /usr >>>> since b64; there are dependencies to /usr and they are not >>>> documented. - kv doesn't help too. I tried added /usr/lib/ >>>> libdisk* to a /usr/lib dir on the root partition and failed. >>>> Jurgen also pointed that there are two related bugs already >>>> filed: Bug ID 6570056 Synopsis / sbin/zpool should not link to >>>> files in /usr/lib http:// bugs.opensolaris.org/bugdatabase/ >>>> view_bug.do?bug_id=6570056 Bug ID 6494840 Synopsis libzfs >>>> should dlopen libiscsitgt rather than linking to it http:// >>>> bugs.opensolaris.org/bugdatabase/view_bug.do? bug_id=6494840 I >>>> can do a snapshot on bootroot too ... after I tried to do a >>>> rollback from failsafe I couldn't boot anymore, probably >>>> because there was no straightforward way to rebuild the boot >>>> archive. Regarding compression, if I am not mistaken, grub >>>> cannot access files that are compressed. Regards, K. On >>>> 05/10/2007, at 5:55 AM, Andre Wenas wrote: >>>> >>>>> Hi, Using bootroot I can do seperate /usr filesystem since b64. >>>>> I can also do snapshot, clone and compression. Rgds, Andre W. >>>>> Kugutsumen wrote: >>>>> >>>>>> Lori Alt told me that mountrount was a temporary hack until >>>>>> grub could boot zfs natively. Since build 62, mountroot >>>>>> support was dropped and I am not convinced that this is a >>>>>> mistake. Let's compare the two: Mountroot: Pros: * can have >>>>>> root partition on raid-z: YES * can have root partition on >>>>>> zfs stripping mirror: YES * can have usr partition on >>>>>> separate ZFS partition with build < 72 : YES * can snapshot >>>>>> and rollback root partition: YES * can use copies on root >>>>>> partition on a single root disk (e.g. a laptop ): YES * can >>>>>> use compression on root partition: YES Cons: * grub native >>>>>> support: NO (if you use raid-z or stripping mirror, you will >>>>>> need to have a small UFS partition to bootstrap the system, >>>>>> but you can use a small usb stick for that purpose.) New and >>>>>> "improved" *sigh* bootroot scheme: Pros: * grub native >>>>>> support: YES Cons: * can have root partition on raid-z: NO * >>>>>> can have root partition on zfs stripping mirror: NO * can use >>>>>> copies on root partition on a single root disk (e.g. a >>>>>> laptop ): NO * can have usr partition on separate ZFS >>>>>> partition with build < 72 : NO * can snapshot and rollback >>>>>> root partition: NO * can use compression on root partition: >>>>>> NO * No backward compatibility with zfs mountroot. Why did we >>>>>> completely drop support for the old mountroot approach which >>>>>> is so much more flexible? Kugutsumen >>>>>> _______________________________________________ zfs- discuss >>>>>> mailing list zfs-discuss@opensolaris.org http:// >>>>>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >>>>>> >>>> _______________________________________________ zfs-discuss >>>> mailing list zfs-discuss@opensolaris.org http:// >>>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >>>> >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss