Re: 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. The root cause is
that since Debian 9 , the "/usr-like" parts of the root filesystem
are no longer guaranteed to be self-contained: important shared libraries
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 .
> 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, 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).
 https://bugs.debian.org/769738 (opened in 2014)
 and possibly earlier: that release note was documenting current practice
rather than describing a new change
 for example about half the libraries in `ldd /sbin/cryptsetup`
 which potentially happen atomically across a reboot, as seen in ostree,
or while rebooted into a special boot mode, as with