No file system selectable in Rufus 4.8 or greater

[ktelep]

Checklist

• I have been made aware that if my problem can be summarized as "I've created or tried to create a media using Rufus, and ...", and I am not including a log, this issue will be summarily closed.
• 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

USB creation fails with "Error: Could not partition drive" when using Rufus 4.8 or greater with Nutanix Community Edition ISO (phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso, MD5: 0e7c800b46986c84d4fcdae92e73dc53) this was originally reported in our community forums and I've been chasing down the issue.

After selecting the ISO image, the file system and cluster size dropdowns do not populate with any options as they do with previous versions of Rufus (See attached images)

This issue does not occur with Rufus 4.7 or earlier (confirmed with 3.21, 3.22, 4.4, 4.5, 4.6, 4.7) and has been confirmed across multiple versions of windows and multiple USB devices. I have included logs from 4.7 (working) and 4.8 (failing)

I can provide a copy of the ISO for further testing if necessary.
Kurt Telep
kurt@nutanix.com

Log (v4.8 Output - Not Working)

Rufus x64 v4.8.2253 (Portable)
Windows version: Windows 11 Pro for Workstations x64 (Build 26100.4351)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.12
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
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 non-USB removable device 'NVMe KXG50ZNV1T02 NVM' => Eliminated
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5581)
Using 'autorun.inf' label for drive G: 'PHOENIX'
1 device found
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 15109, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x41639FB0
Drive has a Syslinux Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Detected File System: FAT32
  Size: 115.7 GB (124280340480 bytes)
  Start Sector: 2048, Boot: Yes
Scanning image...
ISO analysis:
  Image is a UDF image
  Will use '/boot/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 4.05/0x5bd8f633 (from '/boot/isolinux/isolinux.bin')
  Detected Shim version: 15 (from '/EFI/BOOT/BOOTX64.EFI')
  Detected GRUB version:  (from '/EFI/BOOT/grubx64.efi')
  Supported GRUB filesystems: ext2, hfsplus, iso9660, xfs
Disk image analysis:
  Image does not have a Boot Marker
UEFI bootloaders analysis:
  • /EFI/BOOT/BOOTX64.EFI
  Signed by 'Nutanix Secure Boot Key'
  • /EFI/BOOT/grubx64.efi
  Signed by 'Nutanix Kernel Signing Key'
ISO label: 'PHOENIX'
  Size: 6.6 GB (Projected)
  Uses: Syslinux/Isolinux v4.05
  Uses: GRUB2 ()
  Uses: EFI
Using image: phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso (6.6 GB)

Format operation started
Requesting disk access...
Will use 'G:' as volume mountpoint
Opened \\.\PhysicalDrive1 for exclusive write access
Analyzing existing boot records...
Drive has a Syslinux Master Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Initializing disk...
Partitioning (MBR)...
● Creating Main Data Partition (offset: 1048576, size: 115.7 GB)
Unsupported file system
\\?\GLOBALROOT\Device\HarddiskVolume24\ was successfully mounted as G:
Re-mounted volume as G: after error

Found non-USB removable device 'NVMe KXG50ZNV1T02 NVM' => Eliminated
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5581)
1 device found
No volume information for drive 0x81
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 15109, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned
No file system is selectable for this drive

Computing hash for 'C:\Users\ktele\Downloads\phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso'...
  MD5:    0e7c800b46986c84d4fcdae92e73dc53
  SHA1:   47f64de857fddf05ea51a4f34fefa2953ae5c0c6
  SHA256: c1b89c930f5e9d5dbff2b6ede2064978e79b57902bbcab6e055a8600777bebb7

Format operation started
Requesting disk access...
No drive letter was assigned...
Will use 'H:' 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 (MBR)...
● Creating Main Data Partition (offset: 1048576, size: 115.7 GB)
Unsupported file system
\\?\GLOBALROOT\Device\HarddiskVolume24\ was successfully mounted as H:
Re-mounted volume as H: after error

Found non-USB removable device 'NVMe KXG50ZNV1T02 NVM' => Eliminated
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5581)
1 device found
No volume information for drive 0x81
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 15109, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned
No file system is selectable for this drive

Log (v4.7 Output - Working, same system, same USB device)

Rufus x64 v4.7.2231 (Portable)
Windows version: Windows 11 Pro for Workstations x64 (Build 26100.4351)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.12
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
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 non-USB removable device 'NVMe KXG50ZNV1T02 NVM' => Eliminated
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5581)
1 device found
No volume information for drive 0x81
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 15109, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned
Scanning image...
ISO analysis:
  Image is a UDF image
  Will use '/boot/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 4.05/0x5bd8f633 (from '/boot/isolinux/isolinux.bin')
Disk image analysis:
  Image does not have a Boot Marker
ISO label: 'PHOENIX'
  Size: 6.6 GB (Projected)
  Uses: Syslinux/Isolinux v4.05
  Uses: EFI
