Gentoo Linux systems using ZFS as their root filesystem will print messages about being unable to unmount datasets during system shutdown. What happens during shutdwn is that OpenRC will invoke RC/init scripts' shutdown() functions in reverse order of dependencies. This means that zfs is called before localmount. When the rootfs is ZFS, zfs will naturally try to unmount it, but localmount has other stuff on top, which prevents that, causing information about the failure to unmount ZFS to be printed. That is a cosmetic issue. I plan to address it in the future, but it is a low priority.
I don't know if the following is a bad idea. But in my understanding, you need an initramfs for ZFS to work as root. Within you mount your ZFS root FS and then execute the init from that FS. Why can't the zfs init script not run before localmount is executed? This would reverse the current order of the init scripts and prevent the issue from happening...
(In reply to comment #1) > I don't know if the following is a bad idea. But in my understanding, you > need an initramfs for ZFS to work as root. Within you mount your ZFS root FS > and then execute the init from that FS. > > Why can't the zfs init script not run before localmount is executed? This > would reverse the current order of the init scripts and prevent the issue > from happening... This has been on my mind, although I haven't had a chance to do proper testing yet.
Created attachment 349512 [details, diff] Patch to OpenRC script All major issues in the ZFS kernel code that acted as stabilization blockers are no resolved, so I am beginning to look at lower priorities issues, such as this one. The attached patch should fix it. It is a work in progress as I evaluate other cases that I might want to handle in the same ebuild revision.
(In reply to Richard Yao from comment #3) > Created attachment 349512 [details, diff] [details, diff] > Patch to OpenRC script > > All major issues in the ZFS kernel code that acted as stabilization blockers > are no resolved, so I am beginning to look at lower priorities issues, such > as this one. The attached patch should fix it. It is a work in progress as I > evaluate other cases that I might want to handle in the same ebuild revision. That should be "now resolved", not "no resolved".
I have committed sys-fs/zfs-0.6.1-r1 with a variation of this patch.
