Bug#1000239: Rescue system won't find root partition, but insists on /usr
Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : c) parse /target/etc/fstab, and attempt to mount other partitions The rescue system already offers to do it for separate /boot and /boot/efi, so why couldn't it do for separate /usr too ?
Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >> >> >> c) parse /target/etc/fstab, and attempt to mount other partitions > >The rescue system already offers to do it for separate /boot and /boot/efi, >so why couldn't it do for separate /usr too ? That's exactly what I'm about to do. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#1000239: Rescue system won't find root partition, but insists on /usr
Simon McVittie writes: >> 2. Reassign to src:rescue, and fix the rescue system. > > I think this will have to be the answer. See also [0]. I'm certainly not against fixing this issue, but I thought I'd point out that even as things are, its pretty trivial to get into rescue mode. Having just tested it with a separate /usr, all one needs to do is select the actual root partition as you'd expect, then when prompted to execute a shell, select the second option (Execute a shell in the installer environment), then the trick is to mount the /usr partition by hand onto /target/usr e.g.: # mount /var/vfa4 /target/mnt Having done that one can exit that shell, and then select the first option (Execute shell in /dev/...) and you're away. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Sat, Dec 4, 2021, 6:45 AM Simon McVittie wrote: > (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). > I would like to add myself to the Testing part of this process. Some may have noticed some "static" from me Yesterday, when I, somehow messed up the "Install Desktop from Network" options, on two qemu Installs of Bookworm. I assume that, Bookworm would be the earliest place where most of the Changes would be made to the Rescue System? (Though I have one or two Bullseye Systems that are Expendable also). > [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) > Speaking of SystemD, are there, yet any good "SystemD for Dummies" books out there? That is something I would pay Money for. Thanks! Kenneth Parker >
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)
Bug#1000239: Rescue system won't find root partition, but insists on /usr
Am 03.12.2021 um 22:08 schrieb Nicholas D Steeves: 2. Reassign to src:rescue, and fix the rescue system. Looks like a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769738
Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Control: severity -1 serious
> Control: tags = confirmed
>
> CCing the release team, and CTTE because I don't know who else is
> tracking issues related to the usrmerge effort. I've consciously chosen
> not to pour gasoline on the flame war by CCing anyone else (nor will I
> contact anyone else about the existence of this bug).
>
> Steps I used to try to reproduce:
>
> 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M
> 2. Installed to EFI-enabled qemu eg:
>kvm -bios /usr/share/ovmf/bios.bin -m 2G \
>-hda debian-separate-usr-sda.raw \
>-cdrom debian-testing-amd64-netinst.iso
> 3. Guided partitioning with separate /home, then changed the mount point
>to /usr. Partition layout is:
> sda1: ESP fat32
> sda2: /ext4
> sda3: swap swap
> sda4: /usr ext4
> 4. Selected only "Standard System Utilities"
> 5. Rebooted
>
> Result: SUCCESS
>
> Then, to test the rescue functionality:
>
> 1. I discovered qemu+OVMF boot order is broken without changing the
>command to: kvm -L /usr/share/ovmf/ -m 2G -boot menu=on \
>-hda /scratch/debian-separate-usr-sda.raw \
>-cdrom /scratch/debian-testing-amd64-netinst.iso
> 2. Selected sda2
> 3. Yes, mount /boot/efi
> 4. Execute a shell in /dev/sda2
> 5. No usable shell was found on your root file system (/dev/sda2)
> 6. Changed virtual terminal
> 7. cd /target && ls bin
>ls: bin: No such file or directory
>
> Result: FAILED
> Conclusion: This is a usrmerged system, and the rescue system does not
> support usermerged systems.
>
> The options are, as I see them, ranked from least to most work-hours:
>
> 1. Debian isn't yet ready for usrmerge. Revert to normal system installation.
> 2. Reassign to src:rescue, and fix the rescue system.
>a) before chrooting, test for the presence of /target/bin/sh
>b) if /bin/sh is not found, either emit error to the user and present a
> dialogue for selecting /usr partition, or
>c) parse /target/etc/fstab, and attempt to mount other partitions
>d) b & c will be difficult to implement when attempting to accommodate
> the heterogeneity of possible MD, LUKS, and LVM layouts, not to mention
> the complications introduced by the possibility of a user-configured
> btrfs subvolume name "@usr" on any valid device. Fstab parsing might
> make the btrfs case easier with:
> i) Display a dialogue selector if a btrfs partition is detected
> The dialogue will list all detected subvolumes
> ii) If the user cannot find a subvolume for "@usr", then
> iii) Allow the user to escape to the partition selection screen, and
> iv) Unmount the partition
> 3. Disallow configuring of a mount for "/usr", and *Prominently* declare that
>Debian no longer supports separating /usr from /, declare this in *many
>places*, and reply to bugs on this topic for many years. I put this one
>last because I believe the cost to work-hours is unbounded, and
>because I believe there may be a negative social cost associated with
>this action. Also, if Fedora/RHEL/SUSE/Ubuntu support a separate /usr
>partition, then this action could make Debian look inferior.
FWIW, Debian was the last holdout in still supporting a separate /usr
partition amongst major distributions, so that bit is irrelevant...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
