El dom., 18 ago. 2019 a las 15:36, Laurent Bercot escribió: > > >Simply excluding filesystems doesn't help when the root filesystem is on one > >of > >these devices that needs teardown actions after being unmounted. In that > >case, > >the only workable solution is to have PID1 pivot_root() to a tmpfs with the > >teardown/reboot tools in it. That way you can actually fully unmount the > >former > >root filesystem. > > Are there systems in the real world that actually work like that? That > need pivoting into a "shutdownramfs" in order to be able to unmount the > rootfs and perform teardown operations on it? This is doable, of course, > but sounds too complex and too brittle. You'd need more than a fsck to > recover after a power loss, for instance.
I know that there are people that have the rootfs on an LVM logical volume or a LUKS encrypted volume, yes. However, those are specialized setups. I don't use one myself, I think they are risky, and I don't know the details, but I think they are handled with a (mandatory) initramfs. Perhaps someone else knows this better. Our friends from the systemd project have thought of that as well (the 'shutdownramfs' would be the initramfs that is kept mounted at /run/initramfs): * https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface But I think of this as a separate problem, that maybe also means revisiting the decision of not having s6-svscan do its finish procedure. I didn't want to mention all the complicated cases at once :) > Now the fun part for me is to find a way for s6-l-i-umountall to > leave the proper filesystems mounted. It's not as straightforward as > it seems: if /dev is a symlink to, say, /mnt/tmpfs/dev, then you want > to keep /mnt/tmpfs/dev, even if it means you have to keep /mnt/tmpfs. > But if you have a second dev mount on /usr/local/mychroot/dev, then > you want to unmount that one, so you can unmount /usr/local. I suppose > I can count the number of devtmpfs, procfs and sysfs, and only keep > one of each (the first that was mounted), but I have to think more > about it to make sure it catches everything. Why not just leaving all of them alone? s6-linux-init-umountall already warns about, but then just ignores, umount(2) failures. What happens if you try to unmount /mnt/tmpfs, and you have a devtmpfs mounted on /mnt/tmpfs/dev that you have previously skipped? G.