Re: support for merged /usr in Debian
Daniel Reurich <daniel@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: