#79248 [PATCH] 006-rebootload: Propose GCD006 "Rewrite Bootloader Subsystem"

Message #17 received at 79248@debbugs.gnu.org (full text, mbox, reply):

Received: (at 79248) by debbugs.gnu.org; 17 Aug 2025 23:22:02 +0000
From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 17 19:22:01 2025
Received: from localhost ([127.0.0.1]:48218 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1unmhN-0001So-8i
	for submit@debbugs.gnu.org; Sun, 17 Aug 2025 19:22:01 -0400
Received: from cyberdimension.org ([79.143.250.36]:37086
 helo=rockpro64.cyberdimension.org)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <GNUtoo@cyberdimension.org>)
 id 1unmhK-0001Sa-1w
 for 79248@debbugs.gnu.org; Sun, 17 Aug 2025 19:21:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=dkim; bh=oixDjGhTJoK+az+
 9tD2XCuQOx82vg+vF+gCEzMOGezQ=;
 h=references:in-reply-to:subject:cc:to:
 from:date; d=cyberdimension.org; b=AzJRzBCqoAoeg/lMyvMjHJCJ2WHadAvJWsR
 S6h75SRnsfiPjsS/S0olM0nInwetHGY7fRyC531wZH1ZomZ/c4urDnn9ks1Ne3Ayy7w+Y5
 9xa1SPpZllVuLULs8n8WU6zIX+dfLp8+uV57cFe4L95J4spL2Nfu+iaxqK0wQsApoxGQ1p
 OOtEboAZE5+v1girrYqmtpZPUyZ+yqQ9G9v5qUpWCYVeEIQ2tg4vYS9a4WzWYurXMIMC6b
 aQyx35zPNNkzJkJU7fhycdAz/VLEOuTuhYa1JHykUaZN7sUvv13Xg3ErRe5xI8GVClVZDu
 54NGK2b2xeShwDgBYS8a6Z7lwdA==
Received: from primarylaptop.localdomain (localhost [127.0.0.1])
 by rockpro64.cyberdimension.org (OpenSMTPD) with ESMTP id 67287fc7;
 Sun, 17 Aug 2025 23:21:54 +0000 (UTC)
Date: Mon, 18 Aug 2025 01:21:35 +0200
From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
To: Lilah Tascheter <lilah@lunabee.space>
Subject: Re: GCD006: Rewrite bootloader subsystem
Message-ID: <20250818012135.7245af5f@primarylaptop.localdomain>
In-Reply-To: <912fd9f161309a065423b062997a9226b92e60fb.camel@lunabee.space>
References: <912fd9f161309a065423b062997a9226b92e60fb.camel@lunabee.space>
X-Mailer: Claws Mail 4.3.1 (GTK 3.24.43; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/zmlNgG7heCN8L.mQXAdnUv6";
 protocol="application/pgp-signature"; micalg=pgp-sha256
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79248
Cc: guix-devel@gnu.org, 79248@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.