** Description changed: [ Impact ] When upgrading from questing: all flash-kernel calls fail (resulting in repeated failure to apt upgrade). When upgrading from noble (once questing goes EOL): potential for non-booting system after *apparently* successful upgrade. [ Test plan ] This has already been carried out using a couple of local builds, but should be re-verified with the official archive build. For each affected $image (Ubuntu Server for Raspberry Pi, and Ubuntu Desktop for Raspberry Pi): * With spare SD card, flash $image from questing * Boot card, run through upgrades, reboot * sudo apt install flash-kernel # set flash-kernel to manually installed * sudo do-release-upgrade * Run through upgrade, checking that the upgrade does *not* attempt to remove flash-kernel * After upgrade test flash-kernel; this should fail complaining that Raspberry Pi is not supported * Repeat procedure, but use: sudo do-release-upgrade --proposed * After upgrade test flash-kernel; this should succeed * Repeat the procedure with noble, but skip do-release-upgrade and download the installer direct from the archive to test the upgrade path from noble: * https://archive.ubuntu.com/ubuntu/dists/resolute/main/dist-upgrader-all/current/resolute.tar.gz * https://archive.ubuntu.com/ubuntu/dists/resolute-proposed/main/dist-upgrader-all/current/resolute.tar.gz + + For the flash-kernel task, for each $image (server and desktop): + + * With spare SD card, flash $image from noble + * Boot card, run through upgrades, reboot + * sudo apt install flash-kernel # set flash-kernel to manually installed + * sudo sed -i -e 's/noble/resolute/g' /etc/apt/sources.list.d/ubuntu.sources + * sudo apt update + * sudo apt dist-upgrade + * Cancel the update and check the output was *not* going to update the meta-package, but *was* going to update flash-kernel + * Enable proposed; adjust pin priority to allow resolute-proposed to be included in general updates + * sudo apt update + * sudo apt dist-upgrade + * Check apt was going to remove flash-kernel and update the meta-package [ Where things could go wrong ] The changes are gated on the inclusion of the raspi seeds, thus testing can be limited to the Raspberry Pi images. Both server and desktop images must be tested given that the upgrades involve substantially different package sets that may interact with the changes differently. The upgrade may be prevented from working at all (by presenting a selection that the resolver cannot handle), although that's a substantially less harmful scenario than that which may occur upgrading from noble once questing goes EOL. The biggest danger is the upgrade may still result in an unbootable system if, for some reason, piboot-try *doesn't* get installed, but the test cases above should guard against that possibility. [ Original description ] There have been a number of bugs (filed erroneously against flash- kernel, though quite understandably given this *appears* to be where the errors occurs) indicating people have managed to upgrade *without* piboot-try getting pulled in, despite it being in the relevant meta packages for both server and desktop on the Raspberry Pi. Given the raspi entries have been removed from flash-kernel in resolute (i.e. only piboot-try is functional on the Pi under resolute), the installation of piboot-try and removal of flash-kernel should be forced when upgrading to resolute if the raspi meta-packages are present on the system.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2151216 Title: [SRU] Force switch to piboot-try on Raspberry Pi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/2151216/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
