MultiOS-USB: one stick that boots every ISO you drop onto it

One device, many installers

MultiOS-USB is a tool for putting multiple operating system images on a single removable device. The one-line description in the README is the clearest statement of the idea: one device with multiple ISO/WIM files, easy to use, install once, add ISO/WIM files and boot computers from it.

That last clause is the important one. The usual approach to a multi-boot stick is to install each image with its own tooling, which rewrites the bootloader every time and leaves a partition layout that only the tool that created it understands. MultiOS-USB separates the two concerns. The bootloader is installed once, and after that the images are just files you copy onto the device.

The consequence for a user is that adding a new OS takes no reinstallation. The README says you can add support for new operating systems with no need to reinstall, and the update mechanism is a separate command that refreshes the configuration files, so the bootloader and the operating systems live in different places and are updated independently.

The feature list covers a wide range of boot targets: boot Linux from `.iso` images, boot WinPE from bootable `.wim` images, boot the Windows 10 and 11 installer from an ISO, boot Linux installers from the network, which is marked experimental, and boot locally installed systems, meaning Linux and Windows already on the machine's own disks. It also loads UEFI drivers, launches `.efi` executables and other boot loaders, and supports both x86 and x86_64.

The device types are equally broad, with support for USB, SSD, nvme, mmcblk, loop, nbd and virtual disks, which is what makes it usable for a machine you build a stick for rather than only for a USB stick in your pocket.

The project is GPL-3.0 licensed, the primary language is PowerShell, and the default branch is `master`. The recent releases are v0.14.2 from 2026-10-02, v0.14.0 from 2026-09-27 and v0.13.0 from 2026-08-06, and the last push was on 2026-10-12.

GRUB, loopback, and systems that have no loopback

The feature list names the mechanism in one line: automatic detection of compatible ISO images using GRUB loopback, alongside support for systems without loopback support.

Loopback mounting is the standard trick for booting an ISO from a filesystem rather than from optical media. GRUB can mount the ISO image as a filesystem and read the boot catalogue from inside it, which is what lets the stick present a menu of dozens of operating systems rather than a single chainloaded bootloader per image. The automatic detection is the part that saves effort: the tool inspects the images and works out which ones it can boot that way, so the menu is generated from what is actually on the device.

The support for systems without loopback is the more interesting engineering, because it implies a second path. When the firmware or the storage stack cannot present an ISO as a filesystem, the image has to be booted some other way, which in practice means extracting or chaining rather than mounting. The project does not describe the mechanism in the README, so the details are in the code and in the `config` directory, and the `docs/Supported_OS.md` list of tested images is the practical map of which path each image takes.

The configuration is data, and that is the part that makes the rest work. The tree has a `config/` directory, a `config_priv/` directory, a `themes/` directory, `binaries/`, a `cert/` directory and a `common.sh`. The bootloader reads its menu from those files, and the README explains the customisation route: to change the configuration for a given ISO, copy the file you have chosen from the `config` folder, paste it into `config_priv` and update it as needed, and the updated configuration will be detected automatically.

So an entry for a Linux installer with custom kernel options is a text file you can adjust per image, with a private overlay that wins over the shipped one, and no rebuild of anything. The customisation of the ISO boot menu, for example custom kernel options, is listed as a supported feature, and the `config_priv` mechanism is how you do it.

Secure Boot means a certificate on every new computer

Secure Boot support is listed as covering boot and the management of UEFI keys, and the README is straightforward about what that costs in practice.

On the first boot with Secure Boot enabled on each new computer, a MultiOS USB certificate must be installed. The documented procedure is a sequence of screens. You press Enter at the first prompt, then choose Enroll key from disk. Then you select `MultiOS-EFI` as the partition, browse to the `EFI/cert` directory and select `MultiOS-USB.cer`, then `Continue` and confirm the key enrolling with `Yes`. The same path can also be used to add certificates from popular distributions while you are there.

If you need to do it later, the README gives the route through the main menu: `EFI Tools` and then `Add UEFI key or hash`.

The per-machine nature of this is the operational point. The certificate lives in the machine's own firmware, so every new computer is a separate enrolment, and a machine with Secure Boot enabled will refuse to boot the stick until that has happened. For someone who plugs the same stick into a different laptop every week, that is a two minute ritual per machine. For a workshop where the same stick goes to twenty machines, it is a task someone has to plan for.

The `cert/` directory in the repository and the `MultiOS-EFI` partition naming are the artefacts behind this, and the fact that the project ships the certificate as a file rather than asking you to fetch it is a kindness. It is also the security boundary worth understanding: enrolling that key tells the firmware to trust this bootloader, and that trust is what lets it boot images the machine's own policy would otherwise refuse.

Four ways to install it

The install paths cover the main Linux distributions, and the README is explicit about which is the recommended one on Windows.

On SparkyLinux, it is a package:

# Refresh the package list and install MultiOS-USB
sudo apt update
sudo apt install multios-usb

# Display available USB devices
multios-usb -l

