Daniel Reurich <dan...@centurion.net.nz> writes: > Ah, so it's actually packages that don't separate device configuration > logic from the application or daemons properly that has caused the > brokenness. Can we identify and fix the packages that cause this issue?
No. Debian has basically given up on this; there are way too many packages and way too much stuff that would have to be moved to /bin and /lib in order to preserve the traditional semantics that allow /usr to be mounted very late. I've poked a bit at this in the past, and the amount of work that would be required is daunting, and benefits only a few highly unusual edge cases. I'm pretty sure we have not released a version of Debian that did this fully properly for at least four or five years. There have been various unexpected dependencies on /usr in at least some packages for at least that long (such as sysvinit scripts that use binaries in /usr without depending on $remote_fs). I'm pretty sure of this because I looked at trying to write Lintian checks for it, once upon a time. Instead, everyone just takes the approach of mounting /usr very early so that stuff in /usr can be used during boot. I suspect you have not even noticed that this has happened, because it basically just works for the average system, although my understanding is that it's not particularly clean (yet) under the hood. > Is this also something to do with the inherent lack of determinism and > parallelization in systemd's startup as well (just out of interest)? No, it has nothing to do with systemd parallelism. It does have a lot to do with udev (specifically with udev rules that want to run commands), but udev is definitely not the only culprit in wanting /usr to be available. > Having to do all this contortionism and particularly mounting /usr in > initramfs sounds like a horribly insane way to do things! And yet, it works, and it means that we don't have to try to harass a thousand package maintainers into doing essentially untestable busy-work to try to move things around between /usr, /bin, and /lib to support a tiny handful of systems for which other approaches are available. The cost/benefit tradeoff is, dare I say, *extremely* obvious. Note that mounting /usr early, something we *already do*, is separate from actually merging /usr with /bin and /lib. Once you mount /usr early, it's rather less important whether you actually merge the file systems. While it does let you do some interesting things, I see it as more of a cleanup. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
