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 https://github.com/osbuild/bootc-image-builder/issues/551#issuecomment-2245120613, 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 https://github.com/osbuild/bootc-image-builder/pull/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: https://github.com/coreos/bootupd/issues/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 https://github.com/coreos/bootupd/issues/766

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

[supakeen]

@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.

Since these have landed would this now be possible to document or implement (minus the firmware copying).

[MoralCode]

However, as @ondrejbudai pointed out in his experiments. bootupd does not copy the necessary firmware and dtb into /boot when installing the bootloader.

After booting a current build of Raspi OS to my pi3-ish - it seems like theyve moved all the firmware files to /boot/firmware, so maybe this makes it easier for bootupd to do its thing?

[ondrejbudai]

Note that Fedora uses a different firmware and bootloader setup, so unless someone makes a bootc image of Raspi OS, I'm afraid this change is mostly irrelevant for us. :(

[MoralCode]

Note that Fedora uses a different firmware and bootloader setup

Fedora in general or specifically the bootc versions?

so unless someone makes a bootc image of Raspi OS, I'm afraid this change is mostly irrelevant for us. :(

F40 already has arm builds available that claim to support the raspi: https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/ - would that help?

[ondrejbudai]

Fedora in general uses a different firmware and bootloader setup for raspi. But honestly I think it's not that important where the files are located, it's just that bootupd needs to learn how to put extra files anywhere. :)

[ondrejbudai]

ok, GPT vs. MBR support is here: https://github.com/osbuild/images/pull/1085

next thing is custom partition types (raspi3 needs 06 instead of EF for ESP)

[martin-paulus]

next thing is custom partition types (raspi3 needs 06 instead of EF for ESP)

On that note, in the osbuild/images sources (pkg/disk/disk.go) I found the following constant:

	// FAT16BDOSID used for the ESP-System partition
	FAT16BDOSID = "06"

Which is no longer being referenced anywhere, but it is what would make the ESP compatible with Raspberry Pi 3.

[martin-paulus]

Would you welcome a set of pull requests which would introduce a Raspberry Pi-specific partition table type?

The blueprint snippet could look like this, for example:

{
  "customizations": {
    "disk": {
      "type": "rpi",
      "partitions": [
        {
          "fs_type": "vfat",
          "label": "ESP",
          "type": "plain",
          "minsize": "99 MiB",
          "mountpoint": "/boot/efi"
        }
      ]
    }
  }
}

And in images (pkg/disk/disk.go):

const (
	PT_NONE PartitionTableType = iota
	PT_DOS
	PT_GPT
	PT_RPI
)

func getPartitionTypeIDfor(ptType PartitionTableType, partTypeName string, architecture arch.Arch) (string, error) {
	switch ptType {
	case PT_RPI:
		switch partTypeName {
		case "data", "boot", "root", "usr":
			return FilesystemLinuxDOSID, nil
		case "esp":
			return FAT16BDOSID, nil
		case "lvm":
			return LVMPartitionDOSID, nil
		case "swap":
			return SwapPartitionDOSID, nil
		default:
			return "", fmt.Errorf("unknown or unsupported partition type name: %s", partTypeName)
		}
...

[supakeen]

AFAIK all the bits have landed to be able to do this in a blueprint (which we would document). I'd probably prefer that over code changes.

Sadly I haven't been able to validate yet (even though I made some of the PRs) since I've been busy. I hope to get to it soon.

---

Side-question, is the bootupd 'hack' still necessary for bootc to copy the firmware files into ESP?