Re: 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.iso 2021-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}
Reply to: