On Sat, 3 May 2025 19:43:03 +0300 =?UTF-8?Q?Martin=2D=C3=89ric_Racine?=
<martin-eric.rac...@iki.fi> wrote:
> la 3.5.2025 klo 17.47 Martin-Éric Racine (martin-eric.rac...@iki.fi)
kirjoitti:
> >
> > la 3.5.2025 klo 17.41 Julian Andres Klode (j...@debian.org) kirjoitti:
> > >
> > > On 3 May 2025 15:03:18 CEST, "Martin-Éric Racine"
<martin-eric.rac...@iki.fi> wrote:
> > > >la 3.5.2025 klo 14.42 Chris Hofstaedtler (z...@debian.org)
kirjoitti:
> > > >>
> > > >> Control: tags -1 + moreinfo unreproducible
> > > >>
> > > >> On Fri, May 02, 2025 at 08:14:37PM +0300, Martin-Éric Racine
wrote:
> > > >> > pe 2.5.2025 klo 19.44 Chris Hofstaedtler (z...@debian.org)
kirjoitti:
> > > >> > >
> > > >> > > On Sun, Apr 13, 2025 at 10:23:17AM +0300, Martin-Éric
Racine wrote:
> > > >> > > > Is there any way I can help the maintainers pinpoint the
source of the problem?
> > > >> > >
> > > >> > > This bug needs two things:
> > > >> > >
> > > >> > > 1) A full reproducer step list, starting from "I have
nothing but an empty
> > > >> > > amd64 VM".
> > > >> >
> > > >> > There isn't much to reproduce:
> > > >> > 1) Start with a fully functional host running Bookworm with
GRUB-EFI
> > > >> > on a brtfs filesystem created using d-i/Bookworm's default
@rootfs
> > > >> > subvolume name.
> > > >> > 2) Change APT sources from Bookworm to Trixie.
> > > >> > 3) Dist-upgrade.
> > > >> > 4) Reboot.
> > > >> > 5) Find the above kernel panic.
> > > >> > 6) Using Bookworm d-i's rescue mode via EFI, APT pin and
downgrade
> > > >> > grub* to Bookworm. All other packages remain at Trixie versions.
> > > >> > 7) Reboot.
> > > >> > 8) The host boots normally.
> > > >>
> > > >> I've followed these steps today, and cannot reproduce the problem.
> > > >> The upgraded VM boots successfully.
> > > >
> > > >I beleive you. Again, googling this exact error mostly pulls up
> > > >reports of this failing on ASUS motherboards of various models.
> > > >
> > >
> > > Unfortunately some firmware is just broken and there isn't much
that can be done about that.
> >
> > Sorry, but that's a really pitiful excuse for breaking something that
> > worked fine until now.
> >
> > > As we're moving towards more upstream solutions that use more
parts of the firmware, such as EFI LoadFile2 protocols for loading the
initrd, more hardware will break.
> >
> > I cannot help but wonder what is the point of breaking something as
> > fundamental as a bootloader, even just for the sake of adopting new
> > ways of doing things. It can only result in fewer and fewer people
> > using Debian.
>
> Check this post out:
>
>
https://forum.level1techs.com/t/ubuntu-upgrade-bricked-os-initramfs-unpacking-failed-invalid-magic-at-start-of-compressed-archive/215981
>
> It's on Ubuntu, but the error is similar. Key point: something among
> the boot messages (see screenshot there) suggests that either GRUB or
> Linux don't know how to boot off a btrfs partition anymore. Sure
> enough, someone in the thread says that once they made a fresh install
Hello,
I am running two very similiar pre-upgrade setups to Martin-Éric
(Bookworm, btrfs install via Debian Installer with @rootfs) but on
vastly different platforms - an Asus Ryzen B550 and a Lenovo 11th Gen
Tiger Lake-LP laptop. I also have Asrock Ryzen B450 and B550 machines
standing by for additional testings if applicable. For at least one of
these I was planning a fresh Trixie btrfs install once it is out.
Seems to me this bug is for now limited to Asus boards (so far I saw
Asus H61 and Z68 chipsets mentioned in the forum links you provided)
with Sandy bridge CPUs and btrfs. Anyway, my question for you
Martin-Éric, since I got a bit lost in your replies with mantainers, how
would I try to verify if my machines will survive the Trixie upgrade or
not (without actually fully upgrading for now)?
If I gather you correctly, if "Debian GNU/Linux 13 (trixie) amd64 -
netboot mini.iso 20241227" boots in UEFI mode, the system will also
probably boot after upgrade to Trixie?
BTW I feel your frustration, considering all the architectures Debian
supports, that your somewhat-aged but pretty mainstream system is now
(hopefully just temporarily) not supported.
Regards,
Staš
P.S. We still had some retired Sandy/Ivy Bridge H61/H67 workstations
(mostly Gigabyte boards though) lying around a couple weeks ago, but we
donated them to charity, shame as they could have come handy now.
