[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1000239: Rescue system won't find root partition, but insists on /usr

(Speaking only on my own behalf, not on behalf of the TC, here)

On Fri, 03 Dec 2021 at 16:08:24 -0500, Nicholas D Steeves wrote:
> 1. Debian isn't yet ready for usrmerge

Merged /usr is not actually the problem here, although it exacerbates what
appears to be a pre-existing bug in the rescue mode[0]. The root cause is
that since Debian 9 [1][2], the "/usr-like" parts of the root filesystem
are no longer guaranteed to be self-contained: important shared libraries[3]
and executables have been gradually moving into /usr for a while, and
stretch was the point at which this was declared to be officially allowed.

Merged /usr makes this very noticeable because it's the most extreme
version of that process, where *literally everything* "/usr-like" (most
notably /bin/sh) moves into /usr. When /usr is a separate filesystem, that
leaves a root filesystem that potentially contains only /etc, symlinks and
mount points, which is certainly not enough to be useful to chroot into.

> 2. Reassign to src:rescue, and fix the rescue system.

I think this will have to be the answer. See also [0].

> 3. Disallow configuring of a mount for "/usr"

That would be unfortunate, since one of the things enabled by merged
/usr is the ability to keep all "/usr-like" content on a separate /usr
filesystem that is mounted read-only during normal operation, remounting
it rw only for system updates[4], while leaving /etc and /var rw (and
potentially offering the ability to reformat the partition with /etc
and /var, and then repopulate it via systemd-tmpfiles or similar, as a
"factory reset" mechanism).


[0] https://bugs.debian.org/769738 (opened in 2014)
[1] https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#late-mounting-usr
[2] and possibly earlier: that release note was documenting current practice
    rather than describing a new change
[3] for example about half the libraries in `ldd /sbin/cryptsetup`
[4] which potentially happen atomically across a reboot, as seen in ostree,
    or while rebooted into a special boot mode, as with

Reply to: