I say may cause i am going a unsupported upgrade from 24.04 to 25.04 (hopefully nothing breaks i can’t fix… ) (edit: there was breakage, but nothing i could not fix)
while doing a upgrade i ran into this, /usr/lib32 did not exist, however i do have a /usr/libx32, however the upgrade makes sure the symlink goes to /usr/lib32 so using libx32 did not work, created the folder and it is continuing the install
******************************************************************************
*
* The base-files package cannot be installed because
* /lib32 is a dangling symbolic link.
*
* This is an unexpected situation. Cannot proceed with the upgrade.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
******************************************************************************
giving how i was preforming the ‘upgrade’ i feel it needs to be validated 1st by someone else
going from 24.04 to 25.04 (skipping 24.10) by editing my apt sources and doing a dist upgrade (keeping added repos and setting them to use newer sources when possible), then fixing all the broken packages (force remove this, install that, upgrade) is not the supported way
given that is so far from the normal supported method, it really needs validation, or should i report it as a bug anyway
Upgrades from 24.04 to 25.04 will only be supported after 24.10 is EOL (July 2025), as until then the supported upgrade are 24.04 to 24.10, and from 24.10 to 25.04 (currently the focus of QA).
If CI testing currently checks 24.04 to 25.04 I don’t know, but QA for that path isn’t yet open (and that upgrade path gets less QA than every release).
Either way, as you release-upgraded using a Debian method, you didn’t run the normal Ubuntu release-upgrade scripts; thus are outside of what could happen when a 24.04 LTS to 25.04 upgrade will occur anyway.
Never ever just edit your sources (note that the sources.list file is deprecated, source repo entries have been moved to deb822 format)…
The do-release-upgrade tool (or its GUI frontend update-manager) actually do a lot more than just mangling your sources… One is the transition of the /lib and /lib32|64 dirs to their new places in the so called “usrmerge” transition, another is the move to above mentioned deb822 handling of apt sources and there are tons of other things, even app specific ones, where bits and pieces get moved in the correct places, configs get adjusted and more that the new release requires.
The only problem that I had using ‘sudo do-release-upgrade -d’ from Ubuntu 24.10 was the usual snap-store issues. After the upgrade, ‘sudo snap info snap-store’ showed…
tracking: 2/stable/ubuntu-24.10
Snap after the upgrade from 24.10 to 25.04 doesn’t allow for the channel to be set to 2/stable/ubuntu-25.10 as it thinks it doesn’t exist. The only workaround that I have found is to resort to a clean install of Ubuntu 25.10 rather than an upgrade.
I read somewhere that the ubuntu+1 snap-store isn’t considered to exist until release but that is very puzzling as the installer thinks it does.
The reason for that is that the required quirks to update snaps probably hadn’t been added when you decided to upgrade. This is one of many reasons upgrades aren’t enabled until a week or two after release.
It would be nice if they at least provided a way to fix the snap channels afterwards. Unless I am mistaken, currently you stuck on the wrong channel even after they enable upgrades on previously upgraded machines.
While testing the current nightly 25.04 live installers on amd64 with a dual boot Linux/Windows machine, I noticed that the ‘sudo mokutil --list-sbat-revocations’ showed that…
sbat,1,2023012900
got updated to the previously problematic…
sbat,1,2024010900
Weirdly, this did not seem to break the Windows/Linux dual boot with secure boot enabled. Has the previous breakage…
After more testing, I can confirm that while Ubuntu 24.04.2 has the 2023012900 dbx loading from its signed-shim that Ubuntu 25.04 loads the 2024010900 dbx. This brings up the question of how this 2024010900 dbx isn’t breaking the dual boot? Is it modified from what Microsoft installed in their updates or has the incompatibility been worked around within grub?
… and here was the change spec’ed (IIRC Ubuntu strarted to move to it with 23.10 and made it a default in 24.04 … there is backwards compatibility indeed, but we should try to make people use the right thing when supporting them):
The question is still whether Ubuntu 25.04 has really adopted sbat,1,2024010900. The confusion is that this should in theory be the problematic one that Microsoft released which broke dual booting. If Ubuntu did, was the copy in shimx64.efi hacked to fix Microsoft’s bug in their own copy or did grub get a workaround for the breakage Microsoft introduced?
The Microsoft DBX update in August 2024 (KB5041585) introduced a Secure Boot Advanced Targeting (SBAT) policy that blocked older Linux bootloaders, including shim and GRUB, causing dual-boot failures on systems with Secure Boot enabled. To address this, newer shim versions (starting with shim 15.8) were updated to comply with the SBAT policy and ensure compatibility.
Key changes in newer shim versions include:
SBAT Metadata Integration: Shim 15.8 and later incorporate an .sbat section in their Portable Executable (PE) files. This section contains metadata like vendor name, component name, and version number, allowing the bootloader to self-identify and align with SBAT’s generational revocation approach. This prevents the shim from being flagged as vulnerable by the updated DBX database.
Updated Signatures: Newer shim versions are signed with updated certificates that aren’t listed in the DBX revocation list. This ensures they pass Secure Boot verification, avoiding the “Security Policy Violation” error triggered by older, revoked signatures.
Compatibility with SBAT Policy: The shim was modified to handle SBAT’s stricter checks, which target specific bootloader versions rather than individual binary hashes. This allows the shim to boot without being blocked by Microsoft’s policy, which aimed to prevent vulnerable EFI modules from loading.
These changes enabled distributions like Ubuntu 24.04 (which shipped with shim 15.8) to boot unaffected. For older systems, updating to a shim version >=15.8 (often via distribution-specific packages like shim-signed in Ubuntu) or applying GRUB updates resolves the issue, assuming Secure Boot remains enabled. If you’re troubleshooting a specific Ubuntu version, let me know, and I can tailor the fix details!
It was annoying that the changelog for the updated shim-signed packaging didn’t make it clear that the KB5041585 breakage was fixed at upstream 15.8.
Grok even has an answer as to why the older dbx is used as the default for Ubuntu prior to 25.04.
The difference in the default DBX (Secure Boot Forbidden Signature Database) versions between Ubuntu 25.04’s shim-signed package and those in Ubuntu 24.04.2 and 24.10 likely stems from Canonical’s approach to integrating Microsoft’s Secure Boot updates, particularly the one tied to KB5041585 (August 2024), which introduced a stricter SBAT (Secure Boot Advanced Targeting) policy. Here’s a breakdown of why this happens:
Ubuntu 25.04’s Shim-Signed and KB5041585 DBX:
Ubuntu 25.04, being a development release (as of April 2025, it’s likely in active development toward its April 2025 stable release), defaults to a newer shim-signed package that incorporates the DBX update from KB5041585. This update expanded the list of revoked bootloader signatures and introduced SBAT policies to block vulnerable Linux bootloaders (e.g., older shim and GRUB versions). Canonical likely included this to ensure 25.04 aligns with Microsoft’s latest security requirements for Secure Boot, avoiding the dual-boot issues seen in August 2024 when KB5041585 broke older Linux setups. By embedding the KB5041585 DBX, 25.04’s shim (version 15.8 or higher) ensures compatibility with systems applying Microsoft’s latest revocation list, preventing boot failures.
Ubuntu 24.04.2 and 24.10 Using Older DBX:
Ubuntu 24.04.2 (an LTS point release) and 24.10 (released October 2024) were finalized before the KB5041585 fallout became a widespread issue. Their shim-signed packages (still shim 15.8 in many cases) likely defaulted to an earlier DBX version (e.g., from 2023 or early 2024, like version 371 or 20230501) because these were stable and didn’t yet need the KB5041585-specific revocations. Canonical’s conservative update strategy for stable releases prioritizes avoiding disruption, so they didn’t rush to include the KB5041585 DBX, which caused issues for users with older bootloaders. Instead, users were advised to update shim and GRUB manually or disable Secure Boot as a workaround.
Technical and Policy Reasons:
Development vs. Stable Releases: Ubuntu 25.04, as a bleeding-edge release, adopts the latest DBX to future-proof against Secure Boot incompatibilities, especially after the KB5041585 incident exposed risks of outdated bootloaders. Stable releases like 24.04.2 and 24.10 stick with tested DBX versions to minimize regression risks.
SBAT Integration: The KB5041585 DBX enforces SBAT, which requires bootloaders to have specific metadata (like the .sbat section in shim 15.8). Ubuntu 25.04’s shim-signed likely defaults to this DBX to ensure all boot components meet SBAT standards, while 24.04.2 and 24.10 could boot fine with older DBX versions on systems not yet updated with Microsoft’s patch.
Pacing of Updates: Canonical may have delayed rolling out the KB5041585 DBX to stable releases to allow time for testing and community feedback, given the update’s history of breaking dual-boot setups. Ubuntu 25.04, being newer, skips this lag by starting with the updated DBX.
In short, Ubuntu 25.04’s shim-signed defaults to the KB5041585 DBX to align with Microsoft’s latest Secure Boot policies and avoid known issues, while 24.04.2 and 24.10 use older DBX versions to maintain stability for users not yet affected by the update. If you’re facing specific issues with these versions, let me know your setup, and I can suggest targeted fixes!
) (edit: there was breakage, but nothing i could not fix)