Score:2

Booting from the flash Ubuntu Studio 22.04 (created with Rufus) on Dell Vostro 15

lb flag

I'm trying to boot from the flash Ubuntu Studio 22.04 (created with Rufus) on Dell Vostro 15 (see config below). I got stuck at Launching 'EFI\boot\bootx64.efi'... Ubuntu 16.04 is already installed and I would like to preserve the files.

Boot screen:

booting screen

Dell configuration:

dell config

UEFI boot sequence:

bios booting seq

guiverc avatar
cn flag
I'm not familiar with the first screenshot you provided (*you titled botting screen*) but from details you provided there and on that screen, I'd say the ISO was either invalid (*did you verify it*?) or was incorrectly written to media as NTFS should not be involved in booting a Ubuntu ISO.
Vladimir Sovetov avatar
lb flag
Oh, probably should be FAT32?
guiverc avatar
cn flag
The media should be *ISO9660* with a small *vfat* ESP. No FAT32 or NTFS is expected (though on some systems the *vfat* may show as *fat32* as that's an older but compatible version; vfat allows more than 32-bit capacity)
Vladimir Sovetov avatar
lb flag
Thanks, but strangely enough the only option in Rufus for ubuntustudio-22.04.2-dvd-amd64.iso is NTFS. At least on my WIN
guiverc avatar
cn flag
I'm suspicious your software maybe *out-of-date*, as older versions can only write releases **up to 20.04 ONLY**, with updated `rufus` required to deal with later releases (ie. you could write 16.04, 18.04, even 20.04 & it'll work but not write later ISOs). The *developer* of `rufus` often scans this site & will know, but as I don't use that application, I don't keep *up to date* with it. My guess is you're not writing the ISO correctly given your message (*using a version of RUFUS that can only write releases prior to 20.10*) FYI: If `rufus` is set to CLONE it should work all releases
Vladimir Sovetov avatar
lb flag
I dowloaded Rufus 3.22 from Rufus site today. Thanks anyway
Vladimir Sovetov avatar
lb flag
Resolved. I simply need to disable Secure Boot.
guiverc avatar
cn flag
FYI: All Ubuntu media (inc. 22.04.2) was QA-tested & installed with Secure-boot *enabled* when written correctly (using *clone* methods to write the ISO to install media). I still believe your ISO wasn't written correctly; but regardless - **WELL DONE FOR SOLVING YOUR ISSUE !** (*example of Lubuntu's QA can be seen here - https://phab.lubuntu.me/w/release-team/testing-checklist/ as we use the same `calamares` installer & thus QA/testing/support with the Ubuntu Studio team*)
sudodus avatar
jp flag
A simple final comment: Rufus is made to *clone* when you select ''dd-mode".
Akeo avatar
hk flag
Rufus dev here. Just a note that I've been able to replicate the issue on a different system from OP and I am [currently investigating it](https://github.com/pbatard/rufus/issues/2210). At the moment I suspect that the problem might be with MOK Manager and might have to do with using a **read-only** NTFS driver when booting through UEFI:NTFS. It may take a long time to investigate though, since, unlike UEFI:NTFS, none of Shim/MOK Manager/GRUB provide any output of what they're doing so it's difficult to tell where exactly the problem lies. I'll try to post an answer once I have enough data.
Score:6
hk flag

Rufus dev here. This was a tough one to troubleshoot, but I can now give you a full answer about the issue. It may be a bit chock-full of acronyms and terminology, but that's because I don't really want to provide an explanation that is so dumbed down that it'll become meaningless.

  1. The root of the problem is that, because the current Ubuntu Studio ISO contains a file that is larger than 4 GB, Rufus defaults to using NTFS as the file system for the USB media and, in order to ensure that systems such as Dell Vostro can boot it, also makes sure that an NTFS driver is loaded before the Ubuntu bootloaders start. Unfortunately, as we have found out, the current NTFS driver used by Rufus is not entirely UEFI compliant when it comes to replying to directory listing requests.
  2. Because of this, the next part of the Ubuntu boot loading process, called Shim, may enter an infinite loop when trying to locate certificates by listing specific some directories which it only does when Secure Boot is enabled. So this means that, as OP found out, one way to avoid the issue is to disable Secure Boot, since the Shim will not be reading directories then and will not stress the non-compliant part of the NTFS driver.
    NB: For those technically inclined, the problem is that Shim uses a loop where it issues a read call for the /efi/boot/ directory with a zero sized buffer, and expects (as should be the case for a compliant driver) that the driver will tell it that the buffer provided is too small while also returning the actual size required. Then it re-enters the loop with what it expects to be the updated buffer size. However, whereas the driver does indeed return a code to tell Shim that the buffer it requested is too small, it does not update the size required, meaning that Shim keeps issuing zero-sized requests and the driver keeps returning "buffer too small" forever...

Obviously, we are going to fix the problematic driver in the next version of Rufus to make sure that it returns the actual required size when listing directories, as Shim (rightfully) expects. Yet in the meantime, and even before we identified this issue, the people who develop the Shim also recently discovered that some UEFI firmwares (notably from Dell), and that are not using our NTFS driver, are also failing directory listing compliance and ran into this infinite loop issue. So they have also independently applied a fix to avoid the infinite loop. However, their fix was added in early February, whereas the binary that Ubuntu uses for the Shim was produced in January so it didn't make it into the current Ubuntu Studio. Then again, if Ubuntu Studio had been using the updated Shim code, OP would most likely never have ran into this boot freeze, and we wouldn't have found out that the NTFS driver from Rufus wasn't 100% UEFI-compliant.

All of this means that, eventually, you should have 4 options:

  1. Temporarily disable Secure Boot during installation (as OP did).
  2. Write the media in Rufus in DD mode instead of ISO mode (Remember that, Rufus always prompts you to select between DD mode or ISO mode and tells you, very explicitly, that if you do encounter an issue in ISO mode, you should try to recreate the drive in DD mode).
  3. Use Rufus 3.23 or later, which will include a UEFI-compliant driver.
  4. Use a more recent version of Ubuntu, which should include an updated version of the Shim that can deal with a non-compliant UEFI drivers or firmwares.
Vladimir Sovetov avatar
lb flag
Thank you so much, Akeo. All is clear now and I am happy to help make Rufus better.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.