Marc Joliet posted on Thu, 29 Oct 2015 22:10:24 +0100 as excerpted: >>Meanwhile, as explained in the systemd docs (specifically the systemd >>for administrators series, IIRC), systemd dropping back to the initr* is >>actually its way of automatically doing effectively the same thing we >>were using lib_users and all those restarts to do, getting rid of all >>possible still running on root executables, including systemd itself, by >>reexecing systemd itself back in the initr*, as a way to help eliminate >>*everything* running on root, so it can not only be remounted read-only, >>but actually unmounted the same as any other filesystem, as userspace is >>now actually running from the initr* once again. That's a far *FAR* >>safer reboot after upgrade than traditional sysvinit solutions were able >>to do. =:^) > > Yeah, the ability to do that is a nice plus of using an initramfs. > Although I've never been clear on why it's *safer*. Is it because the > remount might fail? Or are there other reasons, too?
While I don't claim anything but informed admin level authority on the problem... It's first worth noting that the problem a return to initramfs helps solve is in practice reasonably rare and obscure, since if it weren't, people would have been experiencing it in serious numbers on sysvinit- based systems all along, and something would have been done to solve it long before systemd came along. So it's a relatively narrow issue that in practice can only affect a few users, a relatively small portion of the time. >From my read of the systemd docs, it's more pointing out a theoretical issue than a practical one, pointing out that systemd is in fact a more theoretically correct solution to the (implicitly mostly theoretical) problem. In that context, I believe the (mostly theoretical) point is as much that we were treating / (and perhaps another mount or two) special, remounting it read-only instead of unmounting it because in practice there wasn't any other choice, and that now that systemd offers the choice, it can in fact be treated just like any other filesystem, fully unmounting it before shutdown. Since exceptions to rules are nice places for bugs to hide, in theory at least (the remount-ro root being such a universal exception that in practice it's a rule of its own, and bugs couldn't long hide in that exception /because/ of its universalness), being able to treat / like any other filesystem and unmount it is a "purer and more correct" solution. IOW, it's a nice counter to the "systemd isn't unixy enough" point, as here, it's more "unixy" than sysvinit ever was. That said, I expect that over the years there have been plenty of otherwise nice implementations of various useful things that ran into a shutdown/reboot-time problem due to root's remount-ro exception, that either limited them to non-root-filesystem deployment or sent them back for a workaround, if not causing them to rejected outright as unworkable, that in this new return-to-initr*-and-unmount-root environment will see faster deployment without the workarounds that heretofore were required. Of course that'll end up being a limitation on deployment on non-initr* direct-to-root boot sequences, but in this primarily prebuild binary distro with prebuild by-necessity-modular-kernel-and-initr* environment, that's unlikely to slow down wide deployment by much, and anyone wanting to do direct-to-root boots and/or non-systemd-based deployments will just have to find their own workarounds, which may ultimately be incorporated into upstream, or not, depending on upstream's whims. Which, bringing it all back to the btrfs list title topic, is already where multi-device btrfs as / filesystem is in terms of initr*, since that's basically broken without an initr* to assemble it. And of course the same thing goes for / on LVM, since it too requires userspace to activate, which means initr* if / is on it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
