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

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

Received: (at 79248) by debbugs.gnu.org; 3 Sep 2025 21:59:03 +0000
From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 03 17:59:03 2025
Received: from localhost ([127.0.0.1]:43081 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1utvVO-0003Ul-Vc
	for submit@debbugs.gnu.org; Wed, 03 Sep 2025 17:59:03 -0400
Received: from slategray.cherry.relay.mailchannels.net ([23.83.223.169]:31647)
 by debbugs.gnu.org with esmtps
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2)
 (envelope-from <dannym@friendly-machines.com>) id 1utvVM-0003UH-2s
 for 79248@debbugs.gnu.org; Wed, 03 Sep 2025 17:59:01 -0400
X-Sender-Id: dreamhost|x-authsender|dannym@friendly-machines.com
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id 185BA7846CF;
 Wed,  3 Sep 2025 21:58:58 +0000 (UTC)
Received: from pdx1-sub0-mail-a279.dreamhost.com
 (100-102-91-11.trex-nlb.outbound.svc.cluster.local [100.102.91.11])
 (Authenticated sender: dreamhost)
 by relay.mailchannels.net (Postfix) with ESMTPA id 4CCE478454A;
 Wed,  3 Sep 2025 21:58:57 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1756936737; a=rsa-sha256;
 cv=none;
 b=KMimLQCem73BI4K/3u1CA8WWHbeHJDVOTu50TivzPoi6ysu3JxBQKVCyoI7aDDhCZxH1lv
 DUZ/O/e+3qRg59IqpZ4OI77xRg5cinj3j/2MKnHFZf2Xlpv4O26Dx25MsCiObd3+IBjI3f
 htQIehn7BPSwuxDEk+IAn/4wO2gRgoN/FqpJjcdDHIK1NWKL7WqZE3bvEhWRFVFeFFfcaG
 xIs+31zglidUi+bfxdA4IrhaIxwde0U0CEYBI+e72YN/RymP+6Iz155+ARLTooxPnsGWjz
 tRD6Xe24JHYofhRMta2ygtIhqSImCXFmUKtChIw+GTIVyT/oCUdDktGJ5j1A1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mailchannels.net; s=arc-2022; t=1756936737;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 dkim-signature; bh=VI1xZN9ySLWHiVmymIH+xHBJpMfRdVBoy6gapSutaxs=;
 b=QjLIvf7sxneMafNRJjPeuHLcyup61zSomz9Dxl2IKMSUdR8PXybeyow0aQL6IxwhLYPdh1
 5DLHy0jbVv8vhq29OJBFxrtPg9COSbUGj6F156PDRqYTkaZBbGNQNv36fmV7cc/Iju1bOM
 KsR2wZs89MDg/o1CJSlUFKwH16aXFI+piygAWg/Opk6Akepo4ki/Wy9vm7YRiXl84eHcRV
 1rwOncoO47OJecwfC1tSdI1+GNpheNCl6d3yQC/XyIbKB400g+h1UajzK15pZZoTNaAob/
 6miamkRmd/EeLCgqK9BlnFv31Smld8tzYFUDGwGJ6iKeBcpj57xv0EBYIukVJQ==
ARC-Authentication-Results: i=1; rspamd-8b9589799-n4rjh;
 auth=pass smtp.auth=dreamhost smtp.mailfrom=dannym@friendly-machines.com
X-Sender-Id: dreamhost|x-authsender|dannym@friendly-machines.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|dannym@friendly-machines.com
X-MailChannels-Auth-Id: dreamhost
X-Blushing-Keen: 56a6d578536986f2_1756936737956_2875309373
X-MC-Loop-Signature: 1756936737956:1880928014
X-MC-Ingress-Time: 1756936737955
Received: from pdx1-sub0-mail-a279.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
 by 100.102.91.11 (trex/7.1.3); Wed, 03 Sep 2025 21:58:57 +0000
