weird mumi message dupe/drop?
so, I just tried to apply v3 of issue #73202, but it failed, first trying to apply a regular email, then completely dropping the last patch (in email order, so actually patch 12/14). looking into it, it seems like the raw messages aren't indexed properly? when downloading the raw mbox for either @17 or @18, the message for @17 is returned. all subsequent messages are then shifted one earlier than they should be. so, mumi am just doesn't work at all. any clues wtf happened? honestly I'm not even sure where to report this (if to report this?) and if anyone can, like, fixup the patch series message files? thanks! lilah
Call for testers for bootloader subsystem rewrite!
Hey! I just submitted a patchset containing a full rewrite of Guix's bootloader subsystem, as in its current state, it was only really meant to support GRUB. Seeing as we support a large variety of bootloaders, and a bug in this subsystem could be disasterous, I figured I'd ask for testers here. So, anyone willing to throw an experimental patchset at some (recoverable!) hardware, please test it out and tell me any issues you encounter! Link on the issue tracker: https://issues.guix.gnu.org/72457 Thanks!!
extlinux and a bootloader system rewrite
heyall! I've been working on a large bootloader subsystem rewrite to get everything working together nicer and support future bootloaders better. however, extlinux is being a bit of an issue. extlinux installs its second stage (ldlinux.sys) by copying it into the root (or boot) filesystem, and then copying the on-disk block offset into the bootblock first-stage. this relies on the now-heavily discouraged practice of assuming files just stay in the same physical spot. it requires special treatment with btrfs, will break if anything rearranges the file-system, and will most likely never work on disk images. it hasn't been updated since 2014 and kinda shows. a possible solution would be re-implementing its installer and instead installing ldlinux.sys to a separate partition, or maybe see if it could re-use GRUB's method of installing in the partition gap or even editing the disk image installer to work in an losetup'd container or some shit. but, honestly, I don't know if that would actually help anyone. does anyone use extlinux on guix still? would anyone mind if I just nix it (guix it?) entirely in the patch series? grub supports every case extlinux would support anyway. thanks! leila
Re: [RFC] proposal for refactoring bootloaders
one more quick change that I've realized will be necessary: add a bootloader-targets field to boot-parameters. some bootloaders would need target info to know where to install config files, and reinstall-bootloader doesn't have access to the operating-system record. rollbacks to generations pre-field addition shouldn't be an issue with this either, as existing bootloaders (sans depthcharge?) do just fine without targets. all in all, bootloader-installer and bootloader-config-file-installer would be procedures that return gexps, with the following signatures: * (installer entries #:key bootcfg mount-offset generation old-entries store-crypto-devices store-directory-prefix locale) * (config-file-installer entries #:key package targets mount-offset generation old-entries store-crypto-devices store-directory-prefix locale) mount-offset is the current target, and old-entries becomes an alist with generation numbers. - lilah
[RFC] proposal for refactoring bootloaders
hi everyone! I've been working on submitting to mainline some bootloaders I packaged a while ago on my channel (an efi-stub bootloader supporting secure boot & full disk encryption and p-boot for pinephones) and came across a good few hard points in how guix handles bootloaders. the current system seems to have been made with only grub/extlinux-alikes in mind, and makes working with everything else extremely cumbersome and incompatible with generation rollbacks. before I start making/submitting changes, I wanted to ask for opinions on the following plan: * merge bootloader-installer and bootloader-disk-image installer. almost all cases where one is used, the other is called with almost the exact same arguments, except for in (gnu system image), which provides the image itself. this should be provided in general; BIOS bootloaders and u-boot need to know the main disk device anyway. * create a new bootloader-config-installer record field (accepting a gexp), replacing bootloader-configuration-file and bootloader-configuration-file-generator. it's really only grub/extlinux-alikes that use a single, static-path config file. uefi configuration involves calling efibootmgr, and p-boot needs an entire configuration partition. can provide a helper procedure to replicate current behavior, and register the gexp as a gc root to prevent gc of boot objects, in lieu of the current behavior. * provide the full bootloader-configuration record to bootloader-installer instead of just bootloader-package. the full record is available every time bootloader-installer is called. * don't provide bootloader-configuration to bootloader-config-installer. reinstall-bootloader (guix scripts system) regens the configuration without access to the full bootloader-configuration record. conceptually, config install should only affect the boot entries themselves anyway. * change initialize-efi-partition (gnu build image) to handle any bootloader-installer when used, providing its partition as the target. also un-hardcode grub in system-disk-image (gnu system image). * to facilitate secure boot support, add a bootloader-configuration-signing-keypair record field accepting a pair of out-of-store paths to encryption keys. * provide generation numbers to bootloader-installer and bootloader-config-installer, to help with coordination between the procedures, and bootloader-config-installer allowing incremental rollbacks in bootloaders that have to copy the kernel/initrd off-root. (thanks Hilton Chain for initial discussion on this in the uefi support patch thread!) - lilah
