Ventoy - open source bootable USB tool

[Grogan]

I came across this coincidentally while reading an article. Someone was testing something and said "It took about a minute to boot with Ventoy..." and I thought, WTF is Ventoy? It turns out to be just what I need, if I can make it work for me.

Ventoy
https://www.ventoy.net/en/index.html

It's not just a bootable USB creator, it's a bootloader. You drop images in and it automatically will display them in a boot menu for you.

Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files.
With ventoy, you don't need to format the disk over and over, you just need to copy the ISO/WIM/IMG/VHD(x)/EFI files to the USB drive and boot them directly.
You can copy many files at a time and ventoy will give you a boot menu to select them (screenshot).
You can also browse ISO/WIM/IMG/VHD(x)/EFI files in local disks and boot them.
x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI, ARM64 UEFI and MIPS64EL UEFI are supported in the same way.
Most types of OS supported (Windows/WinPE/Linux/ChromeOS/Unix/VMware/Xen...)
1100+ image files are tested (list), 90%+ distros in distrowatch.com supported (details)

What I was dreading was either having to buy another USB stick, or having to sacrifice (well, not permanently) my good $100 Corsair one for a boot image. I will have to tear down the partitions and create one for this (I'm assuming) but once I get the device all set up again, it will remain in place. Need to boot something else? Drop it in.

This sounds great on paper, I'll have to get playing with this ahead of time. I would think though, I'll have to set it up for MBR booting for testing now though and redo it for UEFI. I can't see it supporting both boot methods (the low level bootstrap part I mean) at once (but I haven't read much yet).

There's binaries for Linux and Windows, and source code for moi

[Grogan]

Hoho... talk about an onerous build. There are no subprojects for its git repo, you have to get them all separately and put them in a certain directory for the build. The build dependencies are pretty onerous too. Not something I'm going to do to my LFS system, that's for sure.

So I found a PKBUILD on AUR (they have both a -bin for a binary repack, which would be pointless... download a binary then. and a build)

https://aur.archlinux.org/packages/ventoy

