Rufus truncates file-names in UEFI ISOs

[roosmaa]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the 'Log' button (🗒️) or pressed Ctrl-L in Rufus, or used DebugView, and copy/pasted the log into the section that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.
• If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

When creating a USB disk from the Talos SecureBoot ISO ( https://factory.talos.dev/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v1.7.0/metal-amd64-secureboot.iso ), the USB is successfully created, however, some of the file names are truncated, thus the booting fails.

Mounting the ISO in the WSL environment and comparing the two:

# mount -t drvfs D: /mnt/d/
# mount /mnt/c/Users/me/Downloads/metal-amd64-secureboot.iso /mnt/iso/
# mount /mnt/iso/efiboot.img /mnt/loop/

# find /mnt/d/
/mnt/d/
/mnt/d/System Volume Information
/mnt/d/System Volume Information/WPSettings.dat
/mnt/d/System Volume Information/IndexerVolumeGuid
/mnt/d/[boot]
/mnt/d/[boot]/0-boot-noemul.img
/mnt/d/boot.catalog
/mnt/d/efiboot.img
/mnt/d/EFI
/mnt/d/EFI/BOOT
/mnt/d/EFI/BOOT/BOOTX64.EFI
/mnt/d/EFI/Linux
/mnt/d/EFI/Linux/Talos-v1.7.0
/mnt/d/EFI/KEYS
/mnt/d/EFI/KEYS/uki-signing-
/mnt/d/LOADER
/mnt/d/LOADER/KEYS
/mnt/d/LOADER/KEYS/AUTO
/mnt/d/LOADER/KEYS/AUTO/PK.auth
/mnt/d/LOADER/KEYS/AUTO/KEK.auth
/mnt/d/LOADER/KEYS/AUTO/db.auth
/mnt/d/LOADER/loader.conf
/mnt/d/autorun.inf
/mnt/d/autorun.ico

# find /mnt/loop/
/mnt/loop/
/mnt/loop/EFI
/mnt/loop/EFI/BOOT
/mnt/loop/EFI/BOOT/BOOTX64.EFI
/mnt/loop/EFI/Linux
/mnt/loop/EFI/Linux/Talos-v1.7.0.efi
/mnt/loop/EFI/keys
/mnt/loop/EFI/keys/uki-signing-cert.der
/mnt/loop/loader
/mnt/loop/loader/keys
/mnt/loop/loader/keys/auto
/mnt/loop/loader/keys/auto/PK.auth
/mnt/loop/loader/keys/auto/KEK.auth
/mnt/loop/loader/keys/auto/db.auth
/mnt/loop/loader/loader.conf

Notice the following naming discrepancies:

Dir	File name (actual)	File name (rufus)
/EFI/Linux	Talos-v1.7.0.efi	Talos-v1.7.0
/EFI/keys	uki-signing-cert.der	uki-signing-

Log

Rufus x64 v4.5.2180
Windows version: Windows 10 Home x64 (Build 19045.4651)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.12
System locale ID: 0x0809 (en-GB)
Will use default UI locale 0x0809
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Notice: The ISO download feature has been deactivated because 'Check for updates' is disabled in your settings.
Found 517 officially revoked UEFI bootloaders from embedded list
Found 2351 additional revoked UEFI bootloaders from this system's SKUSiPolicy.p7b
0 devices found
Found USB 3.0 device 'TOSHIBA USB FLASH DRIVE USB Device' (0930:1408)
Using 'autorun.inf' label for drive D: 'Talos Secure Boot ISO'
1 device found
Disk type: Removable, Disk size: 16 GB, Sector size: 512 bytes
Cylinders: 1886, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {F2FE1DBD-6A69-4666-B50E-B599185AFBAD}
Max parts: 128, Start Offset: 17408, Usable = 15518890496 bytes
Partition 1:
  Type: Microsoft Basic Data Partition
  Name: 'Main Data Partition'
  Detected File System: FAT32
  ID: {59D34677-31D1-4D11-8CB0-E971F912234B}
  Size: 14.5 GB (15517843456 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
Scanning image...
ISO analysis:
libcdio: Auto-expanding the size of 0-Boot-NoEmul.img
  Image is an ISO9660 image
libcdio: Auto-expanding the size of 0-Boot-NoEmul.img
  Detected EFI bootloader(s) (from '/efiboot.img'):
  ● 'bootx64.efi'
Disk image analysis:
  Image does not have a Boot Marker
ISO label: 'Talos Secure Boot ISO'
  Size: 186.3 MB (Projected)
  Uses: EFI
Using image: metal-amd64-secureboot.iso (93.4 MB)

Format operation started
Requesting disk access...
Will use 'D:' as volume mountpoint
Opened \\.\PhysicalDrive1 for exclusive write access
Analyzing existing boot records...
Drive has a Zeroed Master Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Initializing disk...
Partitioning (GPT)...
● Creating Main Data Partition (offset: 1048576, size: 14.5 GB)
Waiting for logical drive to reappear...
Formatting to FAT32 (using IFS)
Using cluster size: 8192 bytes
Quick format was selected
Creating file system...
Format completed.
Writing Master Boot Record...
Using Rufus protective MBR
Writing protective message SBR
Found volume \\?\Volume{0d2eaf60-4f76-11ef-b0f8-bcf171ab504e}\
Successfully remounted \\?\Volume{0d2eaf60-4f76-11ef-b0f8-bcf171ab504e}\ as D:
Extracting files...
libcdio: Auto-expanding the size of 0-Boot-NoEmul.img
Image is an ISO9660 image
This image will be extracted using Joliet extensions (if present)
Extracting: D:\[boot]\0-boot-noemul.img (93.3 MB)
Extracting: D:\boot.catalog (2 KB)
Extracting: D:\efiboot.img (93 MB)
libcdio: Auto-expanding the size of 0-Boot-NoEmul.img
Extracting: D:\EFI\BOOT\BOOTX64.EFI (from '/efiboot.img', 88.3 KB)
Extracting: D:\EFI\Linux\Talos-v1.7.0 (from '/efiboot.img', 81.2 MB)
Extracting: D:\EFI\KEYS\uki-signing- (from '/efiboot.img', 1.4 KB)
Extracting: D:\LOADER\KEYS\AUTO\PK.auth (from '/efiboot.img', 3.7 KB)
Extracting: D:\LOADER\KEYS\AUTO\KEK.auth (from '/efiboot.img', 3.7 KB)
Extracting: D:\LOADER\KEYS\AUTO\db.auth (from '/efiboot.img', 3.7 KB)
Extracting: D:\LOADER\loader.conf (from '/efiboot.img', 69 bytes)
Finalizing, please wait...
Created: D:autorun.inf
Created: D:autorun.ico

Found USB 3.0 device 'TOSHIBA USB FLASH DRIVE USB Device' (0930:1408)
Using 'autorun.inf' label for drive D: 'Talos Secure Boot ISO'
1 device found
Disk type: Removable, Disk size: 16 GB, Sector size: 512 bytes
Cylinders: 1886, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {1898DFC8-A917-48A6-BF36-E80F68216373}
Max parts: 128, Start Offset: 17408, Usable = 15518890496 bytes
Partition 1:
  Type: Microsoft Basic Data Partition
  Name: 'Main Data Partition'
  Detected File System: FAT32
  ID: {E3F561E1-F038-494C-B653-9AFFBE9F77CC}
  Size: 14.5 GB (15517843456 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000

[pbatard]

Thanks for the report.

I'm afraid Rufus doesn't support El Torito file extraction, which is where your issue occurs, except for a limited set of cases (extractions of the UEFI bootloaders themselves). We do try to extract the other files from the El Torito image where possible, but this is accomplished through the third party SysLinux FAT library, to which we added a quick and dirty fat directory extraction, that we don't really have plan to flesh out (because the cost/benefit ratio isn't that great).

That's not to say we might not look into it, but I'm afraid it's going to be be very low priority for the time being.

I will also add that, generally it's a very poor idea to rely on El Torito/flat images for UEFI boot, whereas one can simply have the bootloaders and all their dependency residing at first level in the ISO-9660/UDF file system itself. Case in point, you had to mount the media twice to access the files under Linux, whereas the whole point of UEFI design and UEFI boot, as opposed to BIOS boot, was to do away with stopgap solutions like El Torito, which was only ever really designed for BIOS/Legacy, and have the bootloaders resides on the prime file system of the media and accessed through regular UEFI file system calls (rather than sector by sector loading). Alas, a lot of distro maintainers didn't seem to get that message, and are still relying on archaic ways, because it does make their lives (but only their lives) easier, while, as you have experienced, actually creating issues downstream.

In short, in my view, the root of the issue is with Talos completely disregarding File System Transposition, which is something that any distro maintainer should really be striving to support on the same standing as DD copy, as it would allow people to completely do away with third party utilities like Rufus of dd (which is not native on Windows), and instead create UEFI bootable media by simply extracting the ISO content as is on media that they formatted themselves using the native OS tools.

Otherwise, by continuing to only see DD as the one mode to rule them all (despite a long list of shortcomings), and using quirks, such as El Torito, that can only ever work well in DD, they will continue to drastically reduce the possibility of choice when it comes to the manner in which end-users can create their boot media, especially, again, when UEFI's goal was precisely to remove all of the pain points that fostered the use of disk images and sector by sector copy.

So, for the time being, I will flag this issue as deferred.

[roosmaa]

Thanks for the insightful reply. As someone who's not at all familiar with the inner workings of ISOs, it's a good rabbit hole to do some further research. 🙇

[hhihhio]

hello, please add option to create efi partition. my laptop can't boot uefi usb to install win without have small efi partition, or it can't find /EFI folder or efix64 to run windows install in uefi mode. I tried create GPT-UEFI many times with Rufus but rarely it ramdom create efi partition, very rare, I want an option.