On Wed, 11 Mar 2026 21:32:04 -0400 Aaron Rainbolt <[email protected]> wrote:
> Hi, > > I am able to reproduce this issue using the the latest daily Trixie > image, 'debian-13-raspi-arm64-daily.tar.xz'. I am attempting to boot > it on a Raspberry Pi Model 4B. > > Steps to reproduce: > > * Download the iamge from https://raspi.debian.net/, clicking the > 'Image download' link underneath 'Debian 13 "Trixie" (Stable)'. > * Unpack the image with `tar -xf debian-13-raspi-arm64-daily.tar.xz`. > * Flash the image to an SD card with `sudo dd if=./disk.raw > of=/dev/sda bs=4M status=progress oflag=direct; sync;` (note that I'm > using a USB SD card "reader") > * Insert the SD card into the Raspberry Pi > * Insert all peripherals (network, keyboard, display) > * Insert the power cable > > The rainbow screen appears, and the SD card read light turns on and > stays on for a bit. The rainbow screen then continues to be displayed > indefinitely, and the SD card read LED begins blinking in a steady > pattern, 7 short blinks at a time with some space in between each > group of blinks. > > According to > https://www.raspberrypi.com/documentation/computers/configuration.html#led-warning-flash-codes, > 7 short flashes indicates that the kernel image could not be found. I > plugged the SD card into my normal work PC, mounted the firmware > partition (`/dev/sda15`) to `/mnt`, and then explored around. There is > a `vmlinuz-6.12.73+deb13-arm64` file present, and config.txt contains > a line that reads `kernel=vmlinuz-6.12.73+deb13-arm64`, so it seems > like the image *should* work. Furthermore, the image is using a hybrid > GPT/MBR partition table, and the first partition on the MBR > partition table is the FAT32 boot partition, so I don't really > understand *why* this isn't working yet, I just know it isn't. > > I'll probably report back with more research on this soon-ish. Alright, I finished my research and I think I know what's happening. The contents of the firmware partition (`/boot/firmware`) are fine. I checked them against a grml-debootstrap-built RPi image which was able to successfully boot, and they were so close to identical that the boot issues couldn't be explained because of faulty files. The main difference between my working grml-debootstrap image and the not-working cloud image is that the grml-debootstrap image is MBR-only, while the cloud image is a hybrid between MBR and GPT. What the cloud image tries to do at the moment is basically this: * There is a normal GPT partition table on the disk. Partition 1 is the root filesystem, partition 2 (which actually show up as partition 15 in `lsblk`) is the FAT32 firmware partition. * There is also an MBR partition table on the disk. This is normal for GPT-partitioned disks, but in most scenarios, this MBR partition table only includes a single "GPT protective MBR" partition (type 0xEE) that covers the entire disk, in order to tell MBR-only partitioning programs "stay away from this". * The cloud image is slightly different here; its MBR partition table contains three separate partitions. Partition 1 is a FAT32 partition that exactly overlaps the firmware partition on the GPT partition table. Partition 2 is a GPT protective MBR partition that covers the first 2048 sectors of the disk. Partition 3 is a GPT protective MBR partition that covers everything from the end of the firmware partition to the end of the cloud image. Partition 4 doesn't exist, the slot is filled entirely with 0x00. The idea, as far as I can tell, is that the Raspberry Pi firmware will see the FAT32 MBR partition, find the firmware and boot files, and boot successfully. Then the kernel will notice the GPT protective MBR partitions and use the GPT partition table, allowing it to find the rest of the system's files. The issue with this is that the firmware on the Raspberry Pi 4B seems to try to detect GPT-partitioned SD cards and refuse to boot from them. If partition 2 on the SD card is a GPT protective MBR partition, the system will not boot, and a "kernel not found" error code will be flashed on the disk access LED. I don't know of anywhere this is documented, I discovered this by trial and error. If I change the type code on partition 2 to 0x83 instead of 0xEE, the firmware will successfully boot the kernel. This isn't a total solution though, because changing the partition that covers the first 2048 sectors of the disk to a type other than 0xEE results in the Linux kernel no longer recognizing the disk as a GPT disk. I end up stuck at an initramfs prompt. What ended up working, oddly enough, was to place the GPT protective MBR partition covering the first 2048 sectors in the *third* partition slot in the MBR table. I then blanked out the second slot entirely, so that the MBR now looks like this: * Partition 1: FAT32 partition overlapping the firmware partition in the GPT table * Partition 2: Nothing, all bytes in this slot are 0x00 * Partition 3: GPT protective MBR covering the first 2048 sectors of the disk * Partition 4: Nothing, all bytes in this slot are 0x00 Even though partition 3 uses type 0xEE, the RPi4 firmware finds and boots the kernel properly. The GPT protective MBR partition in the third slot also is enough for Linux to figure out that this is a GPT-formatted disk, so ultimately everything "just works" with this setup. I'm not sure if this is particularly safe, since it depends on the Raspberry Pi firmware only checking the second (or perhaps first two) partitions for GPT protective MBR partitions, and depends on the Linux kernel continuing to recognize a disk as GPT-formatted even if only a small part of it is covered by a protective partition. This might also not work on newer (or older) Raspberry Pi versions. But, with Debian Trixie, on a Raspberry Pi 4B with 8 GB RAM, this works. The alternative would be to switch to an MBR-only partition table, which is what grml-debootstrap currently does. This is probably safer in the long run, but maybe there are reasons to avoid this. -- Aaron
pgpJhf0XetKK7.pgp
Description: OpenPGP digital signature