So I guess I'm building this on Arch. That's a lot of gymnastics, that PKGBUILD. That guy did a pretty good job of adapting this horrendous build procedure. Well, assuming it completes (it's been going for a while building all these projects). It should, it's seen some attention with a patch for the new binutils 2.42, so I'd assume it worked in the last few weeks. What the packager has to say about this is funny

# Maintainer: Toolybird <toolybird at tuta dot io>
#
# WORK IN PROGRESS
#
# <rant>This thing is a packaging nightmare!! The upstream build system is
# *especially* distro unfriendly (build on Centos 7...WTF?). Building from
# source to proper Arch standards is "interesting" to say the least.</rant>
#
# NOTE: upstream uses losetup (root) for disk image preparation and GRUB
# installation. Solved by utilizing libguestfs/QEMU.
#
# NOT INCLUDED (compared to upstream): ARM64, MIPS64, LiveCD.
#
# PROBLEMS: FIXME
#
# - ancient pkg versions used in the build
# - includes bundled / vendored sources
# - some third party / pre-compiled / downloaded binaries are used
#
# This PKGBUILD is based on "INSTALL/all_in_one.sh". The upstream build
# environment is Centos 7 (as root!). See "DOC/BuildVentoyFromSource.txt" and
# GitHub CI/docker files. The Ventoy code is unfortunately built upon very old
# and outdated pkgs. In order to achieve an initial working build, I've simply
# tried to replicate upstream procedures as much as possible. Some patches are
# required to successfully build on a modern Arch system. The main components of
# Ventoy are heavily modified versions of:
#
# - grub (Jul 2019) (2.04)
# - ipxe (Sep 2019) (3fe683e)
# - edk2 (Dec 2019) (201911)
#
# Please see the "License" folder for full details of various other bits that
# have been modified.

[Grogan]

It was almost successful. Everything compiled, but the libguestfs VM they are using in the PKGBUILD to manipulate the disk images they created, aborted with an unexpected condition of some sort, right after writing the partition tables to "disk" (an image file).

Code: Select all

'INSTALL.upstream/ventoy/common_bootmgr.xz' -> 'INSTALL/ventoy/common_bootmgr.xz'
'INSTALL.upstream/ventoy/memdisk' -> 'INSTALL/ventoy/memdisk'
'INSTALL.upstream/ventoy/dragonfly.mfs.xz' -> 'INSTALL/ventoy/dragonfly.mfs.xz'
:: image
Checking that no-one is using this disk right now ... OK

Disk img.bin: 256 MiB, 268435456 bytes, 524288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

>>> Created a new DOS (MBR) disklabel with disk identifier 0x34da6ae6.
img.bin1: Created a new partition 1 of type 'HPFS/NTFS/exFAT' and of size 223 MiB.
img.bin2: Created a new partition 2 of type 'EFI (FAT-12/16/32)' and of size 32 MiB.
img.bin3: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x34da6ae6

Device     Boot  Start    End Sectors  Size Id Type
img.bin1   *      2048 458751  456704  223M  7 HPFS/NTFS/exFAT
img.bin2        458752 524287   65536   32M ef EFI (FAT-12/16/32)

The partition table has been altered.
libguestfs: error: appliance closed the connection unexpectedly.
This usually means the libguestfs appliance crashed.

So it was obviously working, but it died while (or right after) writing the partition tables. I'll have to troubleshoot that... later. I might have to compile that stuff (libguestfs and qemu).

[Zema Bus]

I played around with it before, I think it was a couple years ago.

[Grogan]

Well, I made a nice mess last night installing a shit tonne of packages that I now have to uninstall in order (I started, but had to go to bed this morning). All of the gymnastics with that libguestfs (that also proved difficult to build) was to avoid having to be root. Well, it's my system and I am root. Sometimes ideology is just spinning wheels.

Since it's only for one-time or occasional use, all I had to do was run the wrapper script to prepare the disk and install the bootloader binaries. I would have liked to have compiled those myself, but oh well.

Code: Select all

[getstuffed ventoy-1.0.97]# ./Ventoy2Disk.sh -i -r 225280 -g /dev/sdc

**********************************************
      Ventoy: 1.0.97  x86_64
      longpanda admin@ventoy.net
      https://www.ventoy.net
**********************************************

Disk : /dev/sdc
Model: Corsair Voyager GTX (scsi)
Size : 238 GB
Style: GPT

You will reserve 225280 MB disk space 

Attention:
You will install Ventoy to /dev/sdc.
All the data on the disk /dev/sdc will be lost!!!

Continue? (y/n) y

All the data on the disk /dev/sdc will be lost!!!
Double-check. Continue? (y/n) y

Create partitions on /dev/sdc by parted in GPT style ...
Done
Wait for partitions ...
partition exist OK
create efi fat fs /dev/sdc2 ...
mkfs.fat 4.2 (2021-01-31)
success
Wait for partitions ...
/dev/sdc1 exist OK
/dev/sdc2 exist OK
partition exist OK
Format partition 1 /dev/sdc1 ...
mkexfatfs 1.3.0
Creating... done.
Flushing... done.
File system created successfully.
mkexfatfs success
writing data to disk ...
sync data ...
esp partition processing ...

Install Ventoy to /dev/sdc successfully finished.

That command installs Ventoy to the specified device (-i) and reserves 220 Gb of unpartitioned space on it (-r) so I can still use my stick. The -g is for GUID partition tables. By default, secureboot support is enabled, I saw no harm it letting it support that, for, say, booting someone else's computer or something with a Windows image. It will simply be disabled on mine.

I won't be able to test it, as I can't boot from that kind of disk setup, but I'll get the Arch ISO dropped in.

[Grogan]

So now my device is prepared. I used linux fdisk to claim the 220G of unpartioned space, and changed it to partition type 11 ("Microsoft basic data") and formatted it exfat. I did have a 32G fat32 partition for my tools stash, in case of older computers, but I think as long as they have Windows 7 SP1 they can read GUID partition tables and exfat filesystems.

Code: Select all

Device        Start       End   Sectors  Size Type
/dev/sdc1      2048  38679175  38677128 18.4G Microsoft basic data
/dev/sdc2  38679176  38744711     65536   32M Microsoft basic data
/dev/sdc3  38746112 500117503 461371392  220G Microsoft basic data

The first partition ("Ventoy" label) is exfat for the boot images. The second one is the FAT32 EFI partition where the boot loader stage is.

I think I can dump boot images anywhere on the first partition and it automatically looks for them in all subdirectories, according to the destructions, but I created a directory named bootimgs and dropped in archlinux-2024.03.01-x86_64.iso

I guess I could take this up to my parents' computer and see if it boots up to the menu at least.