Using image: phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso (6.6 GB)

Computing hash for 'C:\Users\ktele\Downloads\phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso'...
  MD5:    0e7c800b46986c84d4fcdae92e73dc53
  SHA1:   47f64de857fddf05ea51a4f34fefa2953ae5c0c6
  SHA256: c1b89c930f5e9d5dbff2b6ede2064978e79b57902bbcab6e055a8600777bebb7

Format operation started
Requesting disk access...
No drive letter was assigned...
Will use 'G:' 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 2176 sectors
Initializing disk...
Partitioning (MBR)...
● Creating Main Data Partition (offset: 1048576, size: 115.7 GB)
Waiting for logical drive to reappear...
Formatting (Large FAT32)...
Opened \\?\Volume{008b59bd-5cb6-11f0-81e2-d89ef341af80} for exclusive write access
Size : 115.7 GB 242735040 sectors
Cluster size 32768 bytes, 512 bytes per sector
Volume ID is 1afc:1616
144 Reserved sectors, 29624 sectors per FAT, 2 FATs
3791807 Total clusters
3791806 Free clusters
Clearing out 59456 sectors for reserved sectors, FATs and root cluster...
Initializing reserved sectors and FATs...
FAT #0 sector at address: 144
FAT #1 sector at address: 29768
Writing Partition Boot Record...
Using Standard FAT32 partition boot record
Confirmed new volume has a primary FAT32 boot sector
Setting primary FAT32 boot sector for boot...
Confirmed new volume has a secondary FAT32 boot sector
Setting secondary FAT32 boot sector for boot...
Setting label...
Format completed.
Opened \\.\PhysicalDrive1 for exclusive write access
Writing Master Boot Record...
Partition is already FAT32 LBA...
Set bootable USB partition as 0x80
Using Syslinux MBRExtracting: G:\images\hypervisor\kvm\AHV-DVD-x86_64-el8.nutanix.20230302.101026.iso.iso (1.5 GB)
Extracting: G:\images\svm\nutanix_installer_package.tar.p00 (3.9 GB)
Extracting: G:\images\svm\nutanix_installer_package.tar.p01 (470.5 MB)
Extracting: G:\make_iso.sh (2.8 KB)
Extracting: G:\phoenix_version (23 bytes)
Extracting: G:\squashfs.img (343.8 MB)
Extracting: G:\templates\grub2.cfg (851 bytes)
Extracting: G:\templates\grub_efi.cfg (644 bytes)
Created: G:\syslinux.cfg → /boot/isolinux/isolinux.cfg
Finalizing, please wait...
Created: G:autorun.inf
Created: G:autorun.ico

Found non-USB removable device 'NVMe KXG50ZNV1T02 NVM' => Eliminated
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5581)
Using 'autorun.inf' label for drive G: 'PHOENIX'
1 device found
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 15109, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x41639FB0
Drive has a Syslinux Master Boot Record
Partition 1:
  Type: FAT32 LBA (0x0c)
  Detected File System: FAT32
  Size: 115.7 GB (124280340480 bytes)
  Start Sector: 2048, Boot: Yes

[pbatard]

Thanks. I can replicate the issue, and I know why it's happening.

In short, recent versions of Rufus check for what file systems are available in the GRUB bootloaders (which is what the Nutanix ISO uses for UEFI boot), before making them available to the user in Rufus.

However, whereas the FAT module is available in the GRUB bootloader of the phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso ISO, the Nutanix folks decided to build a custom version of it that is missing the fshelp identifier that allows us to tell that the FAT module is indeed present.

Therefore, Rufus does not detect that FAT is available. Therefore it does not allow you to use FAT.

