Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #390145 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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@iki.fi> - 2025-04-18 18:20 +0200
    Bug#1102160: upgrade-reports: Bookworm to Trixie [amd64][EFI] initramfs unpacking failed invalid magic at start of compressed archive Felix Zielcke <fzielcke@z-51.de> - 2025-04-18 18:50 +0200
      Bug#1102160: upgrade-reports: Bookworm to Trixie [amd64][EFI] initramfs unpacking failed invalid magic at start of compressed archive Felix Zielcke <fzielcke@z-51.de> - 2025-04-19 07:50 +0200
        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@iki.fi> - 2025-04-19 08:10 +0200
    Bug#1102160: upgrade-reports: Bookworm to Trixie [amd64][EFI] initramfs unpacking failed invalid magic at start of compressed archive Paul Gevers <elbrus@debian.org> - 2025-04-19 08:50 +0200
      Bug#1102160: upgrade-reports: Bookworm to Trixie [amd64][EFI] initramfs unpacking failed invalid magic at start of compressed archive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-04-19 11:50 +0200

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

On Fri, 18 Apr 2025 11:17:06 +0300
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <martin-eric.racine@iki.fi>
wrote:
> On Thu, 17 Apr 2025 10:13:15 +0300
> =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <martin-eric.racine@iki.fi>
> wrote:
> > to 17.4.2025 klo 10.03 Pascal Hambourg (pascal@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@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

[toc] | [next] | [standalone]

#390148

Am Freitag, dem 18.04.2025 um 19:10 +0300 schrieb Martin-Éric Racine:
> 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
> 

Hi Martin-Éric,

FUSE support in GRUB 2 is only used for the grub-mount binary. And not
at all in the actual booting code loaded from EFI/BIOS.

You could though test the fs drivers of it with grub-mount:

grub-mount /dev/sda2 /mnt (replace sda2 with your / partition)
sha1sum /mnt/@rootfs/boot/initrd.img-6.12.20-amd64
sha1sum /@rootfs/boot/initrd.img-6.12.20-amd64

both commands should output the same hash sum.
And yes, this is safe with a mounted fs because the GRUB fs code is
100% complete read-only.

Felix

[toc] | [prev] | [next] | [standalone]

#390200

Am Freitag, dem 18.04.2025 um 21:17 +0300 schrieb Martin-Éric Racine:
> Hey Felix,
> 
> pe 18.4.2025 klo 19.39 Felix Zielcke (fzielcke@z-51.de) kirjoitti:
> > 
> > Am Freitag, dem 18.04.2025 um 19:10 +0300 schrieb Martin-Éric
> > Racine:
> > > 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.
> 
> > FUSE support in GRUB 2 is only used for the grub-mount binary. And
> > not
> > at all in the actual booting code loaded from EFI/BIOS.
> > 
> > You could though test the fs drivers of it with grub-mount:
> > 
> > grub-mount /dev/sda2 /mnt (replace sda2 with your / partition)
> > sha1sum /mnt/@rootfs/boot/initrd.img-6.12.20-amd64
> > sha1sum /@rootfs/boot/initrd.img-6.12.20-amd64
> > 
> > both commands should output the same hash sum.
> > And yes, this is safe with a mounted fs because the GRUB fs code is
> > 100% complete read-only.
> 
> Exactly how does the above address the issue I reported?

Well, then we at least know that the bug is not in GRUB's btrfs
filesystem code
So your initramfs should be correctly read by it

> Martin-Éric
> 

[toc] | [prev] | [next] | [standalone]

#390202

la 19.4.2025 klo 8.43 Felix Zielcke (fzielcke@z-51.de) kirjoitti:
>
> Am Freitag, dem 18.04.2025 um 21:17 +0300 schrieb Martin-Éric Racine:
> > Hey Felix,
> >
> > pe 18.4.2025 klo 19.39 Felix Zielcke (fzielcke@z-51.de) kirjoitti:
> > >
> > > Am Freitag, dem 18.04.2025 um 19:10 +0300 schrieb Martin-Éric
> > > Racine:
> > > > 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.
> >
> > > FUSE support in GRUB 2 is only used for the grub-mount binary. And
> > > not
> > > at all in the actual booting code loaded from EFI/BIOS.
> > >
> > > You could though test the fs drivers of it with grub-mount:
> > >
> > > grub-mount /dev/sda2 /mnt (replace sda2 with your / partition)
> > > sha1sum /mnt/@rootfs/boot/initrd.img-6.12.20-amd64
> > > sha1sum /@rootfs/boot/initrd.img-6.12.20-amd64
> > >
> > > both commands should output the same hash sum.
> > > And yes, this is safe with a mounted fs because the GRUB fs code is
> > > 100% complete read-only.

Same checksum. However, manually executing this tells us nothing. It's
performed on a filesystem that's already available. It doesn't
simulate GRUB attempting to cold mount a system on a booting host.

> > Exactly how does the above address the issue I reported?
>
> Well, then we at least know that the bug is not in GRUB's btrfs
> filesystem code
> So your initramfs should be correctly read by it

There seems to be two issues here:

1) A magic error upon loading initrd. It also affects the Trixie
rescue mode via UEFI (but not via BIOS). Bookworm rescue mode boots
both ways.
2) fuseblk reporting an unsupported subvol option on Trixie.

It's a simply a/b test: Downgrading grub* to Bookworm made the host
bootable again.

Martin-Éric

[toc] | [prev] | [next] | [standalone]

#390203

[Multipart message — attachments visible in raw view] — view raw

Hi Martin-Eric,

On 18-04-2025 18:10, Martin-Éric Racine wrote:
> I would really hope the release team to step in on this one.


And what do you expect from the Release Team?

Paul

[toc] | [prev] | [next] | [standalone]

#390209

On 19/04/2025 at 10:19, Martin-Éric Racine wrote:
> 
> Will the release team publish Trixie fully knowing that btrtfs hosts
> will no longer be bootable via UEFI?

Not all btrfs hosts are affected. A fresh UEFI trixie btrfs virtual 
machine boots fine on bookworm QEMU+OVMF. IIUC you wrote that trixie 
installer is affected too on your host, but it does not use btrfs to 
boot so non-btrfs systems may be affected.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web