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
Remember that you have to maintain an entirely separate slice with yet another boot environment. This causes huge amounts of complexity in terms of live upgrade, multiple BE management, etc. The old mountroot solution was useful for mounting ZFS root, but completely unmaintainable from an installation and upgrade perspective. It was dropped because we could not possibly develop installation, packaging, and upgrade software that would work across multiple BEs under such a scheme. - Eric On Thu, Oct 04, 2007 at 11:27:46PM +0700, 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 > > Why did we completely drop support for the old mountroot approach > which is so much more flexible?-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
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 at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >
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 at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >>> >>> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20071005/0430cb9d/attachment.html>
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. On 05/10/2007, at 4:10 PM, Andre Wenas wrote:> 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 at opensolaris.org http:// >>>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >> _______________________________________________ zfs-discuss >> mailing list zfs-discuss at opensolaris.org http:// >> mail.opensolaris.org/mailman/listinfo/zfs-discuss >
ZFS boot is one of the best usage of ZFS for me. I can create more then 10 boot environment, rollback or destroy if necessary. Not afraid of bfu anymore or patching or any other software installation. If bfu breaks the OS, just rollback as simple as that. Rgds, Andre W. 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. > > > On 05/10/2007, at 4:10 PM, Andre Wenas wrote: > >> 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 at opensolaris.org >>>>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >>> _______________________________________________ zfs-discuss mailing >>> list zfs-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >
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 at opensolaris.org http:// >>>>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >>>>> >>> _______________________________________________ zfs-discuss >>> mailing list zfs-discuss at opensolaris.org http:// >>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >>> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
> Regarding compression, if I am not mistaken, grub > cannot access files that are compressed.There was a bug where grub was unable to access files on zfs that contained holes: Bug ID 6541114 Synopsis GRUB/ZFS fails to load files from a default compressed (lzjb) root http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6541114 That has been fixed in snv_71. The description text is misleading, there was no issue with reading lzjb compressed files, the bug occurred when reading "hole" blocks from a zfs file. Grub is unable to read from gzip compressed zfs filesystems, though: Bug ID 6538017 Synopsis ZFS boot to support gzip decompression http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6538017 This message posted from opensolaris.org
/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 at opensolaris.org http:// >>>>>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >>>>>> >>>> _______________________________________________ zfs-discuss >>>> mailing list zfs-discuss at opensolaris.org http:// >>>> mail.opensolaris.org/mailman/listinfo/zfs-discuss >>>> >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >
> I''m not surprised that having /usr in a separate pool failed.while this is discouraging, (I have several b62 machines with root mirrored and /usr on raidz) if booting from raidz is a pri, and comes soon, at least I''d be happy :-) Rob
Same here, if zfs boot support raidz then my problems will be solved. On 05/10/2007, at 11:27 PM, Rob Logan wrote:>> I''m not surprised that having /usr in a separate pool failed. > > while this is discouraging, (I have several b62 machines with > root mirrored and /usr on raidz) if booting from raidz > is a pri, and comes soon, at least I''d be happy :-) > > Rob > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Lori Alt wrote:> 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.This seems, uhm, undesirable. I could understand if the initial *implementation* chose to make these simplifying assumptions, but if the *architecture* or *design* of the feature requires this, then, IMO, this project needs a TCR to not be done that way. Certainly, many of us will be satisfied with all-in-one pool, just as we are today with all all-in-one filesystem, so this makes sense as a first step. But, there needs to be the presumption that the next steps towards multiple pool support are possible without having to re-architect or re-design the whole zfs boot system. -John
John Plocher wrote:> Lori Alt wrote: >> 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. > > > This seems, uhm, undesirable. I could understand if the initial > *implementation* chose to make these simplifying assumptions, but > if the *architecture* or *design* of the feature requires this, > then, IMO, this project needs a TCR to not be done that way.It''s not inherent in the design of zfs boot. It''s more a matter of the current implementation. For example, install and liveupgrade (and future boot-environment management tools) will get a fair amount of mileage from the fact that you can set a mount point at the top of a boot-environment dataset hierarchy and all of the subordinate file systems in the boot environment will inherit it. That kind of thing will only work if the file system composing the BE are in the same pool. In the initial release, the early SMF scripts that mount root, /usr, var, etc. assume that they are in a well-defined hierarchy: <pool>/<be-name> <pool>/<be-name>/usr <pool>/<be-name>/var such that once the <pool>/<be-name> is known, all of the other file systems can be found relative to it. This only works if they are in the same dataset.> > Certainly, many of us will be satisfied with all-in-one pool, > just as we are today with all all-in-one filesystem, so this > makes sense as a first step. But, there needs to be the > presumption that the next steps towards multiple pool support > are possible without having to re-architect or re-design the > whole zfs boot system. >No, re-architecting should not be necessary. Lori
Nicolas Williams
2007-Oct-05 18:41 UTC
[zfs-discuss] ZFS Mountroot and Bootroot Comparison
On Fri, Oct 05, 2007 at 10:44:21AM -0700, John Plocher wrote:> Lori Alt wrote: > > 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. > > > This seems, uhm, undesirable. I could understand if the initial > *implementation* chose to make these simplifying assumptions, but > if the *architecture* or *design* of the feature requires this, > then, IMO, this project needs a TCR to not be done that way. > > Certainly, many of us will be satisfied with all-in-one pool, > just as we are today with all all-in-one filesystem, so this > makes sense as a first step. But, there needs to be the > presumption that the next steps towards multiple pool support > are possible without having to re-architect or re-design the > whole zfs boot system.I''m curious as to why you think this (note: I''ve nothing to do with ZFS development). I understand the need for separate / and /usr in some cases, but how does separate / and /usr add value in a ZFS bootroot environment? Is it because one might like to have a very tiny pool (e.g., on a USB flashdrive) to contain / and a larger one to contain /usr? Thinking of ZFS crypto, it might, since one might put / in cleartext on a small capacity USB flashdrive, say and keep everything else encrypted. But one should want ZFS crypto to protect / as well as everything else (/usr and homedirs), and I would hope that when ZFS crypto gets around to meeting ZFS bootroot then we''ll able to do just that. So assuming that ZFS crypto and bootroot will eventually play very well together, what value is there to having / and /usr on separate pools, or even separate datasets, in a ZFS bootroot environment? Nico --
On Fri, Oct 05, 2007 at 01:41:32PM -0500, Nicolas Williams wrote:> > Certainly, many of us will be satisfied with all-in-one pool, > > just as we are today with all all-in-one filesystem, so this > > makes sense as a first step. But, there needs to be the > > presumption that the next steps towards multiple pool support > > are possible without having to re-architect or re-design the > > whole zfs boot system. > > I''m curious as to why you think this (note: I''ve nothing to do with ZFS > development). I understand the need for separate / and /usr in some > cases, but how does separate / and /usr add value in a ZFS bootroot > environment? Is it because one might like to have a very tiny pool > (e.g., on a USB flashdrive) to contain / and a larger one to contain > /usr? > > Thinking of ZFS crypto, it might, since one might put / in cleartext on > a small capacity USB flashdrive, say and keep everything else encrypted. > But one should want ZFS crypto to protect / as well as everything else > (/usr and homedirs), and I would hope that when ZFS crypto gets around > to meeting ZFS bootroot then we''ll able to do just that.I wonder how much this would change if a functional "pivot-root" mechanism were available. It be handy nice to boot from flash, import a pool, then make that the running root. Does anyone know if that''s a target of any OpenSolaris projects? -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
Nicolas Williams
2007-Oct-05 19:01 UTC
[zfs-discuss] ZFS Mountroot and Bootroot Comparison
On Fri, Oct 05, 2007 at 06:54:21PM +0000, A Darren Dunham wrote:> I wonder how much this would change if a functional "pivot-root" > mechanism were available. It be handy nice to boot from flash, import a > pool, then make that the running root. > > Does anyone know if that''s a target of any OpenSolaris projects?That''s pretty much what the ZFS mountroot effort was about, and it has been replaced with ZFS bootroot instead. But I suspect you mean something more general than a ZFS root scenario, something more Linux-like (where even user-land processes can run prior to switching to the real root and starting init). Nico --
Nicolas Williams wrote:> I''m curious as to why you think thisThe characteristics of /, /usr and /var are quite different, from a usage and backup requirements perspective: / is read-mostly, but contains critical config data. /usr is read-only, and /var (/var/mail, /var/mysql, ...) can be high volume read/write. A scenerio with / on a pair of mirrored USB sticks, /usr on DVD media with with RAM-based cache and /var & /export/home on a large wide striped/mirrored/raided pool of its own isn''t too far fetched an idea. -John
On Fri, Oct 05, 2007 at 02:01:29PM -0500, Nicolas Williams wrote:> On Fri, Oct 05, 2007 at 06:54:21PM +0000, A Darren Dunham wrote: > > I wonder how much this would change if a functional "pivot-root" > > mechanism were available. It be handy nice to boot from flash, import a > > pool, then make that the running root. > > > > Does anyone know if that''s a target of any OpenSolaris projects? > > That''s pretty much what the ZFS mountroot effort was about, and it has > been replaced with ZFS bootroot instead. But I suspect you mean > something more general than a ZFS root scenario, something more > Linux-like (where even user-land processes can run prior to switching to > the real root and starting init).Perhaps. My thoughts were really wondering about something more general than ZFS, rather than any ZFS-specific solutions. -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
Nicolas Williams wrote:> On Fri, Oct 05, 2007 at 10:44:21AM -0700, John Plocher wrote: > >> Lori Alt wrote: >> >>> 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. >>> >> This seems, uhm, undesirable. I could understand if the initial >> *implementation* chose to make these simplifying assumptions, but >> if the *architecture* or *design* of the feature requires this, >> then, IMO, this project needs a TCR to not be done that way. >> >> Certainly, many of us will be satisfied with all-in-one pool, >> just as we are today with all all-in-one filesystem, so this >> makes sense as a first step. But, there needs to be the >> presumption that the next steps towards multiple pool support >> are possible without having to re-architect or re-design the >> whole zfs boot system. >> > > I''m curious as to why you think this (note: I''ve nothing to do with ZFS > development). I understand the need for separate / and /usr in some > cases, but how does separate / and /usr add value in a ZFS bootroot > environment? Is it because one might like to have a very tiny pool > (e.g., on a USB flashdrive) to contain / and a larger one to contain > /usr? >Not a sufficient reason. Crypto policy is a data set (file system/zvol) policy not a storage pool policy. The question of why to have different storage pools has still not been satisfactorily addressed. Methinks people are still confusing pools and data sets. -- richard
>> >> The question of why to have different storage pools has still not >> been >> satisfactorily addressed. Methinks people are still confusing >> pools and >> data sets. >> > > Is it possible to create a pool called rootpool made up for example > of mirror c1t0d0 c2t0d0 > then add 4 disks in raidz2 to the same pool and create a /usr > filesystem using only the raidz2 portion of the pool? > > >
> Is it possible to create a pool called rootpool made up for example > of mirror c1t0d0 c2t0d0 > then add 4 disks in raidz2 to the same pool and create a /usr > filesystem using only the raidz2 portion of the pool?Not usefully. You cannot segregate the location of data or datasets within pools they way they are. -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
Torsten "Paul" Eichstädt
2007-Oct-13 09:03 UTC
[zfs-discuss] solaris pivot-root (Re: ZFS Mountroot and Bootroot Comparison)
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
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/ppm at 0
pci0 at root: space 0 offset 0
pci0 is /pci at 0,0
/pci at 0,0/pci1000,30 at 10 (mpt0):
Rev. 1 LSI, Inc. 1030 found.
/pci at 0,0/pci1000,30 at 10 (mpt0):
mpt0 Firmware version v1.3.41.32 (?)
/pci at 0,0/pci1000,30 at 10 (mpt0):
mpt0: IOC Operational.
PCI-device: pci1000,30 at 10, mpt0
mpt0 is /pci at 0,0/pci1000,30 at 10
sd2 at mpt0: target 1 lun 0
sd2 is /pci at 0,0/pci1000,30 at 10/sd at 1,0
/pci at 0,0/pci1000,30 at 10/sd at 1,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 at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
This message posted from opensolaris.org