# Install to the selected device (replace sdX with your target device)
sudo multios-usb /dev/sdX

The `-l` flag lists the candidate devices, which is the safety step before anything destructive, and it is shown for every path.

With Nix, the project is a flake and can run without a permanent install, provided flakes are enabled:

# run without permanent install (flakes must be enabled)
sudo nix run github:Mexit/MultiOS-USB -- /dev/sdX

# create shell with MultiOS-USB available
nix shell github:Mexit/MultiOS-USB

On Arch Linux, the README points at the AUR, either through a helper or by hand:

# install using AUR helper like yay or aura
yay -S multios-usb-bin

# or install by cloning and executing makepkg -si
git clone https://aur.archlinux.org/multios-usb-bin.git
cd multios-usb-bin/
makepkg -si

And from the release archive on a Linux console, you unpack it, make sure the required tools are present, which are listed as tar, bzip2, xz, sgdisk, wipefs, mkfs.fat and mkfs.exfat, and then run the shell script directly:

./multios-usb.sh -l

followed by:

sudo ./multios-usb.sh /dev/sdX

For Windows, the README describes two routes, a PowerShell installer or manual installation which is UEFI only and is the recommended method for Windows, and an image based installation covering BIOS and UEFI which is marked experimental, with details in `docs/README_uefi` and `docs/README_image`.

Updating the configuration without touching the bootloader

The update story is the piece that makes the device worth keeping over years, and it is a deliberate separation of the bootloader from the menu configuration.

The README says you can add support for new operating systems with no need to reinstall, and gives two ways to update the configuration files. The automatic one is a single command against the device:

./multios-usb.sh -u /dev/sdX

The manual one is two steps that are worth reading even if you use the automatic path, because they explain the layout. You remove all files and directories on the USB in `/MultiOS-USB/config/`, and then copy the downloaded files and directories from `config` to that directory.

That path is also where your own settings live. The `/MultiOS-USB/config_priv` directory holds configuration files you add yourself, and they will not be deleted during the automatic MultiOS-USB update. So the structure is a shipped `config` directory that the updater is free to replace, and a `config_priv` directory that it must not touch. Your custom kernel options for one ISO live in the private directory, they override the shipped entry, and they survive every update.

For the user, the daily workflow is short. Copy your ISO files to the `/ISOs` directory and boot the computer from USB. The `ISOs` directory is a plain folder on the device, so adding an image is a file copy, and adding a boot entry is a text file, and neither requires the tool to run again.

One structural note about the project: the full source code lives on GitLab, while the GitHub repository carries the releases. The README points at both, and the distinction explains why the tree here contains `binaries/`, `common.sh`, `install.bat`, `install.ps1` and `multios-usb.sh` alongside the `config` directories, since the release archive is what you actually download and run.

What it does not do, and when a different tool fits better

There are three limits worth stating plainly, two of them flagged by the project itself.

The first is the Windows installation path. The PowerShell installer is described as UEFI only, and the image based installation covering BIOS and UEFI is marked experimental. On a Windows machine with legacy BIOS, or on a Windows installation path you do not want to experiment with, the Windows route is not the tool's strong suit.

The second is network booting of Linux installers, which is explicitly labelled experimental. The rest of the feature list is presented as working, and network boot is the exception.

The third is structural. The tool installs a bootloader and a menu onto a device and expects the images to be plain files. It is not a partitioning scheme, it does not create a recovery partition, it manages UEFI keys from its own boot menu, and it has no background services, which the feature list presents as a benefit and which is also a limitation if you wanted a tool to watch for changes.

The alternative approach, and the one to weigh against, is a virtualisation based installer, where you run the target OS inside a hypervisor on the machine rather than booting it from removable media. The difference in approach is that a virtualised install avoids the boot compatibility questions entirely, at the cost of being slower and of needing the target's own drivers rather than the live environment's.

For the case this tool actually serves, which is a technician carrying a stick of installers to customer machines, there is no real substitute. A stick with a working menu, offline, booting the real installation media, is a different tool from a virtual machine, and the effort this project saves is the effort of maintaining a per-machine multiboot setup by hand.

For a home user with one laptop, the effort of installing a bootloader, enrolling a certificate and learning the configuration layout may exceed the effort of just writing the ISO to a stick with the tool the image came with. The feature list is aimed at people who do this repeatedly.

Editorial conclusion

Adopt MultiOS-USB if you carry installers between machines, if you want one USB device to boot Linux installers, Windows installers, WinPE images and your own installed systems, and if you can accept enrolling a certificate on every new Secure Boot machine. Do not adopt it if you need a supported, signed multi-boot solution for an organisation, since the image based Windows installation path is marked experimental. Verify three things first: that the ISO you intend to boot is on the tested list in `docs/Supported_OS.md`, that your machine's firmware can boot the stick in the mode you need, BIOS or UEFI, and that the Secure Boot certificate enrolment is acceptable in your environment, because that step is per computer and cannot be skipped once Secure Boot is on.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Mexit/MultiOS-USB on GitHub
4. README
5. Releases