kernel upgrade via apt 5.11.0.1015-raspi kills the OS on Raspberry Pi4B

[The Pthyister]

OK, so I've already killed three RPi4B Ubuntu installs (1 Ubuntu Server, 2 Xubuntu Desktops) by installing the recommended apt package(s) for the firmware and especially the kernel into version 5.11.0.1015 -- I've already written a comprehensive summary on the issue on AskUbuntu's side @ https://askubuntu.com/questions/1353872/raspberry-pi4b-64bit-21-04-5-11-kernel-trees-1014-raspi-1015-raspi-apt

The Ubuntu Server one was a fresh one and I literally did nothing else except apt update and apt upgrade straight out of the box from an image that I etched using the latest version of 'rpi-imager'. I ran the OS from a never-before-used, fresh USB stick as my attempt to get some sort of a working boot loader that I could then try to rsync/copy to the boot parts of the other Ubuntu builds that were broken by this very same update. No such luck! I would expect a _lot_ of broken OS installs headed your way; I did try to contact the devs two weeks ago when my first system got fried due to getting the update from the 'hirsute-proposed' repository ... Geez.

Under the /var/log/ of my first fried OS, I have absolutely no errors or warnings, and I've included i.e. my 'dmesg' output as for the installed stuff here: https://paste.ubuntu.com/p/SXnzTTsNtS/ -- that indeed was the last time the system booted.

I'm really in a tough spot due to this because now I've got two dead systems and no apparent solution to fix it! :(

[The Pthyister (pthyister)]

I tried swapping different setups that I have, I've now tried it with two different firmware versions, one from May and the other from 6th of July (which is the most current version). It's either the "cursor of doom"-screen (on two of the Xubuntu desktop installs) or the "rainbow screen of death" (on the fresh 64-bit Ubuntu Server).

On the one that boots into the blinking cursor, none of low level boot bypass keys work. The disk utilization led stays.

RPiOS and other OS's work just fine, and both of those systems that had been working previously, had been running without much troubles since 21.04 hirsute came out.

Please advice, as, like I just noticed, this has the possibility to affect every single user installing the 5.11.0.1015-raspi update from the apt packages.

I'd need all the help restoring my bootloader to those two of my systems, they worked perfectly well and I wouldn't want to ditch and rebuild them. :(

[The Pthyister (pthyister)]

Okay, I solved this by making yet another Ubuntu Server test install, updating it to the 1017-raspi kernel, now that it was available, and copying the boot partition data (apart from meta-data, network-config and user-data + my own config-files) on top of the files on the boot partition, and it worked! :) My builds were brought back to life! :)))

[Dave Jones (waveform)]

I'm unable to replicate the issue of a typical apt upgrade to the linux-raspi -1015 kernel on hirsute server breaking boot, with either SD card storage or a USB as the root device.

Copying things between boot partitions can be done as a temporary fix for things, but ultimately (as discussed on IRC), you want to use "sudo flash-kernel" after a successful boot to ensure that the kernel & initrd on the boot partition match whatever's on the root (including modules etc).

On the Xubuntu desktop question: how exactly did you set up the Xubuntu desktop? There's no official release of Xubuntu for the Pi, so I'm guessing this was either an Ubuntu server or a desktop image onto which the xubuntu-desktop package was installed?

[Paul Broadhead (pjbroad)]

I think I have the same issue but I'm not sure.

I have a Rasp Pi 400 that I've been running Ubuntu 21.10 desktop (vanilla Gnome via the vanilla packages) on for about a month. I'm booting directly from a USB attached disk. This weekend I did updates as I do most days but this time the system will no longer boot. I'm not familiar with the boot process on Arm/PIs so have been unable to fix it. I needed the machine so I used a fresh install on a different disk and keeping to 21.04. Today, missing Gnome 40, I decided to upgrade using "do-release-upgrade -d". All looked fine until the restart, the machine fails to boot.

I'll try recovering the installs using the suggested method but it could be an issue with the latest kernel.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Juerg Haefliger (juergh)]

Are you still having issues when running 22.04 jammy?

[Paul Broadhead (pjbroad)]

> Are you still having issues when running 22.04 jammy?

Sorry, I'm no longer running Ubuntu on the device.

[Juerg Haefliger (juergh)]

Thanks for the feedback. Closing the ticket. Please open a new ticket if you come across the issue again in the future.