# UEFI:NTFS: booting an NTFS partition from firmware that only speaks FAT32

> UEFI:NTFS is a GPL-2.0 licensed UEFI bootloader by the Rufus author that loads an NTFS driver and chainloads the real boot file, which removes the FAT32 restriction most firmware imposes. The interesting constraint is Secure Boot, where only the GPLv2 ntfs-3g drivers can be signed by Microsoft.

**pbatard/uefi-ntfs** — UEFI:NTFS - Boot NTFS or exFAT partitions from UEFI

- Repository: https://github.com/pbatard/uefi-ntfs
- Stars: 1,010 · Forks: 164
- Language: C
- License: GPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/pbatard-uefi-ntfs

## The FAT32 restriction is a manufacturer choice, not a spec

UEFI:NTFS is a generic bootloader designed to allow boot from NTFS or exFAT partitions, in pure UEFI mode, even if your system does not natively support it.

The README spends a paragraph correcting a widespread belief, and it does so with some heat, noting that there appears to exist a lot of inaccurate information about this on the Internet. There is absolutely nothing in the UEFI specifications that actually forces the use of FAT32 for UEFI boot. On the contrary, UEFI will happily boot from any file system, as long as your firmware has a driver for it.

So the restriction is not in the standard. It is the choice of system manufacturers, who tend to only include a driver for FAT32, and that leads many to erroneously believe that only FAT32 can be used for UEFI boot.

That reframing is what makes the project worth understanding. The problem is a commercial decision by firmware vendors, not a technical impossibility, and a project that removes the restriction is doing something that no amount of specification reading would achieve.

The stated use is with Rufus, which is by the same author, but it can also be used independently. The concrete motivations given are UEFI-booting a Windows NTFS installation media containing an install.wim larger than 4 GB, something FAT32 cannot support, and dual BIOS plus UEFI boot of Windows To Go drives.

## The two-partition trick and the chainload

The mechanism is described step by step, and the design is elegant because it does not need to change the partition layout anyone else expects.

Rufus creates two partitions on the target USB disk, and these can be MBR or GPT partitions. The first is an NTFS partition occupying almost all of the drive, containing the Windows files for Windows To Go or for a regular installation. The second is a very small FAT partition, located at the very end, that contains an NTFS UEFI driver and the UEFI:NTFS bootloader itself.

When the drive boots in UEFI mode, the first NTFS partition gets ignored by the UEFI firmware, unless that firmware already includes an NTFS driver, in which case two boot options will be available that perform the same thing. The UEFI:NTFS bootloader from the bootable FAT partition is executed. It then loads the relevant NTFS UEFI driver, locates the existing NTFS partition on the same media, and executes the boot file that resides there, and the relevant boot files are the /efi/boot/bootia32.efi, /efi/boot/bootx64.efi, /efi/boot/bootarm.efi or /efi/boot/bootaa64.efi depending on the architecture.

The result, as the README puts it, achieves the exact same outcome as if the UEFI firmware had native support for NTFS and could boot straight from it.

Two things are worth noting about the layout. The FAT partition is at the very end of the drive, which keeps it out of the way of the operating system's partition handling and out of the way of anything that assumes the first partition is the important one. And the driver is loaded from the same FAT partition rather than being built in, which is what makes it possible to swap the driver without rebuilding the bootloader.

## Secure Boot, and the GPLv3 wall

The Secure Boot section is where this project hits a constraint it cannot engineer around, and the documentation is unusually clear about it.

UEFI:NTFS is compatible with Secure Boot and has been signed by Microsoft. Secure Boot signed binaries for x86_64, x86_32 and ARM64 are available in the uefi-ntfs.img archive of Rufus.

The restriction comes next. Due to Microsoft arbitrary restrictions regarding GPLv3, the only drivers that can currently be used with UEFI:NTFS in a Secure Boot environment are the GPLv2 licensed ntfs-3g ones. The NTFS and exFAT drivers from EfiFs, which are derived from GRUB 2.0 and therefore GPLv3, cannot be submitted to Microsoft for signing.

So the licence of the driver determines whether your boot media will boot on a Secure Boot machine. That is an unusual coupling, and it is a direct consequence of how Secure Boot works: a signed bootloader can only load signed drivers, and Microsoft will not sign GPLv3 code.

There is one more gap. Microsoft's current Secure Boot signing policies require additional validation for 32-bit ARM, therefore the 32-bit ARM binaries are not Secure Boot signed. The documentation notes that this does not affect 64-bit ARM, known as ARM64, AARCH64 or AA64, for which there are fully Secure Boot signed binaries.

The licence itself is GPL-2.0, which is what makes the project compatible with the GPLv2 ntfs-3g driver it loads in the signed configuration. A GPLv3 driver could not be signed and would have to be loaded with Secure Boot disabled, which is a constraint worth understanding before you commit to a driver choice.

## Building it: gnu-efi, EDK2 and QEMU

There are two toolchains, and the project supports both, which is unusual for a bootloader of this size.

The prerequisites are Visual Studio 2026 or MinGW, or MinGW64, preferably installed using msys2, or gcc. Plus QEMU v2.7 or later, with Windows binaries linked separately, plus git, and wget and unzip if not using Visual Studio.

With gnu-efi the build is simple. The project can be compiled against the gnu-efi library rather than EDK2, and for that you may need to initialize the git submodules:

```
git submodule update --init
```

