exfatuefi
Is it possible to boot from UEFI on an exFAT partition?
I've been reading that it should be FAT32 and not NTFS, however I was able to boot SteamOS from an exFAT formatted USB – notably with errors… but it did seem to error.
I ask to exclude the fact it was exFAT for my diagnosis.
–EDIT
This post maybe better of as a wiki post seeing as I did get reasonably far, so it's probably pretty obvious it is compatible… but this could act as a reference as there isn't an obvious reference for this.
The only tool I tested that can actually resize/extend an exFAT partition:
I got many errors that files had unallocated blocks after resizing, so I decided to reformat as NTFS.
All other "best partition manager" tools I tested at date (08/2018) DON'T SUPPORT exFAT resize/extend:
I don't think there is any tool that can resize/extend exFAT on Linux at the moment.
It turns out that .. first of all, what mode the UEFI is in doesn't matter as regards detection. So, a USB that is detected under EFI will show under EFI, and if Legacy is chosen then on restart, the USB will show under both EFI and Legacy.
But to be listed under EFI, the USB must be appropriately set up for EFI.
The question, is how to set up a USB so it shows under EFI, (you then have a chance of booting off of it when it's not in legacy mode, i.e. when the UEFI is in UEFI mode). Below is the answer of how to make a USB stick show under EFI.
Rufus offers a number of options
Note- the general term for MBR and GPT, are "partition formats".
It may be that all 3 options could work, where they have UEFI in there.. They all work for me. These instructions http://www.eightforums.com/tutorials/15458-uefi-bootable-usb-flash-drive-create-windows.html say you should choose "GPT with UEFI"
For file system.. apparently UEFI is required to support FAT32, and not necessarily NTFS. So, best option here is FAT32
There is one more thing that is needed though. A "bootloader file" in a particular folder, typically \efi\boot\
This page about Debian mentions the names of these files. But it's still relevant to Windows, because for example, Windows 7 64bit uses the path and filename of \EFI\boot\bootx64.efi
amd64 \EFI\boot\bootx64.efi
i386 \EFI\boot\bootia32.efi
arm64 \EFI\boot\bootaa64.efi
I find testing on a 64bit laptop.. If I have the bootia32.efi file on the usb, then it won't be detected(perhaps because the laptop is 64bit), but with bootx64.efi file it will, even if there's junk in the file and it's not a proper bootloader. Sure no doubt it won't boot properly or won't boot far. But my point is that to be detected you need that file. Detection is a precondition for booting. If it's the proper file then it will boot too. I could troubleshoot the issue much faster when I found that I didn't have to burn a whole windows ISO onto the USB to test this/that.
The win7 32bit ISO i've looked at has the EFI folder The win7 64bit ISO has an EFI folder too. I'm not sure about defaults but it looks like the USB might not be EFI , it has an EFI directory but not EFI\boot and so not bootx64.efi and the UEFI motherboard firmware on my laptop isn't seeing it as EFI either, so it's not just Rufus that sees it as not EFI, but the UEFI on my laptop too doesn't see Win7 (even 64bit), as EFI.
While the filename in \efi\boot isn't OS specific, the contents of the file is most likely OS specific. This link for example http://www.nextofwindows.com/how-to-make-uefi-bootable-usb-flash-drive-to-install-windows-8 offers a download to the file and says "if you are preparing for a 64-bit version of installation. You will need to copy a file called bootmgfw.efi from inside install.wim file at sources folder to efi\boot folder on USB flash drive, and rename it to bootx64.efi...[or]... you can simply download this file (http://www.nextofwindows.com/download/bootx64.efi) and copy to your efi\boot folder. " And there may be some supporting files too for proper bootup.
So you should check
Partition Format
File System
EFI folder existing with the relevant file (these are also going to be in any OS ISO that is meant to be booted from a UEFI set to UEFI - as opposed an OS designed to be booted from a BIOS or a UEFI set to legacy)
The EFI folder is a necessity. but don't write the folder manually unless you're experimenting or know what you're doing. It's going to be with the OS ISO.
Apparently Win7 has some issues with USB3 though that wasn't the issue here. That'd cause other symptoms.
Windows 10 can also be made by the windows 10 "media creation tool" instead of rufus though rufus I have found to be ok. And the reason why Macrium reflect booted, was that the current one is based on WinPE 10 64bit which is the WinPE for Windows 10. Windows 10 64bit, has the EFI folder. (I can't comment on windows 10 32bit) And when the Macrium program makes the USB it must be it gives it a partition format that supports UEFI e.g. GPT or a form of MBR that supports UEFI, and the USB would have the EFI folder.
added
UEFI has two modes. a legacy bios mode called CSM(where a BIOS is simulated). And a full mode(that is, legacy/csm is disabled). Many old UEFIs from like 2000-2010 didn't have full mode, so didn't mention any legacy/csm mode but were legacy/csm mode.
If an OS or thing you boot into e.g. if a Windows PE environment, then as of writing, if you make the USB with UEFI mode, then the partition style has to be GPT. As MBR with UEFI is not / is still not supported in windows systems. So on Windows there are only two relevant options. GPT with UEFI, or MBR with UEFI-CSM/BIOS.
I used one UEFI where when booting off a USB, when a USB is setup as UEFI(and not CSM), then in the UEFI's 'boot device options', you can actually point the UEFI to the .efi file so it can boot off it. Or it can try and find it automatically, but if it can't find it then it will say 'no image found' or that you need to make the USB for UEFI-CSM, and then the EFI image and even EFI directory is not needed.
One can experiment with 'Hirens boot cd' on USB, it has a WinPE version and a less graphical, 15.2 version. Macrium Reflect has an option for either legacy boot media, or UEFI boot media.. though macrium might not call it that, it might call it something more like early winpe and later winpe.
Best Answer
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-00A0C93EC93Band an MBR partition ID of0xEF(previously more or less unused).From §12.3.1 (File System Format):
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.