1. 12
    1. 3

      Ah, synchronicity! What surfaces this now?

      Just six hours ago (and about as long past bedtime), I was learning from sparse Reddit threads where to get OVMF in GNU Guix. Like the author, I’ve been drawn towards increasing amounts of both immutabililty and personalization (ie. exoticism), one locus being Erase Your Darlings. Just looking at their config I can feel the hours of persistent, stubborn wrangling.

      Eventually, many hours later, […]

      I had my own run-ins with EFI while setting up Secure Boot. Something (some daemon, utility, firmware, or package-script) keeps flagging efivars as immutable, and the extended attribute has escaped me, for several hours, on multiple occasions.

      What I wish I had tried earlier was to just boot into EFI shell because you can edit EFI vars much faster there

      Does somebody expect me to remember those magic [GRUB] spells? What [should you] do next to boot into Linux?

      I hardly remember commands for the GRUB & EFI shells. For a long time I didn’t know you could scroll in EFI shells, and the output of help would scroll off-screen. Using my phone sucked, a VM wasn’t always sufficient (or simple: see TFA), and I really appreciate my one KVM.

      Although it’s later in the boot process, I want to give props to the Guix team here: their Guile Scheme initramfs scripts error out into a REPL, where you can import all the same (gnu build [...]) utilities the script was using. Don’t think you can scroll, but it’s refreshing to have all those tools a backtrace at hand as soon as something goes wrong.

      I don’t even want to think how many hours I lost because of this. My actual problem was more nuanced […]

      Rant: Guix doesn’t yet support key-files for LUKS partitions so I made my own mapped-device-kind that does. Other code filters mapped-devices for LUKS partitions by checking their types, and proceeded to miss mine. To avoid forking Guix (which I guess I could do) or subverting it’s device management entirely, I had to mutate the existing type to add special cases for my devices.

      Another pain-point: Having achieved darling erasure with BTRFS I’m now pursuing root on ZFS, which has a… tumultuous history with Guix. I’ve done all the necessary wrangling to mount the datasets in the initramfs, but Guix really wants a path to a mount-able root block-device that it can watch for. I don’t want to write (and maintain) my own fork of the initramfs, or stoop to putting root on a ZVOL just to satisfy that requirement, so I’m working on whatever cheap hacks are necessary to get around the existing code.

      Which is somehow to say; It’s always like this. I can’t suitably articulate right now why I persist in having everything just so, but I learn a heck of a lot about both the underlying systems and the towers built atop them by being so stubborn. Software infrastructure was how I got into programming in the first place, and will always be a blessing and a curse. Heaven help those who rely on my homelab.

      I find this post valuable informationally and personally. Thanks joonas for taking the time to write it, and to bsandro for sharing it.

      Edit: Ugh, going to need so mutate / advise more functions.

      “I didn’t identify with it for a long time; Not until everyone else had been getting an earful for years. I was just trying to get my computer to work, and guess I picked it up along the way. Couldn’t get everything just right without a lil’ scripting. I thought, does this (ie. Bash) really count? How do people use their computers (ahem, Linux) without programming? But I’m well past any plausible stage of denial now :p”

    2. 2

      An additional hair-pulling detail from my notes on the topic:

      • A flash storage with boot firmware, OVMF_CODE.fd on x86_64
      • A flash storage, (a writable copy of) OVMF_VARS.fd for a VM instance. Must be writable on aarch64, can be readonly on x86_64
      • A FAT partition on a VM drive with EFI/Boot subdirectory:
        • contains .efi files to boot.
        • the default option is BootX64.efi on x86_64 (BootAA64.efi, BootIA32.efi, etc);

      OVMF_VARS.fd can technically be readonly for x64, but if you want to persist variables, it should be a writable copy. aarch64 even requires it to be writable.