Then, if using gcc with gnu-efi, you should be able to simply issue make. You can also issue something like make ARCH=<arch> CROSS_COMPILE=<tuple>, where arch is one of ia32, x64, arm or aa64 and the tuple is the one for your cross-compiler, for example aarch64-linux-gnu-. You can also debug through QEMU by specifying qemu to your make invocation, though that turns the special _DEBUG mode on, and the documentation warns that you should run make without invoking qemu to produce proper release binaries. That is a genuinely useful warning, because a debug bootloader built by accident and shipped is a different artefact from a release one.

The Visual Studio solution is the fastest route. If using the solution file, just press F5 to have the application compiled and launched in the QEMU emulator, so a full build and test cycle is one keypress.

The EDK2 route is for people who want the full EDK2 build system. On Windows with EDK2 in D:\edk2 and nasm in the BaseTools directory, the sequence sets EDK2_PATH, NASM_PREFIX, WORKSPACE and PACKAGES_PATH, runs edksetup.bat reconfig, and then builds with build -a X64 -b RELEASE -t VS2022 -p uefi-ntfs.dsc. On Linux with edk2 in /usr/src/edk2, the equivalent uses export for the same four variables, sources edksetup.sh --reconfig, and builds with build -a X64 -b RELEASE -t GCC5 -p uefi-ntfs.dsc.

The repository layout backs this up. There is boot.c, boot.h, path.c and system.c as the C sources, with a Makefile for the gnu-efi path, a uefi-ntfs.sln for Visual Studio, and the EDK2 package description files uefi-ntfs.dsc, uefi-ntfs.dec, uefi-ntfs.inf and uefi-ntfs.uni, plus a gnu-efi/ directory and a .vs/ directory.

## Installing it without compiling anything

Most people who want this do not need to build it at all, and the README covers that case first.

A ready-to-use FAT partition image, containing the x86 and ARM versions of the UEFI:NTFS loader, both 32 and 64 bit, and the driver, is in the Rufus project under /res/uefi. The file is uefi-ntfs.img.

The procedure is to create a partition of the same size at the end of your drive and copy uefi-ntfs.img there, in DD mode of course, and then you should have everything you need to make the first NTFS partition on that drive UEFI bootable.

That is the whole install for the independent use case, and it is a good illustration of the design. There is no installer, no registry, no configuration file, and no persistent state in the filesystem. The bootloader is a file in a FAT partition, and the NTFS partition it needs to find is found at runtime by scanning the same media.

The fact that the image contains the ARM versions as well as the x86 ones is worth noting, since the Secure Boot section covered signed binaries for ARM64 and x86_64 as well. The same image therefore serves the desktop and the ARM board use case.

The security and governance files are worth mentioning separately. There is a SECURITY.md at the repository root for reporting vulnerabilities, and a LICENSE.txt carrying the GPLv2 terms. The release history shows v2.8 from 2026-06-10, v2.7 from 2026-02-09 and v2.6 from 2025-10-24, and the last push was on 2026-07-27, so this is an actively maintained component rather than a one-off.

## Conclusion

UEFI:NTFS is a good pick if you are building boot media that has to hold a Windows image larger than 4 GB or must support both legacy BIOS and UEFI boot from the same stick, because the two-partition layout is a workaround for a firmware limitation rather than a limitation of the UEFI specification, and the chainload arrives at exactly the same result as native NTFS support; it is the wrong tool if you are on a machine whose firmware already ships an NTFS driver, and before you ship anything Secure Boot enabled you should note that only the GPLv2 ntfs-3g drivers can be signed, so the exFAT and GRUB derived drivers are not available in that environment.

## FAQ

### What does UEFI:NTFS do?

It is a generic bootloader that allows boot from NTFS or exFAT partitions in pure UEFI mode even if the system does not natively support it. It loads an NTFS UEFI driver, locates the existing NTFS partition on the same media, and executes the boot file there, achieving the same result as native NTFS support.

### Is FAT32 really required for UEFI boot?

No. The README states there is absolutely nothing in the UEFI specifications that forces FAT32 for UEFI boot, and that UEFI will boot from any file system as long as the firmware has a driver for it. The restriction comes from system manufacturers who tend to include only a FAT32 driver.

### Which NTFS driver works with UEFI:NTFS under Secure Boot?

Only the GPLv2 licensed ntfs-3g ones, because Microsoft will not sign GPLv3 code. The NTFS and exFAT drivers from EfiFs, which derive from GRUB 2.0 and are therefore GPLv3, cannot be submitted for signing. UEFI:NTFS itself is Secure Boot signed for x86_64, x86_32 and ARM64, but the 32-bit ARM binaries are not.

### How do I build UEFI:NTFS?

With gcc and gnu-efi, run git submodule update --init and then make, optionally with ARCH and CROSS_COMPILE for cross-compiling, where arch is ia32, x64, arm or aa64. With the Visual Studio solution you can press F5 to build and launch in QEMU. The EDK2 route uses build -a X64 -b RELEASE -t VS2022 or GCC5 with the uefi-ntfs.dsc package.

### How do I install UEFI:NTFS without building it?

A ready-to-use FAT partition image with the x86 and ARM loader and driver is in the Rufus project under /res/uefi, as uefi-ntfs.img. Create a partition of the same size at the end of your drive, copy the image there in DD mode, and the first NTFS partition on that drive becomes UEFI bootable.

## Sources

- [Issues](https://github.com/pbatard/uefi-ntfs/issues)
- [License: GPL-2.0](https://github.com/pbatard/uefi-ntfs/blob/master/LICENSE)
- [pbatard/uefi-ntfs on GitHub](https://github.com/pbatard/uefi-ntfs)
- [README](https://github.com/pbatard/uefi-ntfs/blob/master/README.md)
- [Releases](https://github.com/pbatard/uefi-ntfs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pbatard-uefi-ntfs