Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr
This sounds correct, based on my experience with the bug. I suppose now there are zero ways to definitively determine which partition is actually root. So maybe a hidden flag (empty) file in root might do the trick.
But the fact that /usr can be automounted, but nothing else can be manually mounted afterward is also a problem. If there was a separate script to do the chroot part, and some manual interface by which to mount; perhaps the mount command in the rescue system PATH, the whole thing would be more flexible during the transition to ro mount for /usr in future Debian versions.
Presently it appears there will be several possibilities for the conditions of root and /usr, so no definite means cannot be devised to always do the correct thing. Even if a flag file is used to identify root, that might not be what rescue requires.
In the near future I think the flag file would work, and then /usr could be mounted manually, as once was the case. But perhaps at some point mount would need to be a static binary, to account for libraries moved to /usr.
I'm not well versed on Debian policy, so just ignore my input if it makes no sense. If you find it irritating, it's my ignorance at work, nothing intentional.
-------- Original Message --------
From: Simon McVittie <smcv@debian.org>
Sent: December 4, 2021 11:42:56 AM UTC
To: Nicholas D Steeves <sten@debian.org>
Cc: 1000239@bugs.debian.org, TomK <forensic@milwpc.com>, Steve McIntyre <steve@einval.com>, debian-release@lists.debian.org, debian-ctte@lists.debian.org
Subject: 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[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).
smcv
[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
systemd.offline-updates(7)
Reply to: