Saturday, December 3, 2022

Failing to Install Fedora 37

Waiting for yet another 80+ MB download of a .deb file, I decided to try to dual-boot Fedora on my Pop!_OS laptop (darp8).  Because drpms exist.  That’s it, that’s the whole reason.

[Update 2022-12-04: Because all resize-related commands use “as much space as possible” by default, I decided to try again, shrinking the filesystem/LV/PV more than was necessary, and then re-expanding them after the partition was changed.  I got Fedora installed, but the system76 extension for the power manager doesn’t work on Gnome 43. Gnome claims it’s not their fault that the system they created frequently breaks extensions in general; I assume they feel the same about the specific case here, where they changed the menu API instantly and completely.]

[Update 2022-12-19: I pretty quickly gave up on Fedora.  It had a tendency to result in the laptop rebooting into recovery mode after using the Fedora install.  Booting Linux is clearly not important enough to get standardized.  Oh well!]

I had asked for encryption during the initial setup, and the machine is UEFI with coreboot and open firmware, so the disk has a GPT setup allocated thus:

  1. 0.5 GB EFI SYSTEM
  2. 4.0 GB RECOVERY
  3. 923 GB (no name LUKS type)
  4. 4.0 GB (no name encrypted swap)

I knew from past exploration that the LUKS partition contained an LVM physical volume, with a volume group and logical volume filling the whole space.  It’s not so hard to resize2fs and then lvreduce… very carefully.  I had 99 GB of data in use, so I booted into the on-disk recovery image this time, changed the LV to 400 GiB in the filesystem, then set the number of LVM extents.  That part worked flawlessly.

At this point, I headed into the Fedora installer.  Things went okay, until selecting partitioning.  I exclusively used the “Advanced Custom (Blivet GUI)” option, and that was kind of a mess.  I had to unlock the LUKS partition; afterward, the LVM volume group appears as a second entry in the sidebar. Fair enough.  It had my 400 GB LV inside, and some free space, and then things started going off the rails.

Failure #1: I didn’t understand the Name field, so I left it blank, and Blivet named it (the new logical volume) 00.  That seemed like it would be unnecessarily confusing later on, so I deleted that, and put in a new LV with a better name.

Failure #2: At this point, Blivet said it had 3 actions pending: create/format, delete, create/format.  “Undo” would take out the only change I wanted to keep, so I clicked Reset All.  It cleared the operations queue, but it also put the GUI into a state where it reported the LUKS partition was locked (it wasn’t), but also would not let me unlock it.  I re-locked it through the Terminal, but it didn’t help.  I rebooted to try again.

Alternative hypothesis: maybe the VG was still in the sidebar and I didn’t notice it.  I was too n00b to cover every case yet.

Failure #3: After this point, Blivet never had the keyboard in Dvorak ever again, even after cold boots of the installer.  I’m actually not certain if it did the first time, or if that detail just got lost with all the other stuff going on at that point.

Failure #4: Fedora does not want /boot to be on a logical volume.  There is a bug, where the discussion is basically, “we should support everything reasonable, but md-raid is too hard.”  I found another thread somewhere, where Lennart “You’re Doing It Wrong” Poettering said that the EFI System Partition (ESP) should be mounted at /efi, or even /boot because there’s no point to having /boot when using EFI, and /boot/efi is “dumb” [sic] (no reasoning given.) Fedora does not want the ESP to be mounted anywhere except /boot/efi, though.

Failure #5: I discovered it was possible to use pvresize to shrink the LVM PV.  I wasn’t entirely sure that I could have the partitions out of order (it seemed like the easiest thing for an editor to do would be to append a 5th GPT entry, pointing to the 4th extent on disk) but I decided to try. Unfortunately, fdisk reported 32,768 more sectors allocated to nvme0n1p2 than pvresize said in its “pretending the disk is … not Y sectors” message, which completely destroyed my confidence that I could resize the partition around it correctly.

I gave up at this point.  I can’t coax the system into a “supported” configuration, and I’m not really willing to install an OS on a production machine—this is the one where the money is made—in an unsupported, “may fail at any time” configuration.

Meanwhile, in Pop!_OS, the system boots just fine with /boot on LVM and the kernel/initrd stored in the ESP.  I really thought the whole point of EFI was to make OS-specific boot loaders irrelevant.  (Like Multiboot, but complicated, albeit with Microsoft and Intel supporting it.) I don’t understand why the Fedora “Let’s Remove BIOS Support” Project requires GRUB and /boot (non-nested) with UEFI.

No comments: