Ventoy turns one USB drive into a menu for booting many disk-image files. After preparing the drive, the user copies ISO, WIM, IMG, VHD, VHDX, or EFI files onto its main data partition. At startup, the boot menu searches that partition and its folders, lists the images alphabetically, and starts the one selected. This differs from a conventional USB writer, which normally replaces the previous boot image whenever another operating-system image is written.
Install erases the drive
The first Ventoy installation repartitions and formats the selected USB device. Existing files on that device disappear, so the disk model and capacity must be checked before pressing Install. Selecting an external backup disk by mistake can destroy its partition layout. The separate non-destructive method still changes the master boot record and the first megabyte, and its documentation treats that route as experimental.
Ventoy creates a small boot partition and a larger partition for files. The user may reformat the data partition with another supported filesystem after installation. Partition style must be chosen during installation, however. Changing between MBR and GPT later is not the same as copying a new ISO and can require rebuilding the device.
Images remain ordinary files
Boot images can sit in the root or inside folders. Ventoy searches recursively, so organising installers by operating system does not remove them from the menu. Updating the Ventoy boot components normally leaves these image files intact. The update does not update the operating systems inside the images; replacing an old ISO still requires downloading and copying a newer one.
The menu can list several images that have similar names. Ventoy does not decide which edition, architecture, or rescue environment fits the computer. Clear filenames help distinguish a desktop installer from a server image or a firmware utility. A damaged or incomplete image can still appear in the menu and fail only after boot begins.
Secure Boot enrolment
Ventoy can work with Secure Boot, but the first start may open a firmware enrolment screen. The user may need to enrol the Ventoy key or allow the Microsoft third-party UEFI certificate authority. That choice belongs to the computer firmware, not the USB file browser, and the wording varies between manufacturers.
Some firmware rejects this path even when the option is enabled. The documented fallback turns off Ventoy Secure Boot support and then disables Secure Boot in the firmware. That changes a machine security setting and may affect another installed operating system. Recording the original firmware state makes it easier to restore after the temporary boot job ends.
Persistence needs mapping
Copying a live Linux ISO creates a bootable session, but it does not automatically preserve documents and settings. Ventoy persistence uses a separate data image plus a JSON plugin entry that maps that storage to the chosen ISO. Different Linux distributions expect different labels or persistence layouts, so one generic file does not work with every image.
A distribution can boot normally while ignoring a wrongly labelled persistence file. Testing requires creating a small file, restarting, and confirming that it remains. The user should also let pending writes finish before unplugging the drive; persistence data can corrupt when the operating system still has changes in memory.
One menu, many variables
Ventoy removes repeated image writing, but it cannot remove differences in UEFI mode, legacy BIOS support, image design, storage drivers, or firmware rules. An image that boots on one computer may stop on another. Keeping one known rescue image and testing the USB before an emergency gives the menu a verified fallback rather than a collection of untested downloads.
