Bug#1102160: upgrade-reports: Bookworm to Trixie [amd64][EFI] initramfs unpacking failed invalid magic at start of compressed archive

Martin-Éric Racine martin-eric.racine at iki.fi
Fri Apr 18 17:10:08 BST 2025


On Fri, 18 Apr 2025 11:17:06 +0300
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <martin-eric.racine at iki.fi>
wrote:
> On Thu, 17 Apr 2025 10:13:15 +0300
> =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <martin-eric.racine at iki.fi>
> wrote:
> > to 17.4.2025 klo 10.03 Pascal Hambourg (pascal at plouf.fr.eu.org) kirjoitti:
> > >
> > > On 17/04/2025 at 06:01, Martin-Éric Racine wrote:
> > > > ke 16.4.2025 klo 20.40 Pascal Hambourg (pascal at plouf.fr.eu.org) kirjoitti:
> > > >>
> > > >> There may be some silent data corruption when grub reads the initramfs.
> > > >> Can you test with the initramfs on another filesystem type (fat, ext4) ?
> > > >> Can you test with grub for BIOS/legacy boot ?
> > > >
> > > > See above. GRUB-EFI is clearly the culprit. Booting the Trixie d-i in
> > > > rescue mode works in BIOS mode, but not in EFI mode.
> > >
> > > d-i boots in BIOS mode with isolinux, not grub.
> >
> > This still points to GRUB as the culprit. AFAIK the Linux kernel
> > loaded in both modes is the same. The failure to load initrd appears
> > when booting the Trixie d-i via UEFI but not via BIOS. Both modes work
> > fine when booting using the Bookworm d-i. UEFI no longer does with the
> > Trixie d-i.
>
> As a further test, I booted into the host using the Bookworm rescue
> mode, chrooted myself in, then purposely downgraded the host's grub*
> to the Bookworm versions and APT-pinned them to 1000. The host boots
> fine now.
>
> $ dpkg -l | grep grub | awk '{print $2,$3}'
> grub-common 2.06-13+deb12u1
> grub-efi-amd64 2.06-13+deb12u1
> grub-efi-amd64-bin 2.06-13+deb12u1
> grub-efi-amd64-signed 1+2.06+13+deb12u1
> grub-ipxe 1.21.1+git20250317.42a29d56+dfsg-2
> grub2-common 2.06-13+deb12u1
>
> $ uname -a
> Linux p8h62 6.12.21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.21-1
> (2025-03-30) x86_64 GNU/Linux
>
> $ ls /sys/firmware/efi/efivars/
> (a very full directory indeed - I won't copy-paste it here)
>
> Again, this clearly point to Trixie's GRUB-EFI as the culprit.
>
> Meanwhile, my testing host (i386, GRUB-PC) boots fine:
>
> $ dpkg -l | grep grub | awk '{print $2,$3}'
> grub-common 2.12-7
> grub-ipxe 1.21.1+git20250317.42a29d56+dfsg-2
> grub-pc 2.12-7
> grub-pc-bin 2.12-7
> grub2-common 2.12-7
>
> Further googling shows that users of Ubuntu derivatives started
> experiencing similar issues on hosts with a btrfs rootfs about a year
> ago. Given how Ubuntu developers happen to be the key contributors to
> GRUB at Debian, I'd really hope to see a more proactive reaction from
> them to this bug report.

The Debian changelog suggests what caused this:

Someone enabled compiling GRUB with FUSE3 to enhance QEMU support.
The problem with FUSE3 is that it only has very basic support for
btrfs, lacking among other things support for subvolumes. This is a
serious issue considering how widely spread btrfs has become and how
debian-installer uses subvolumes by default whenever someone selects
brtfs as the filesystem type. Rendering hosts unbootable is a big
no-no. I would really hope the release team to step in on this one.

Martin-Éric



More information about the Pkg-grub-devel mailing list