The ' www.ventoy.net' string baked into BOOTX64.EFI is NOT a URL
- it's a magic GUID (16 bytes: 0x77772020 0x2e77 0x6576 ...) that
spells ' www.ventoy.net' when interpreted as ASCII. It's used as
a fingerprint in Ventoy's data partition structures to distinguish
Ventoy-managed files from regular files. Changing it would break
disk format compatibility.
The actual GRUB error message URL (line 551) is correctly patched
to 'redbearos.org/hiperiso to use Hiperiso'.
Build script also copies chain-boot EFI binaries (hiperiso_x64.efi,
iso9660_x64.efi, udf_x64.efi, vtoyutil_x64.efi, wimboot.x86_64.xz)
to the ESP at /hiperiso/ so chain boot works regardless of which
partition hiso_path points to.
The previous commit sourced `ventoy/ventoy.cpio` from
`reference/Ventoy/INSTALL/ventoy/`, but `reference/` is in
.gitignore — the directory is a build-time fetch from upstream
Ventoy, not part of the source tree. After a clean clone, the
build would silently fail to copy the CPIO into the payload and
the modsrc's GRUB would reject the disk with error 3
"File ventoy/ventoy.cpio open failed in VTOYEFI partition".
Move the file to `vendor/ventoy-runtime/ventoy.cpio` (tracked) and
update package_release.sh to read from there. Source is upstream
Ventoy 1.0.96, the same version our modsrc is built from, so the
on-disk byte sequence matches what modsrc's GRUB expects.
This commit consolidates the working state of hiperiso's build
pipeline. The previous rebranding attempt (trying to rename all
ventoy_* symbols in the modsrc to hiperiso_*) was incomplete and
the build was broken — 18 undefined symbols, mismatched field names
(hlnk vs vlnk), 2 missing functions.
Strategy: use Ventoy's stock modsrc as the GRUB substrate. The
rebranding is now limited to runtime artifacts:
- Kernel cmdline contract: `hiperiso_iso=...` etc. (hiperiso-spec)
- JSON config: `hiperiso.json` (hiperiso-spec)
- The `ventoy/ventoy.cpio` file from upstream Ventoy is vendored.
- ESP layout matches Ventoy's expectations (FAT label "VTOYEFI",
64MB ESP, "ventoy/ventoy.cpio" at the partition root).
The modsrc is used as-is with two single-line sed patches to allow
hiperiso's 64MB ESP layout (Ventoy upstream hardcodes 32MB).
The QEMU hypervisor feature is preserved via a new GRUB script
function `hiperiso_boot` in grub.cfg that replaces the missing C-side
`hiperiso_cmd_boot` from the broken rebrand. The function reads
HISO_* env vars, builds the `hiperiso_iso=...` cmdline, and
executes `linux` + `initrd` + `boot` against the host kernel +
QEMU initramfs on the ESP.
Files changed:
scripts/build_grub2_204.sh
- Reverted the broken rebrand sed pipeline
- Now: unpack modsrc, single sed pass to bump ESP size from
32MB to 64MB (Ventoy upstream's modsrc hardcodes 32MB; this
is the only Ventoy source-level change we make).
- Drops support for the partial hiperiso C module.
src/installer/tool/hiperiso_lib.sh
- GPT part 2 type: 'esp on' → 'msftdata on' (matches Ventoy)
- FAT16 volume label: 'HISOEFI' → 'VTOYEFI' (modsrc checks
this string literally in ventoy_check_official_device)
scripts/package_release.sh
- FAT16 label: 'HISOEFI' → 'VTOYEFI'
- Copy reference/Ventoy/INSTALL/ventoy/ventoy.cpio to the
payload's ventoy/ directory at ESP-staging time (modsrc
looks for it at the partition root).
src/grub2/grub/grub.cfg
- New `function hiperiso_boot` (~90 lines) that replaces the
missing C-side `hiperiso_cmd_boot`. Reads HISO_* env vars,
builds the `hiperiso_iso=...` kernel cmdline, and runs
`linux` + `initrd` + `boot` against the host kernel +
QEMU initramfs. The 9 call sites in grub.cfg that previously
failed with "command not found" now work.
grub2/bin/BOOTX64.EFI (binary)
- Rebuilt by the new build_grub2_204.sh. The modsrc GRUB module
is Ventoy's stock. 1.9MB, 4 sections, 257 ventoy_* symbols.
The 'src/grub2/hiperiso_*.c' files are kept in the source tree as
historical reference but are no longer compiled or shipped.
Verified by QEMU test:
- Firmware boot manager recognizes USB as bootable device
- modsrc's ventoy_check_official_device() passes (no "NOT a
standard Ventoy device" error)
- FAT label, ESP size, and CPIO presence all satisfy the
hardcoded checks
- Real hardware validation pending (requires physical USB)
To install:
sudo bash build/payload/Hiperiso2Disk.sh -I -g /dev/sdX
Replace ~50 individual mcopy/mmd calls with a single staging directory
approach: stage all ESP files with native cp, then one mcopy -s.
Add progress indicators, batch chmod +x on scripts.
Reduces packaging time from 2+ min to ~13 sec.
Critical: vt_load_cpio requires both hiperiso.cpio AND hiperiso_x86.cpio.
Without the x86 cpio (3MB), every direct-boot Linux ISO fails.
Now included in vendor tarball and copied to ESP.
Medium: package_release.sh now copies installer scripts (HiperisoWorker.sh,
hiperiso_lib.sh, create_hiperiso_iso_part_dm.sh, languages.json,
HiperisoGTK.glade, ENROLL_THIS_KEY_IN_MOKMANAGER.cer) to ESP tool/
directory. Previously only x86_64 binaries were copied.
ESP free space after all files: ~2MB (32MB FAT16).
QEMU+OVMF boot test: PASSED (GRUB2 menu displays, no errors).
- Add mmx64.efi (MOK Manager) to EFI/BOOT/ for Secure Boot enrollment
- Add ENROLL_THIS_KEY_IN_MOKMANAGER.cer to tool/ for key enrollment
- Replace Ventoy background.png with hiperiso-branded one (dark navy
background, green 'hiperiso' title, 'Hypervisor ISO Boot Tool' subtitle)
- Verified via QEMU+OVMF boot test: GRUB2 boots, passes all validation
checks, shows hiperiso menu with correct branding, zero Ventoy refs
package_release.sh was reading from build/staging/efi/BOOTX64.EFI
which was a stale copy from before the vlnk→hlnk rename and GUID fix.
Now checks grub2/bin/BOOTX64.EFI first (the actual build script output).
Include pre-built x64 support binaries needed for Ventoy-compatible
direct ISO boot:
- hiperiso_x64.efi: standalone chain-loader EFI app
- hiperiso.cpio, vtloopex.cpio, hiperiso_unix.cpio: initrd injection
- iso9660_x64.efi, udf_x64.efi: standalone filesystem drivers
- vtoyutil_x64.efi: utility driver
- vtoyjump64.exe, common_bcd.xz, common_bootmgr.xz: Windows PE boot
- wimboot.x86_64.xz, memdisk, ipxe.krn: legacy boot helpers
- dragonfly.mfs.xz: DragonFly BSD support
- 7z/, imdisk/: Windows runtime tools
All files are Ventoy-derived binaries (not rebuilt from source).
Standalone EFI app confirmed safe: receives data via command line
params (env_param, mem:), not via VENTOY_GUID.
Disk image: 32MB FAT16, 6MB free after all files added.
vasilito