Now, obviously, there's some better handling needed in Rufus for what happens when FAT is not detected (because it should not let you proceed, since it's going to fail in the manner you experienced), and I am going to see what I can do to figure out how I can detect the FAT module from the Nutanix ISO GRUB bootloader. But I can't promise anything on that last part, because, from looking at the GRUB bootloader, we really don't have much to work with, and I'm seeing a lot of customisation I don't like that the Nutanix folks applied to their GRUB bootloader (Such as removing the GRUB version string altogether. Really? From Open Source software that really doesn't need anything concealed and that will make it impossible for utilities to determine, as happened in the past, if some additional customisation might be needed to make your media boot on all compatible systems) and that might lead me to say "screw it", since I don't want the fs module detection, which is very much needed and relied on by other ISOs, get derailed by distro maintainers who seem to think they "know better" than the GRUB folks what parts from the GRUB source are needed, and what parts they can do away with nilly-willy.

At least, for UEFI, you can just format a drive to FAT32 and extract the ISO there, so you don't really need Rufus anyway (and I doubt many people are installing Nutanix on BIOS systems). Still, I'll see what I can do, but with no promises that I will make Nutanix work with Rufus, because, IMO, it should be down to the Nutanix folks to not alter the GRUB code that doesn't need altering...

[ktelep]

Let me talk to our internal maintainers and see if there’s a reason for the specific customization that’s been done and if we can fix this on our end vs. needing an edge case in Rufus. Surprisingly there ARE a number of folks deploying Nutanix CE on BIOS based systems (old data center hardware from days of yore) which is why we keep both options for both install methods available.

…

On Fri, Jul 11, 2025 at 5:42 AM Pete Batard ***@***.***> wrote: *pbatard* left a comment (pbatard/rufus#2769) <#2769 (comment)> Thanks. I can replicate the issue, and I know why it's happening. In short, recent versions of Rufus check for what file systems are available in the GRUB bootloaders (which is what the Nutanix ISO uses for UEFI boot), before making them available to the user in Rufus. *However*, whereas the FAT module is available in the GRUB bootloader of the phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso ISO, the Nutanix folks decided to build a custom version of it that is missing the fshelp identifier that allows us to tell that the FAT module is indeed present. Therefore, Rufus does not detect that FAT is available. Therefore it does not allow you to use FAT. Now, obviously, there's some better handling needed in Rufus for what happens when FAT is not detected (because it should not let you proceed, since it's going to fail in the manner you experienced), and I am going to see what I can do to figure out how I can detect the FAT module from the Nutanix ISO GRUB bootloader. But I can't promise anything on that last part, because, from looking at the GRUB bootloader, we really don't have much to work with, and I'm seeing a lot of customisation I don't like that the Nutanix folks applied to their GRUB bootloader (Such as *removing* the GRUB version string altogether. Really? From Open Source software that really doesn't need anything concealed and that will make it impossible for utilities to determine, as happened in the past, if some additional customisation might be needed to make your media boot on all compatible systems) and that might lead me to say "screw it", since I don't want the fs module detection, which is very much needed and relied on by other ISOs, get derailed by distro maintainers who seem to think they "know better" than the GRUB folks what parts from the GRUB source are needed, and what parts they can do away with nilly-willy. At least, for UEFI, you can just format a drive to FAT32 and extract the ISO there, so you don't really need Rufus anyway (and I doubt many people are installing Nutanix on BIOS systems). Still, I'll see what I can do, but with no promises that I will make Nutanix work with Rufus, because, IMO, it should be down to the Nutanix folks to not alter the GRUB code that doesn't need altering... — Reply to this email directly, view it on GitHub <#2769 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFCX362WYPFHCEPXRSWANL3H6BI3AVCNFSM6AAAAACBILKDOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANRRGU2DKNBTGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pbatard]

Thanks. Let me more specific then. Rufus is actively looking for the string fshelp\0<file system name> to find out the file systems supported by GRUB. For instance, you will see instances of fshelp\0ext2, fshelp\0hfsplus to indicate that ext2/3/4 and HFS+ are supported as GRUB filesystems, so that the GRUB UEFI bootloader can read the data it needs for them. These are also usually prefixed by the string LICENSE=GPLv3+ (which Rufus doesn't care about). And on every other GRUB bootloader I've encountered from Debin, Arch, Ubuntu, etc., the GRUB FAT filesystem module will have an fshelp\0fat string.

However, for some reason, the GRUB FAT module from Nutanix ditched the fshelp string, which means that we just have LICENSE=GPLv3+\0\0fat (at offset 0x0A26A0 in EFI/BOOT/grubx64.efi), which means that, even as the FAT module is present, it's going to be quite difficult for Rufus to detect it.

From what I can tell, the fshelp string should always appear by default, to reference the fact that the module is build from both GRUB's fshelp.c and fat.c (since here is a direct reference to fshelp.h in fat.c), so I'm not sure what Nutanix did to lose the reference to fshelp. I don't believe that they are using a different FAT GRUB submodule, because it still look awfully similar to GRUB's native submodule. But it also seems very strange that all the other filesystem submodules have the fshelp reference but not FAT.

As to the version removal, I'm just going to say that it is REALLY annoying for anyone trying to use your product, because you'd be surprised how many times having accurate representation of "We're basing our derivative on version x.yz of the base project, on top of which we applied some customization", by making sure that you embed a version such as x-yz_YOUR_PROJECT, can become critical to troubleshooting issues, though, in this specific case, it's a minor gripe.

[pbatard]

I'm going to push a patch that should restore the availability of FAT32 as a file system (and therefore restore the "old" behaviour with Nutanix ISOs) even when Rufus detects that FAT32 is not officially available in the bootloader. A warning about this will be generated in the log though, since Rufus is unable to guarantee that the media can boot properly.

I'm also going to modify the title of the issue, as the main problem is that no file system is being made available (and the partitioning issue is only a consequence of that).

[ktelep]

Thank you! In parallel, we're also working on this NOT being a situation in the next CE ISO release, so we do not need to be an exception to the rule.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.