Invalid symbolic link for UEFI bootloader in linuxmint-21.2-cinnamon-64bit-edge.iso

[pbatard]

Distribution

Mint 21.2 and Mint 21.3

Package version

N/A

Graphics hardware in use

N/A

Frequency

Always

Bug description

The linuxmint-21.2-cinnamon-64bit-edge.iso, and now linuxmint-21.3-###-64bit.iso, were improperly mastered on account that, on the ISO-9660 file system, its /EFI/boot/bootx64.efi is a (Rock Ridge) symbolic link to /etc/alternatives/shimx64.efi.signed which does not exist on the ISO-9660 file system.

As a result, any attempt to boot the media using File System Transposition (which is the default method used by Rufus and other utilities, and which is different from DD copy) will fail, as the x86_64 UEFI bootloader is obviously invalid.

Steps to reproduce

1. Mount the ISO under a Linux system.
2. Look at what /EFI/boot/bootx64.efi point to (ls -alFh <ISO Mountpoint>/EFI/boot/bootx64.efi)
3. Search for the link target or try to access the bootloader content.

Expected behavior

A proper symbolic link should always point to a target on the same file system. This is not the case. Therefore the newer 21.2 and 21.3 ISOs were improperly mastered and need to be fixed.

Additional information

It should also be noted that using symbolic links for the bootloader is a VERY bad idea, and should be avoided at all cost as you can not count on indirection to retrieve an early stage bootloader.

Finally, this improper mastering leads to major boot issues when using Rufus per https://superuser.com/a/1816478/286681 as well as https://old.reddit.com/r/linuxmint/comments/195pgc5/213_live_usb_not_booting/ (since Rufus otherwise has no trouble making Mint work, even though it relies on symbolic links, as long as the UEFI bootloaders are not borked).

[pbatard]

Any update on this. This now affects Mint 21.3 (tested with linuxmint-21.3-xfce-64bit.iso) and is affecting Mint users, per https://old.reddit.com/r/linuxmint/comments/195pgc5/213_live_usb_not_booting/.

[clefebvre]

It looks like a regression in live-build. If so it was fixed in https://salsa.debian.org/live-team/live-build/-/commit/5bff71fea2dd54adcd6c428d3f1981734079a2f7 but not yet backported to Debian.

[pbatard]

Thanks for the update, and pointing to the cause and resolution of the issue. I added a comment on that salsa commit (and may try to submit a patch if nothing happens) as it's pretty clear that a similar issue could arise if someone uses a symlinked /EFI/boot/grub###.efi as part of their build.

Since, sadly, I don't expect a fix to make its way into Mint for a while, I'm also investigating if I can rush a Rufus release that adds a specific workaround for this issue (by picking up the required shim EFI from the El-Torito image when we detect a symlink), but it's a bit tricky...

[clefebvre]

@pbatard our Mint 21.3 EDGE ISO is currently in QA. If this gets fixed today I'll reject it and include the fix in it.

Are you able to test an ISO if I provide a link to you?

[pbatard]

Are you able to test an ISO if I provide a link to you?

Definitely. You can e-mail me to pete@akeo.ie if you want.

[clefebvre]

@pbatard I made a new ISO and sent you the link by email.

[pbatard]

@clefebvre, thanks. I have tested that image on a couple UEFI systems and booted to the live environment, so I can confirm that it does fix the issue referenced above.

While testing this, I also picked a small issue in Rufus (unrelated to the above), when using MBR instead of GPT partition scheme and booting some UEFI systems, so I'll make sure to have that fixed on my side for the next release (that should also include the workaround for the current 21.3 ISOs).

[clefebvre]

Thanks @pbatard.

The upcoming 21.3 EDGE ISO will include this fix.

The following ISOs will still be affected:

• LMDE 6
• Mint 21.2 EDGE
• Mint 21.3 (non-EDGE ISOs)

Note: Not directly related to this. But we'll also fix the following issue in 21.3 EDGE: #635.

[clefebvre]

This is fixed in the upcoming 21.3 EDGE ISO.

[pbatard]

For completion, I'll just add a note that the newly released Rufus 4.4 now includes a workaround for this specific issue, when using an affected ISOs. Basically, it tries to detect if there's a broken symlinked bootx64.efi and, if that is the case, replaces it with the one from the El Torito boot image.