YUMI builds one USB drive that can start several operating-system installers, live Linux images, rescue environments, and diagnostic utilities. Instead of overwriting the stick for every new ISO, YUMI creates a boot menu and stores multiple bootable items on the same device. The files remain separate choices at startup. This differs from copying ISO files into an ordinary folder, because the USB also needs boot partitions, menu data, and loader rules that computer firmware can start.
Choose the branch
The current project has two main paths. YUMI Py shares one codebase across Windows and Linux and receives the active cross-platform work. YUMI exFAT is a Windows-native alternative. Both use exFAT storage for current multiboot projects, which permits individual files larger than the 4 GB FAT32 ceiling.
Older Legacy and UEFI-only branches remain archived for historical hardware. They do not represent interchangeable interface choices. A Legacy build targets older BIOS behavior, while the current path accounts for modern BIOS and UEFI booting. Starting a new drive with an archived branch can create limits that adding a new ISO later will not remove.
Prepare the drive
YUMI needs a partitioned device with a bootable layout. Preparation can format the selected drive, which erases its existing files. The destination should be identified by capacity and model before the operation starts. An external backup disk can appear beside removable sticks, and choosing it by mistake can destroy unrelated archives.
The process creates boot data as well as storage space. Dragging the same ISO files back onto a newly formatted ordinary drive does not reconstruct that layout. A backup of important ISOs and persistence data should exist outside the USB before reformatting or changing its partition scheme.
Add boot images
Each supported distribution or utility has a menu entry and a method for locating or booting its image. YUMI can accept ISO, IMG, WIM, EFI, and virtual-disk material in documented paths. Adding an item does not mean that every image uses the same boot commands.
Filename detection can fail when a project names its ISO differently from the expected pattern. YUMI lets the operator force an image under a related distribution choice, but that only bypasses the filename filter. It does not make incompatible kernel parameters, partition expectations, or boot loaders match. The forced item still needs a real boot test.
Persistence varies
Persistence gives a compatible live system writable storage for settings and files across restarts. Support belongs to the distribution as well as to YUMI. Arch-, Fedora-, Ubuntu-, and some Debian-based images use different arrangements, and a live image can change its persistence rules between releases.
Recent Debian live media may expect a volume named persistence, a persistence.conf file, and a boot parameter. Other images use another label or no persistence at all. Allocating a persistence file cannot make an unsupported live system save changes. When persistence fails, the correct labels and boot entry need checking before the USB is rebuilt.
Test two ways
YUMI Py can start a temporary virtual-machine test for a drive or individual ISO. That catches missing files and many menu mistakes without restarting the computer. A virtual test still does not reproduce every firmware, graphics, storage, or Secure Boot condition on the intended physical machine.
The final check uses the target computer’s one-time boot menu and chooses the correct UEFI or legacy entry. Firmware may ignore a drive with an unsuitable partition layout, and one image may need a machine-specific boot parameter. Reaching the YUMI menu proves that the USB loader started; each important installer or rescue item must also reach its own usable screen.
Windows VHD limit
The guided Windows-on-VHD path depends on Windows disk and imaging commands. YUMI Py on Linux cannot run that guided flow even though it can prepare ordinary multiboot material. Building that particular VHD arrangement requires the Windows host path. Moving the finished drive between computers does not remove the host requirement that applied when the VHD was created.
