Hi, Here are some more related comments on specific parts of the proposal.
Though I've no idea yet if all that should go in a GCD or not (I need to think about it more, maybe other people have better ideas than me though). On Fri, 15 Aug 2025 15:13:49 -0500 Lilah Tascheter <lilah@lunabee.space> wrote: > ## User Configuration > [...] > ## Rollbacks > As the entire bootloader install process exists in gexps, each > generation will simply save its combined bootloader install script as > a GC root to be called on rollback, the exact way it's called on > install. This eliminates the need for bootloader module search and > bootloader configuration guessing (as is currently used), as well as > making bootloader rollbacks more reliable. If a user on x86_64 with GRUB has MBR, then switches to GPT (with gdisk) and runs 'guix system reconfigure' after potentially adjusting the system configuration, would a rollback still work (sudo guix system roll-back)? Or will GRUB only load the MBR specific module (because that was recorded before) and not the GPT one, making it impossible to access the rest of its modules? Right now I've no idea what works and what doesn't. Renaming an LVM partition that holds the rootfs probably breaks roll backs (after GRUB), but for the rest I'm not sure. An idea here could be to warn users that for instance changing the partition type can now break rollbacks, at least for GRUB. And while at it (if there is some interest) we could document what kind of things are (not) supported when rolling back and/or what guarantees the bootloaders managed by Guix are supposed (not) to give (when selecting older system generations at boot, we still use the new bootloader for instance, so only the kernel + its parameters and the initramfs change). > All other handling will be done invisibly to both end-users and > bootloader packagers, due to the above defined semantics of target > conversion into keyword arguments. Will the chosen code to install the bootloader depend on things like GPT vs MBR? Here I mostly have u-boot in mind. > ## Cascading Changes [...] > Furthermore, a new utility procedure will be created to facilitate EFI > bootloaders, handling copying to the ESP, setting EFI boot options, > configuring removability, and ensuring sufficient storage space in > the ESP. Will that generates the /boot partition by itself and take full control, including with 'guix system reconfigure'? > * [waggle](https://git.lunabee.space/waggle/files.html), my channel, > which adds p-boot for the Pinephone and a UKI bootloader, whose > roundabout implementation necessitated by the current system prompted > me to begin this rewrite in the first place. Does not support > rollbacks, and I didn't realize until after I needed one in the first > place. It is impossible for these to support disk images in the > current system. I'll try to look at it. > # Drawbacks and Open Issues > As these are bootloader changes, patches will need to be tested > carefully in order to ensure no devices get bricked. I assume that you mean that the rootfs won't boot anymore. I'm unsure if there is that much care taken right now for arm64. For instance is u-boot on arm64 already broken? It's been a while since I wanted to investigate but I didn't find enough time to fully dive into it. I've one device officially supported by Guix but it's also my mail server, so I'm a bit afraid of rebooting it right now without more guarantees. So I tired with that instead: > +(define-public u-boot-rock-4c-plus-rk3399 > + (let ((base (make-u-boot-rockchip-package > + "rock-4c-plus" 'rk3399 > + '("CONFIG_USB=y" > + ;; Disable SPL FIT signatures, due to GPLv2 and > + ;; OpenSSL license incompatibilities. > + "# CONFIG_SPL_FIT_SIGNATURE is not set")))) > + (package > + (inherit base)))) and: > +(define rock-4c-plus-installation-os > + (embedded-installation-os u-boot-rock-4c-plus-rk3399-bootloader > + "/dev/mmcblk0" ; SD card storage > + "ttyS2")) ;; Default UART as per [...] And here the boot is broken with the commit ac9c4da0581342bec3fa47a38130ebaabc3735f7 (Thu Aug 14). So I'm unsure if this is a real concern for arm64, and I'd like other people to give feedback here. But if it is really broken since many months, then as long as it makes things more reliable at the end, people would probably be happier. As for really breaking computers, it can happen with UEFI on x86 (and maybe some nonfree UEFI on ARM as well) but it needs some conditions: - The computer needs to boot with UEFI (we support UEFI, so let's assume it's true) - The bootloader or kernel needs to crash (it sometimes happen, so let's assume it will happen) - The bootloader and kernel needs to be configure to store crash logs inside the UEFI - The UEFI needs to be buggy (it sometimes happens, so let's assume it's true) So the solution here would be to just verify that we don't write crash logs inside the UEFI and we should be good. We would need to check the kernel and bootloaders though. In the case of u-boot on ARM, if u-boot (+ arm-trusted-firmware) is/are the only bootloaders parts, then there is probably not a lot of probability to break devices. Denis.
pgpi6AI_XjVGC.pgp
Description: OpenPGP digital signature