Received: from nova (84-115-226-251.cable.dynamic.surfer.at [84.115.226.251])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 (Authenticated sender: dannym@friendly-machines.com)
 by pdx1-sub0-mail-a279.dreamhost.com (Postfix) with ESMTPSA id 4cHGhw0N54zJD; 
 Wed,  3 Sep 2025 14:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=friendly-machines.com; s=dreamhost; t=1756936737;
 bh=VI1xZN9ySLWHiVmymIH+xHBJpMfRdVBoy6gapSutaxs=;
 h=From:To:Cc:Subject:Date:Content-Type;
 b=uBJXinYCPPBszQexUVlPWYJ8IScXQOC/eFuq2ea5gzo1syY6kbQ7rZLH6cslq/8TS
 Ig3oPC+jGgf8GSaadpACOSxnxiOE1v8VYW1g0wkZ3+K3NmTS4+JDx+6UBhsW3hGyhl
 w+yR+fAqg9pmjcKyWMn6OOdlxh7/VgHj+rocXyuIPB62lLmIU2SSD+kDqpAR4q0x3l
 7d8VMRjHuvfpkSV8HnL/M82CZC1XwHZIbg9u/b2tIodVzfDGBb91kfP2FE/JwccVL8
 US07UnChIcmWFSx5DvcmMDfUNelCKl7WJFKn8AKNhs396dlCLoGhyYDsJYMDubJYHX
 SCmz6mskiFuhQ==
From: Danny Milosavljevic <dannym@friendly-machines.com>
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Subject: Re: GCD006: Rewrite bootloader subsystem
User-Agent: mu4e 1.12.11; emacs 30.1
Date: Wed, 03 Sep 2025 23:58:52 +0200
Message-ID: <87qzwnmc4j.fsf@friendly-machines.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79248
Cc: guix-devel@gnu.org, Lilah Tascheter <lilah@lunabee.space>,
 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 (-)

Hi,

>The "fix" here is to document what the people who contributed to this bootloader API wanted in the first place (syslinux or bootflow or
something else)

For the (original) u-boot support in Guix, what I wanted is for u-boot to use extlinux (syslinux-like configuration) for a menu and for booting older generations.  That's it.  It's intentionally modeled just like grub in Guix so I don't have to boil the ocean.

Traditional RISC machines are famously simple and you usually just put u-boot itself at some fixed sector, the end[1].  U-boot will see the extlinux configuration we generated, show a menu.  User chooses entry.  That's it.

I have intentionally not added chainloading back then, after asking whether anyone needs it and getting a "no".

