Thank you very much for filing a bug report. I had considered doing that
myself, but I don’t know enough about the cause to create the bug
report. And I can’t “reproduce” the error using the reportbug program.
It would be great if you could post the bug number or a link
https://bugs.debian.org/xxx to it here, so I can follow the issue there.
Heiko
Am 12.03.26 um 22:41 schrieb Aaron Rainbolt:
On Thu, 12 Mar 2026 00:17:05 -0400
Aaron Rainbolt <[email protected]> wrote:
On Wed, 11 Mar 2026 21:32:04 -0400
Aaron Rainbolt <[email protected]> wrote:
... snip ...
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
Small update, it looks like this is a case of the raspi-firmware
package in Trixie being too old. Raspberry Pi OS is able to boot (well,
load the kernel and initramfs anyway, I didn't get bootup to work all
the way, but not because I couldn't, just because I didn't) with a
hybrid MBR configuration similar to what the Trixie cloud image is
using. Furthermore, the hybrid MBR layout also works on a Trixie cloud
image if I copy over the start*.elf and fixup*.dat files from a
Raspberry Pi OS firmware partition to the Trixie cloud image firmware
partition.
I'll be filing a bug report in Debian for this in the near future.
--
Aaron
