grub4dos: a boot manager built for USB sticks and Windows images

A boot manager whose reason to exist is FAT and Windows

grub4dos is described in the project as a multi-function boot and startup manager, and it is a C implementation of GRUB rather than a Linux distribution component. The interesting difference from the GRUB you meet on a Linux install is the target list. A GRUB build for Linux expects a filesystem it can read and a kernel it can load. grub4dos is built to boot things that are not Linux, and to do it from media that a Windows user can format without thinking.

The practical fit is a USB stick that has to be a rescue disk for a DOS-era tool, a Windows installer image and a Linux live image at the same time, controlled from a single text menu. That is a niche, but a real one, and the project has kept at it for a long time, with the repository showing release artefacts going back to 2021 alongside a much newer UEFI build.

The name in the repository description points at the structure. The project page links to grubutils as the source for the external commands used by both grub4dos and grub4efi, mkimage as the tool for generating the boot files, ntloader for booting Windows WIM and VHD images, and grub4dos-build as the compilation scripts. So the boot manager, the utilities it shells out to, the image generator and the build harness are four separate repositories that have to be kept in step.

The primary language is C, the licence is GPL-2.0, and the COPYING file in the repository root is the licence text.

Three branches, three changelogs, and a default that is not the newest

The repository does not have one line of development. It has named branches, each with its own changelog, and the default branch is 0.4.6a, which is labelled Legacy BIOS. The other two are master, labelled 0.4.5c and also Legacy BIOS, and efi, labelled for i386-efi and x86_64-efi.

The changelog files are named to match: ChangeLog_chenall.txt on the 0.4.6a branch, ChangeLog_GRUB4DOS.txt on master, and ChangeLog_UEFI.txt on the efi branch. That is a workable arrangement for a project that must support two different firmware models at once, and it means the sensible way to read about changes is to open the changelog that belongs to the branch you actually intend to build.

The release list explains the rest. The most recent asset is named grub4dos-for_UEFI-2026-05-07.7z, which points at the EFI branch and carries a May 2026 date. The two older assets are named after commit hashes and dates, 2021-01-12-4f0879b and 2021-01-10-4a3e488, which look like snapshot builds from a continuous integration run rather than curated releases. There is no version number to pin in those names.

The download page the project gives is its own site at grub4dos.chenall.net, with the GitHub releases page as a second route. Both are listed in the project description, and the download section of the README points at the same two places.

The autotools skeleton tells you what this thing is built from

The repository root is a GNU autotools project, and the file listing is a textbook one. There is configure.ac with its companion aclocal.m4 and acinclude.m4, a Makefile.am and Makefile.in, a GNUmakefile at the top, and config.h.in. The helper scripts are all present, install-sh, missing, depcomp, mkinstalldirs, config.guess and config.sub, along with compile and build as additional scripts. A bootstrap.sh and autogen.sh are there for regenerating the build system from a fresh checkout, which is what you need when configure itself has not been committed in a runnable state.

The presence of stage2/ in the root is the tell for anyone who knows GRUB's history. Stage 2 is the second-stage loader, the part of the boot chain that runs after the BIOS or firmware has handed over and before the full operating system kernel is loaded. A stage2 directory in the source tree means the boot code itself is being modified rather than merely configured, which is what separates a GRUB fork that does something unusual from a plain configuration of stock GRUB.

The configuration surface lives in the root as well, and the file names are the documentation. menu.lst is the classic GRUB menu file, preset_menu.lst is a template of the same, config.sys is the FreeDOS-style configuration read by DOS boot options, ldscript is a link script for the stage 2 build, grub.pif is a build information file, ipxegrldr.ipxe names the iPXE loader image, and grub4dos_version holds the version string. There is also a default file, which is likely the default configuration used at build time.

For a maintainer, this layout means the answer to most questions is in the file names. For a user, it means the build is a conventional ./configure and make project rather than something with an unusual toolchain.

Where to get it, and what to check before you write to a USB stick

The project does not publish installation instructions in the README, and it does not hand you a shell command to copy a binary onto a device. What it does is point at its own download site and the GitHub releases page, and it lists the external tools you need if you intend to build rather than download: grubutils for the external commands, mkimage for generating the boot files, and ntloader for booting Windows WIM and VHD images.

That is the correct behaviour for this project. A boot manager is written to a device, and a wrong write to the wrong partition is not something a convenience script should be doing behind your back. It also means there is no documented uninstall and no rollback step, so the assumption is that you keep the original bootloader image and can restore it with the vendor tool of your choice.

The two questions worth settling before you go further are which branch matches your firmware, and whether the media you are using is FAT. A FAT-formatted stick is the format this project is built around, and the fact that a Windows user can create one without extra tools is most of the reason it exists. If your media is NTFS or ext4, you are outside the comfortable case.

For a C project of this vintage, the build path is the autotools one, and the project's own grub4dos-build repository holds the compilation scripts. The build also needs a suitable C toolchain, and the i386-efi and x86_64-efi targets named on the efi branch tell you which architectures that branch covers.

Where grub4dos is the wrong tool

The first limitation is that it is not a modern Linux bootloader, and using it as one adds work rather than removing it. On a machine with UEFI and Secure Boot, a boot chain that does not participate in the platform's trust model will not start, and this project does not document a signed shim or a chain of trust. For a normal Linux installation, GRUB packaged by the distribution or systemd-boot already handles this, and the maintainer of a distribution will have far more context about your hardware than you do.

The second limitation is that the branches have diverged. The default branch is a legacy BIOS tree, the newest tagged asset is a UEFI build, and the two older assets are hash-named snapshots from 2021. The change logs are per branch, so a change present in one tree may never reach another. Anyone who depends on a specific behaviour needs to pick a branch and read that branch's changelog rather than assuming the project as a whole moved forward.

The third is the dependency on sibling repositories. grub4dos needs grubutils for its external commands, and it has a build-script repository of its own. None of that is under the same release discipline as a single self-contained tarball, so reproducing a build from source means assembling several repositories at roughly matching states. The GPL-2.0 licence means you are free to do exactly that, and the source is auditable, which is a genuine benefit, but it is not a one-command build.

The fourth is that the surface is a text menu. There is no graphical configuration tool, no automatic detection of what is on the stick, and no recovery mechanism described. A wrong menu.lst means editing a text file on the device with whatever tools you have at hand, which is why the simpler your media and the more careful your menu entry, the better this project works for you.

Editorial conclusion

grub4dos earns its place on a FAT-formatted USB stick that has to start DOS tools, Windows PE or WIM images, and Linux from one menu, since that combination of targets is what the project is built around, and the source is GPL-2.0 so you can audit and patch it. It is the wrong choice for a laptop's own bootloader, for a Linux distribution that already ships GRUB, and for anyone who needs a signed, chain-of-trust secure boot chain, because this project does not document one. Before using it, download from the project's own site or its GitHub releases, pick the branch that matches your firmware, since the legacy BIOS and UEFI trees are separate, and read ChangeLog_GRUB4DOS.txt, ChangeLog_UEFI.txt and ChangeLog_chenall.txt on the branch you pick, because the last push was on 2026-05-28 and the newest release asset is the UEFI build from 2026-05-07.

Frequently asked questions

Official sources

1. chenall/grub4dos on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases