UEFI exFAT partition?

Solution 1:

The official UEFI spec [warning: 13 MiB PDF] doesn't even say that FAT32 is supported - it defines a filesystem called "EFI System Partition" that "happens" to be compatible with FAT32 and says to assign it a GPT partition type of C12A7328-F81F-11D2-BA4B-00A0C93EC93B and an MBR partition ID of 0xEF (previously more or less unused).

From §12.3.1 (File System Format):

The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.

EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32 system partition is identified by an OSType value other than that used to identify previous versions of FAT. This unique partition type distinguishes an EFI defined file system from a normal FAT file system. The file system supported by EFI includes support for long file names.

The definition of the EFI file system will be maintained by specification and will not evolve over time to deal with errata or variant interpretations in OS file system drivers or file system utilities. Future enhancements and compatibility enhancements to FAT will not be automatically included in EFI file systems. The EFI file system is a target that is fixed by the EFI specification, and other specifications explicitly referenced by the EFI specification.

So not only is exFAT not mentioned as a supported filesystem, but it is also made clear that formally only the ESP format is supported.

So why were you able to load SteamOS? There are a few options and possibilities; most EFI firmware implementations don't explicitly check for the ESP partition before searching for boot-related files, rather if no ESP partition is defined they will search all filesystem they can natively read (which is normally just FAT12/16/32) for the EFI boot files. But even if they were able to, the EFI application it would load from the exFAT-formatted USB wouldn't be able to understand its own filesystem... unless it was hardcoded to pull that off too.

Another, more likely, possibility is that even though you are on an EFI machine and your USB is exFAT formatted, you ended up booting from the USB in BIOS/MBR mode. Most EFI firmware settings (aka "BIOS") applications will have the option of enabling "CSM" or "legacy boot" mode to enable them to fall back to traditional BIOS/MBR/bootsector loading of of operating systems either as a first priority or as a fallback in the event that no ESP could be found or the ESP did not contain valid boot targets. The USB you created and used likely has a hybrid MBR with a bootsector containing valid boot code to boot SteamOS from the USB itself.

In our testing at NeoSmart Technologies, even motherboards/firmwares that are strictly EFI-only without an option to enable CSM/legacy boot will still silently use a minimal BIOS shim to load from external devices. That code is still required since loading from a CD, etc. requires alternatives to native EFI boot in most cases (even though the spec has accommodations for that as well).

Bottom line: more information is needed. A dump of the first 512 or 1024 bytes of the USB would shed a lot of light on the matter, as would information about your motherboard and its EFI firmware and configuration. EFI isn't compatible with exFAT and exFAT isn't backwards-compatible with FAT32 (not only is it not formally compatible, it explicitly breaks backward compatibility so platforms that are not exFAT-aware don't munge and mangle your exFAT data), so it's not as simple as a FAT32-aware firmware "making its way" through an exFAT filesystem with errors.

Solution 2:

Mahmoud's answer is good; however, I want to add a couple of points:

• It's not clear how the boot disk was created, but from some of the comments, I suspect you either used dd to copy it over (as in, dd if=image.iso of=/dev/sdc) or used a utility like Unetbootin or Rufus to do the job. In either case, whatever partitions and filesystems you created on the disk might have been overwritten, so what the disk actually was may have had no relation to what you thought the disk was.
• Distinguishing between the EFI System Partition (ESP) and the rest of the disk is critical. The ESP is a FAT partition (technically by another name, as Mahmoud says -- but in practice it's created by tools to create FAT filesystems and manipulated by OSes' FAT drivers), but that doesn't mean the rest of the disk must be FAT. Thus, you could easily have a FAT ESP and another (perhaps larger) exFAT partition. The boot loader goes on the ESP, and it would either contain an exFAT driver or provide some other way to load a kernel or other critical files from the exFAT partition. That's how Windows, OS X, Linux, and other EFI-capable OSes boot.

Solution 3:

2014 Answer: Yes, you can, but not portably without going through a usual FAT ESP first.

The Rufus flash drive writer supports UEFI-booting from NTFS or exFAT drives by a method called UEFI:NTFS. The README is quite clear about what it does: a tiny FAT ESP is created after the NTFS "ESP". If the firmware somehow supports NTFS, it sees the EFI/BOOT/BOOT{arch}.efi in the first partition and it's happy to go. Otherwise it loads the second ESP, which contains an NTFS or exFAT driver and a program that loads it and runs the EFI/BOOT/BOOT{arch}.efi from the first partition.

The code in boot.c only searches for NTFS or exFAT. It can be changed to work for other things like hfsplus or some "minix" fs available from the GRUB2-based efifs driver set too.

(I have actually never seen any vendors that use a non-FAT ESP, save for Apple which used HFS+ in some old mactel times. They still ship a HfsPlus.efi driver for some other purposes though.)