Raspberry Pi is unsupported due to GPT-only partition table

[MoralCode]

I'm trying to follow https://mrguitar.net/?p=2605 to revive my raspberry pi server with bootc (with minor modifications since i only have a raspberry pi 3 not a pi 4)

While troubleshooting, I discovered #551 (comment), which seems to point to the partition table configs being based on those from fedora iot (where arm builds used dos partitions explicitly for raspi compatibility). It seems like this setting was changed in bib for arm builds so that everything could be gpt instead.

I did some further reading and it seems like the weird gpu-first way that a raspi boots depends on having a dos format partition table as it looks for critical files in the "first msdos partition on the card"

Can bib be fixed so that the bootc images it generates can boot on a raspi like full Fedora 40 can?

[MoralCode]

Ping as requested @supakeen

[supakeen]

Thank you. We have working partition tables for the Pi's in images.

@mvo5 @achilleas-k is there a prefered way we would do this? Do we want to change the partition table to a Pi-compatible one or perhaps stick it behind a (config) flag?

[ondrejbudai]

If I'm reading the log correctly, this is the last version of bib before we switched aarch64 to GPT: quay.io/centos-bootc/bootc-image-builder:sha256-465c82cf63b450408fc61f3962fe76423b6c9a3c5bf84b55353605e3604f8c4d

Alternatively, you can build one yourself from git.

@achilleas-k is currently working on new partitioning. While GPT vs. MBR is not in scope, it should be a simple addition, that I would absolutely be in favor of. :)

[supakeen]

The alternative would be, as suggested by @mvo5 in #586 to introduce an explicit switch to use a 'Pi-compatible' partition table. We can use the same partition table as we use for Fedora IoT and Fedora Minimal on aarch64 as we know these work.

However, as @ondrejbudai pointed out in his experiments. bootupd does not copy the necessary firmware and dtb into /boot when installing the bootloader. The linked blogpost does this manually after-the-fact (by mounting the disk image and moving the appropriate files around) and in the experiment (https://github.com/ondrejbudai/fedora-bootc-raspi/tree/main) there's a hacky bootupctl way to do it at build time.

That's to say that if we provide an easy way to switch partition layout there are still things that need to be done manually to make the image bootable. There's an issue here: coreos/bootupd#651 related to that.

[MoralCode]

Poking through some of these links, it sounds like other SBC's also use a similar "read files from the root of the first MBR partition found" method of starting up, so maybe its worth generalizing this for all SBC's. Even if not all of them are "supported"/in there by default i think its important to avoid breaking compatibility with other SBC's, so that people would only need to add their SBC partition table definition and possibly specify what firmware to install/copy to the efi partition for it to work

[achilleas-k]

@achilleas-k is currently working on new partitioning. While GPT vs. MBR is not in scope, it should be a simple addition, that I would absolutely be in favor of. :)

I'll add it to config then.

[ondrejbudai]

Poking through some of these links, it sounds like other SBC's also use a similar "read files from the root of the first MBR partition found" method of starting up, so maybe its worth generalizing this for all SBC's. Even if not all of them are "supported"/in there by default i think its important to avoid breaking compatibility with other SBC's, so that people would only need to add their SBC partition table definition and possibly specify what firmware to install/copy to the efi partition for it to work

Agreed! But in the current setup, I strongly believe that bootupd should be the one responsible for actually installing the firmware files. Implementing this in bootc-image-builder feels a bit out of the place. It would be nice, though, if we can somehow share the config between bootupd and bootc-image-builder. We have some ideas floating around about this.

[cgwalters]

But in the current setup, I strongly believe that bootupd should be the one responsible for actually installing the firmware files.

Thanks yes! Agreed and filed as coreos/bootupd#766

(That said I'd also note I am trying to merge bootupd into bootc, xref containers/bootc#874 which would help close the loop here)