It is very easy to overdo it in this space--and the Guix and Nix way of having whole-system configuration, while nice (and I really like it) is not what a user wants for reconfiguring the chainloader that loads Debian or Windows on the same machine, for example (that is, the first loader should NOT be reconfigured by Guix.  Ideally, Guix wouldn't need to know it exists).  Also, I question whether we want to support this use case in 2025.  There should be project decisions about it.

Personally, I just use qemu-system-x86_64 and emulate other systems (Windows and MacOS X) that way, and I use podman to emulate Debian, RedHat and stuff.  So I don't need to have a weird system I don't trust on the bare metal.  At that point, I don't need chainloading or weird foreign menu-entry support either.

To summarize, we should decide whether we boot only Guix.  If we do, boot only Guix.  That's it.  No chainloading required.

That's not to say that the USER can't configure the system so it boots something other than Guix--just that Guix doesn't do that.  What I mean to say, where does the Guix-responsible time begin when booting?

(For memtest86, UEFI can just have an extra file in the EFI boot volume for that.  Or we can just always provide memtest86 in Guix and add it to our boot config; or boot it from DVD, or from USB flash drive the one time you need it...)

Also, if you make it too complicated (and that happens earlier than you think... *hides*), you WILL eventually cause all your users not to be able to boot their computers anymore (due to a bug).

Anyway, booting is usually harder on CISC systems.
So there's the UEFI standard.  Even u-boot supports it (see Embedded Base Boot Requirements (EBBR) specification; including graphics), and it's mandatory for RISC-V servers.

amd64 BIOS machines are now probably all in the museum.  But we can boot those with grub without chainloading.
Or we could boot u-boot on bare metal (on amd64!), then chainload grub-efi from that using u-boot's UEFI providing.  But why?

>On ARM, Bootroms often support multiple way of booting (like multiple offsets from the start of the block device, MBR + fat32 partition, etc), and sometime a given way is incompatible with what the user wants (GPT instead of MBR). I'm unsure if Guix managed to not have situations that shows this or not.

Guix does not explicitly have abstractions like "from here to here on the disk A, there's this magical blob, don't stomp on it" and so on.

(There's already the buildroot project.  We could scrape how to boot systems (especially configuration, from which we could infer what magical blobs are where) from there.  Also, which u-boot version to use.  Which IS important.  Otherwise it won't boot)

>MLO can also be on a FAT partition, with special requirements for the partitioning table.

Exactly.  Constraints like this are common--and often for good reason.  Do you want to support loading OS bootloaders on extended partitions in the CPU's mask rom bootloader?  Probably not.  How about exfat?   Hell no.  Even the reader for loading a kernel from FAT16 is very hard to get small (and secure) enough (it's possible, though).  What if the first partition you boot is so far in the disk that you need more than a 32-bit sector number?  That would be annoying.  And so on.

Thankfully, there is no business incentive for CPU vendors to make this more complicated than it needs to be since there is no advantage in "hey we boot in this weird way".  That's why they are trying to standardize on UEFI, and usually contribute the implementation themselves.

>Now these are important to document I think, especially when the offset can end up inside GPT or MBR partitions, especially if the u-boot image becomes too big over time.

>(if we don't already, we'd need a check for that, and your proposal seems to enable to do that in a more elegant way).

We don't check for that.

Also, I think the bigger problem is if the number of used GPT entries (specifically, the entries in the GPT "directory"; specifically not necessarily the partition contents themselves) become too many and it scribbles over u-boot (or grub) that way.

>Or can we somehow move that into some structure and abstractions where we clearly define why we choose this method over others?

We could--but should a distribution do that on its own?  It's a LOT of work to maintain that--and new CPUs come out regularily (so many models!!!  So many!).

I'm totally for it if someone wants to maintain it--I just want to stress that this is not a fire-and-forget thing.

>This also brings the next question about /boot. In some cases that looks 100% controlled by Guix and it is re-generated during reconfiguration in certain cases. Is that on purpose?

Yes.  What else would we do?  After all, /boot/grub/grub.cfg (etc) has to be a GC root.

Note that, on Guix, usually /boot is on / anyway, and for example I boot "/" with full disk encryption.

If you mean /boot/efi , we should totally be a good tenant there (I think we are) and not zap everyone else.

>that, while code exists for some ARM SOCs (like some Allwinner chips), there is no tool to just do that (no update-u-boot)?

There's no tool to do that for most ARM 32-bit.  Traditionally, that's because the installation process is so simple nobody bothered to write scripts for *that*.  Also, totally inane differences like "this SOC reads from 0x60000 at boot", "that SOC reads from 0x67000 at boot", that someone has to maintain.  SIGH.

Anyway, in general I like this GCD.

Half-punting the installation to grub-install and half- to genimage and guix has always rubbed me the wrong way (what if they disagree?).  I guess in practical systems a kind of hybrid will happen since once it works once nobody wants to touch it again.

I'm in favor of cleaning it up.

Please let's also think about the case when you switch bootloaders and then go back to a generation which had the previous bootloader.  Will that use the new bootloader?  There are good arguments for yes, and good arguments for no.

[1] Not that simple in "trusted firmware" stuff anymore

Send a report that this bug log contains spam.