Re: [RFC] proposal for refactoring bootloaders
Hi Lilah, On Fri, Feb 16, 2024 at 02:33:02AM -0600, Lilah Tascheter wrote: > > one more quick change that I've realized will be necessary I made some changes to my bootloader locally and believe the commit series here [1] could be useful to you. It removes a lot of the confusion that arises when the boot-parameters are rewritten on the fly. Kind regards Felix [1] https://debbugs.gnu.org/69343
Re: [RFC] proposal for refactoring bootloaders
On Fri, Feb 16, 2024 at 02:33:02AM -0600, Lilah Tascheter wrote: > 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. The current bootloader system started as grub only and then grew more capabilities for other things too. It should be possible to flash u-boot separately and then use grub-efi (or something like it) but it's not currently supported out of the box. I look forward to seeing how this might look. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
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
