Quite a lot of ARM SBCs don't support GPT partitioning so on raw images we explicitly still use traditional partitioning, which is explicitly allowed as part of the UEFI spec. Kiwi needs to look at all the actual details of what the arm images are doing including things like offsets to ensure we don't regress across a bunch of supported devices.

well, the real significant difference here is that the new image is GPT-labeled, not MBR-labeled. That's why everything looks different. GPT doesn't really have the "bootable" concept at all (well, except as a sort of MBR-backwards-compatibility thing). I'm trying to find out now if Pis boot from GPT at all. If not we would just need to switch this image to MBR labelling.

...yeah, kiwi can do hybrid MBR or straight MBR. so I guess we just need to adjust the template accordingly. Looks like we'd want to set `force_mbr` in the <type> definition, I think.

Will a hybrid MBR work? If so, then we can set BootDiskCore and ServerDisk definitions to do that.

They don't, well some of the later generations can, but generally they don't and nor do a bunch of other arm SBCs. That is why we have never moved to GPT.

(In reply to Neal Gompa from comment #4)
> Will a hybrid MBR work? If so, then we can set BootDiskCore and ServerDisk
> definitions to do that.

I believe Hybrid MBR is a x86 invention so I am not sure.

I think we should just go with straight MBR like imgfac was using for now at least. We can always consider changing it in future but that should be treated as a change. This should be only for aarch64 hardware-targeted disk images, though.

Here you go: https://pagure.io/fedora-kiwi-descriptions/pull-request/111

Alright, that's been merged, so the next compose should have MBR for AArch64 images.

I can run another Rawhide later to see the results, I guess. Once we're done with F39 EOL.

OK, so, with latest Rawhide, we get this:

[adamw@xps13a nightlies]$ fdisk -l Fedora-Server-Host-Generic-Rawhide-20241202.n.0.aarch64.raw 
Disk Fedora-Server-Host-Generic-Rawhide-20241202.n.0.aarch64.raw: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7a3893eb

Device                                                       Boot   Start      End  Sectors  Size Id Type
Fedora-Server-Host-Generic-Rawhide-20241202.n.0.aarch64.raw1         2048   206847   204800  100M ef EFI (FAT-12/16/32)
Fedora-Server-Host-Generic-Rawhide-20241202.n.0.aarch64.raw2       206848  2254847  2048000 1000M ea Linux extended boot
Fedora-Server-Host-Generic-Rawhide-20241202.n.0.aarch64.raw3      2254848 20971486 18716639  8.9G 83 Linux

So, it's MBR, but it's not the same as the F41 image. I see four main differences:

1. The first partition is of type ef (EFI system partition) on the Kiwi-built image, type 6 (FAT16) on the imgfac-built image. If it's an ESP, Kiwi is more correct here.
2. The first partition is marked bootable on the imgfac-built image, not on the Kiwi image. The implications of this are pretty fuzzy, on the whole, but we might want to make it more like the old image. I *think* there's a Kiwi setting we can use for this, I'll dig it up later.
3. The second, 1G partition is type ea on the Kiwi-built image, type 83 on the imgfac-built image. I assume this is a /boot partition? Not sure which type is best, or if it matters.
4. The third partition is type 83 on the Kiwi image, type 8e on the imgfac image. 83 is "Linux", 8e is "Linux LVM". Not sure if it matters, or which is 'correct'.

Paul, Peter, any thoughts on those?

oh, the EFI partition is also smaller on the Kiwi image. Not sure if we need it to be bigger. anaconda currently, I believe, tries to make it between 600M and 2G in size. a lot of that is about accommodating firmware, I think.

It can't be too big or it'll stop being FAT16, and some things don't support FAT32 ESP.

The limit for FAT16 is 2G, IIRC, which is probably why the "bigger ESP" Change picked 2G as the upper limit.

(In reply to Adam Williamson from comment #12)
> oh, the EFI partition is also smaller on the Kiwi image. Not sure if we need
> it to be bigger. anaconda currently, I believe, tries to make it between
> 600M and 2G in size. a lot of that is about accommodating firmware, I think.

What size do you want? I could make it as big as 500MB, but I think it's a bit much given that the only firmware we install there right now is the RPi stuff, and that seems to fit in 100MB.

Paul, can you confirm whether current images are bootable? Thanks!

Created attachment 2077207 [details]
F42 Server on RPi4

I tried Fedora-Server-Host-Generic-42-20250219.n.0.aarch64 on Raspberry Pi 4 and it doesn't boot.

Just to check - you wrote it with arm-image-installer as usual? And a similarly-written F41 image boots?

Oh, well, just looking at the images, there's a bit of a big difference. Here's the contents of the first filesystem on the F41 image (type FAT16, size 600MB):

[root@omnibook fedora-comps (tracker-tinysparql-critpath)]# ls /run/media/adamw/DEBC-82AB/
bcm2710-rpi-2-b.dtb       bcm2710-rpi-zero-2-w.dtb  bcm2711-rpi-cm4s.dtb       bcm2712-rpi-cm5l-cm4io.dtb  fixup4cd.dat  fixup.dat       start4cd.elf  start_db.elf
bcm2710-rpi-3-b.dtb       bcm2711-rpi-400.dtb       bcm2712d0-rpi-5-b.dtb      bcm2712-rpi-cm5l-cm5io.dtb  fixup4.dat    fixup_db.dat    start4db.elf  start.elf
bcm2710-rpi-3-b-plus.dtb  bcm2711-rpi-4-b.dtb       bcm2712-rpi-5-b.dtb        bootcode.bin                fixup4db.dat  fixup_x.dat     start4.elf    start_x.elf
bcm2710-rpi-cm3.dtb       bcm2711-rpi-cm4.dtb       bcm2712-rpi-cm5-cm4io.dtb  config.txt                  fixup4x.dat   overlays        start4x.elf
bcm2710-rpi-zero-2.dtb    bcm2711-rpi-cm4-io.dtb    bcm2712-rpi-cm5-cm5io.dtb  EFI                         fixup_cd.dat  rpi-u-boot.bin  start_cd.elf

here's the contents of the first filesystem on the F42 image (type EFI, size 100MB):

[root@omnibook fedora-comps (tracker-tinysparql-critpath)]# ls /run/media/adamw/EFI/
EFI  rpi-u-boot.bin

so yeah, we set up Kiwi to put *literally the pi firmware file* on there, but not any of the other things. From the screenshot it's looking for start.elf and/or fixup.dat, both of which are on the F41 image but not the F42 image.

So, we do need Kiwi to be doing something more here, Neal.

I'm confused because the imgfac snippet I copied doesn't have any of those files: https://pagure.io/fedora-kickstarts/blob/main/f/fedora-disk-base.ks#_58-63

So I'm confused what installs all those files.

Those files are installed by RPM; see: https://src.fedoraproject.org/rpms/bcm283x-firmware/blob/rawhide/f/bcm283x-firmware.spec#_74

(In reply to Adam Williamson from comment #18)
> Just to check - you wrote it with arm-image-installer as usual? And a
> similarly-written F41 image boots?

Yep, wrote it using arm-image-installer. F41 image boots, F42 doesn't.

The /boot partition cannot be of `ef` type or it won't boot on a Pi 3, see: https://github.com/raspberrypi/firmware/issues/1711#issuecomment-1080340451

Tomorrow's F42 and Rawhide builds should have all this fixed with the merge of this: https://pagure.io/fedora-kiwi-descriptions/pull-request/148

OK, I checked today's Rawhide and it looks a lot better. Lukas, can you test today's F42 and/or Rawhide? F42 is still building but should be done soon. Thanks!

Both Fedora-Server-Host-Generic-42-20250221.n.0.aarch64 and Fedora-Server-Host-Generic-Rawhide-20250221.n.0.aarch64 boot on Raspberry Pi 4.

Awesome. Do we have a Pi 3 we can test on also?

Still, the original issue here is clearly fixed, so let's close this. If Pi 3 turns out to have issues, we'll file a new bug.