Pete Batard of Akeo Consulting has updated UEFI:NTFS boot loader:
UEFI:NTFS – Boot NTFS partitions from UEFI
This generic bootloader, which is primarily intended for use with Rufus, is meant to allow seamless booting from an EFI bootloader, that resides on an NTFS partitions. In other words, UEFI:NTFS is designed to remove the UEFI restriction of being able to natively boot from FAT32 only, and allow NTFS boot without the need for any user intervention. This can be used, for instance, for booting an USB Windows NTFS installation media, in EFI mode, allowing support for files that are larger than 4GB (something a native EFI FAT32 partition cannot support), or allow indiscriminate EFI or BIOS boot of Windows To Go drives. The way this works, in conjuction with Rufus, is as follows:
* Rufus creates 2 partitions on the target USB disk (these can be MBR or GPT partitions). The first one is an NTFS partition occupying almost all the drive, that contains the Windows files (for Windows To Go, or for regular installation), and the second is a very small FAT partition, located at the very end, that contains an NTFS EFI driver (see http://efi.akeo.ie) as well as the UEFI:NTFS bootloader.
* When the USB drive boots in EFI mode, the first NTFS partition gets ignored by the EFI firmware and the UEFI:NTFS bootloader from the bootable FAT partition is executed.
* UEFI:NTFS then loads the relevant NTFS EFI driver, locates the existing NTFS partition on the same media, and executes the /efi/boot/bootx64.efi or /efi/boot/bootia32.efi that resides there. This achieves the exact same outcome as if the EFI firmware had native NTFS support and could boot straight from NTFS.
Akeo Consulting is an Irish Software Development company, expertise ranging from OSS development, Embedded Systems and SoCs development, Security, Web Services technologies, Operating Systems, Reverse Engineering, e-Papertechnologies and more. Pete has a blog with UEFI- and other firmware-related posts, and other UEFI-related projects.
Off-topic rant: These kinds of hacks are needed because UEFI requires FAT32 for it’s EFI System Partition (ESP). Apple also supports HFS+ as well as FAT for their ESP. UEFI spec requires vendors only support FAT. As I understand this, it’s mainly because FAT is widely-supported, Microsoft requires it for Windows OEMs, and having more than one file system would make life a bit more complex for UEFI developers, a complexity that Apple’s UEFI developers are already dealing with. With a little bit of interop testing, each OS could have an EFI file system that understands it’s preferred native file system format, which may enable better disk encryption, and fewer support issues with the foreign FAT file system. A problem with using any other file system for UEFI is that all vendors won’t necessarily support it, an install-time issue. I wish we had Ext4 and ZFS file system drivers for UEFI in mainstream use (inside IBV solutions, so they’re useful). Microsoft will of course require only FAT for Windows OEMs. Personally, I’d like to see the UDF file system, used by DVDs, more widely adopted as the second file system for UEFI ESP, as a FAT alternative. Most OSes already support UDF (though with some edge-case errors, which could be fixed), and it’s one of the few common file systems that support large files. If you have to deal with some large ISO/image in the UEFI Shell, you’re limited by FAT32’s small file size limits. Someone has already submitted a UDF into Tianocore. It isn’t perfect, there are probably better choices for some flash-based systems, but it could enable a FAT-free Linux/FreeBSD system.