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.
- 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.
- 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:
- Temporarily disable Secure Boot during installation (as OP did).
- 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).
- Use Rufus 3.23 or later, which will include a UEFI-compliant driver.
- 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.
