Thursday, 28 May 2026

Failed Update from Ubuntu 24.04 LTS to 26.04 LTS on Lenovo Thinkpad E16

 I have a Lenovo Thinkpad E16 which came with Ubuntu 22.04 pre-installed, along with a 22.04 recovery partition.

A couple of years ago it updated to 24.04 LTS without any trouble (it must have, because I don't remember doing the upgrade...).

Yesterday I upgraded to 26.04 LTS - the upgrade appeared to run ok (no major errors reported), but it completely failed to boot.

I am out of my depth with regard to modern boot systems with EFI, secureboot etc, so with a lot of help from Google Gemini, I got as far as the following diagnosis....before finally giving up and doing a clean install of 26.04 LTS, which worked fine....

Note to self - don't bother with upgrades, carry on with my previous policy of doing a clean install instead!


Technical Bug Report Summary: ThinkPad E16 Boot Failure and Partition Illegibility Following Ubuntu 24.04 to 26.04 Upgrade
Hardware Environment
  • Device: Lenovo ThinkPad E16
  • Storage: 1 TB NVMe SSD (/dev/nvme0n1)
  • Initial Setup: Factory OEM pre-installed Ubuntu 22.04 LTS, upgraded to 24.04 LTS, followed by an upgrade attempt to the 26.04 LTS cycle.
  • Disk Layout: Partition 1 (p1) as VFAT EFI, Partition 2 (p2) as the OEM Ubuntu 22.04 Recovery system, and Partition 3 (p3) as the main Ubuntu root (/) filesystem.

1. Primary Symptoms Observed
Following the 24.04 to 26.04 upgrade process, the host system became permanently unbootable.
  • GRUB Panic: The bootloader consistently threw an immediate initramfs not found error.
  • GRUB CLI Crash: Attempting to manually execute kernel boot parameters from the GRUB prompt (grub>) resulted in an immediate heap corruption crash: alloc magic is broken at 0x52864020: 0, or halted with error: cannot load image.
  • Firmware Safety Rejection: Attempting to force-boot via the physical device identifier in the Lenovo F12 BIOS menu triggered a hard stop firmware failure: failed to boot both main and fallback entries.

2. Diagnosis via Ubuntu 26.04 Live USB
Booting into an official Ubuntu 26.04 Live USB environment was used as the first primary recovery step, resulting in the following state:
  • Chroot Attempt (Partial Success): The system root (p3) and EFI (p1) were mounted under /mnt. Virtual file systems (/dev, /proc, /sys, /run) were bound.
  • GRUB Reinstallation: Inside the chroot sandbox, grub-install and update-grub completed successfully with zero errors. The kernel and initrd files were verified to physically exist on disk with valid file sizes.
  • The Block Disconnect: Despite successful file writes inside the chroot, the resulting binaries could not be read at actual boot. Testing the configurations via grub-emu inside the Live environment consistently triggered graphical freeze dialogues and returned error: no such device <uuid>, proving that the bootloader parsing logic was entirely breaking when mapping the underlying block device hardware.
  • GParted Warning: GParted explicitly flagged partitions p1 and p2 with a warning stating it was “unable to read the contents of this file system.”

3. Diagnosis via Ubuntu 22.04 OEM Recovery System
Switching to the local, on-disk Ubuntu 22.04 OEM recovery partition terminal provided the definitive diagnostic clue:
  • Complete Metadata Invisibility (blkid failure): While tools like parted and file -s could see /dev/nvme0n1p3 as a raw ext4 volume block, running blkid completely failed to register a UUID or file format signature for the partition.
  • NVRAM Purge (No Effect): Utilizing efibootmgr to successfully delete old cached boot records, remounting efivarfs, and cleanly rewriting a brand-new boot path to shimx64.efi failed to resolve the issue.
  • Lenovo Firmware Cleared (No Effect): Toggling Secure Boot off, clearing all cryptographic Secure Boot Keys in the BIOS, restoring default platform factory keys, and performing a physical Embedded Controller (EC) hardware pinhole reset failed to get the firmware to recognize the partition state.

4. Technical Root Cause Assessment
The upgrade mechanism aggressively applied advanced modern ext4 filesystem features (specifically metadata_csum_seed and orphan_file via updated e2fsprogs parameters) to the main system partition (p3).
  • The Regression: These newly activated features broke backward compatibility with the boot infrastructure.
  • The Result: Because the partition metadata layout changed, the GRUB bootloader encountered unparseable header structures at boot time, throwing memory pointer pokes (alloc magic is broken). Furthermore, it introduced a severe tool pipeline regression where the partition identification layer (blkid) on the older recovery kernel could no longer map or resolve the partition's UUID, rendering standard chroot automated recovery loops fundamentally unviable.

No comments:

Post a Comment