Add a 'Build Architecture' section explaining the substrate
approach (Ventoy modsrc as the GRUB binary), the runtime bridge
via the hiperiso_boot GRUB script function, the two hardcoded
layout constraints (FAT label 'VTOYEFI', /ventoy/ventoy.cpio at
the ESP root), and the modsrc sed-patch strategy.
Without this, a future contributor reading the build script will
not understand why BOOTX64.EFI has ventoy_* symbols and the source
tree has unused hiperiso_*.c files; they will likely try another
incomplete rebrand.
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
Byte-by-byte comparison of Ventoy vs hiperiso USB showed the only
significant difference: Ventoy uses Microsoft basic data type GUID
(EBD0A0A2-...) with attribute 0x8000000000000000, while our ESP-type
attempt used (C12A7328-...).
The user's UEFI firmware only recognizes the msftdata+hidden attribute
combination as bootable. Reverted all 3 source paths back to msftdata:
- hiperiso_util.c: Table[1].PartType = WindowsDataPartType
- hiperiso_lib.sh: set 2 msftdata on (parted flag)
- partresize.c: g_WindowsDataPartGuid for partition resize update
- Partition 2 type GUID changed from msftdata (EBD0A0A2) to ESP
(C12A7328) in GUI installer, CLI partition resizer, and shell
installer. UEFI firmware only scans ESP-type partitions for
BOOTX64.EFI.
- GPT is now the default partition style (MBR via -m flag)
- Secure Boot default changed to OFF
- Fix PATH using $PWD instead of $OLDDIR in Hiperiso2Disk.sh
- Remove unused g_WindowsDataPartGuid dead code from partresize.c
Change GUI default from MBR (0) to GPT (1). Keep msftdata partition
type for partition 2 (Ventoy-compatible: both partitions visible to
OS and bootable on all UEFI firmware). Fix hisogpt.c partition name
check from VTOY to HISO. Fix partresize.c partition name from VTOYEFI
to HISOEFI.
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.
After writing the partition table, call ioctl(fd, BLKRRPART) to force
the kernel to re-read partitions immediately. Ventoy lacks this and
relies on replug. Also fix hardcoded loop count 32 to
HISOEFI_PART_BYTES / SIZE_1MB to match the new 64MB ESP size.
Original 32MB was at capacity (31MB data). Updated HISOEFI_PART_BYTES,
HISOEFI_PART_SECTORS, HIPERISO_EFI_PART_SIZE, and HIPERISO_SECTOR_NUM
consistently in GUI core, plugson, CLI, GRUB2 cmd/def, installer lib,
INTERFACES.sh, and README partition table.
PCCTS parser generator uses K&R-style function pointers void (*)() which
modern GCC (12+) rejects under -Werror (treats () as (void)).
Build with -std=gnu89 -Wno-error for the BaseTools C toolchain.
Two critical bugs prevented the hypervisor boot path from working:
1. GRUB2 EFI requires explicit gpt/msdos prefix in partition names.
The shorthand (hd0,2) does NOT resolve for GPT disks. Fixed by
having vt_load_part_table set hiso_iso_part/hiso_efi_part with
correct notation based on detected partition table type.
2. hiperiso_boot C function wrapped $hiso_efi_part in extra parens:
($hiso_efi_part) expanded to ((hd0,gpt2)) which GRUB2 parsed as
device name (hd0,gpt2) with literal parens. Fixed by using
${hiso_efi_part} without wrapping.
QEMU-verified: kernel boots, loads initramfs, runs /init with all
hiperiso_* parameters correctly passed through kernel cmdline.
Replaces placeholder with professional branded background:
- RedBear bear logo in top-left corner (red/crimson bear head)
- Green 'hiperiso' title with glow effect
- 'Hypervisor ISO Boot Tool' subtitle
- Red accent line under title
- 'A RedBear OS Project' attribution
- Faint bear watermark on right side (8% opacity)
- 'www.hiperiso.net' footer in green
- Dark charcoal gradient background
Visual identity derived from RedBear OS project assets on
gitea.redbearos.org. hiperiso is a subproject of RedBear OS.
QEMU+OVMF verified: all branding elements render correctly
in GRUB2 menu with test.iso listed.
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.
build_grub2_204.sh: Add vlnk/VLNK/Vlnk→hlnk/HLNK/Hlnk sed rules for
build-time transformation. Add targeted sed rule to replace VENTOY_GUID
hex values (0x77772020,0x2e77,0x6576,...) with HIPERISO_GUID values
(0x65706968,0x6972,0x6f73,...) so the binary GUID no longer spells
'www.ventoy.net' in memory.
build_gui_all.sh: Fix vlnk.c→hlnk.c reference in GUI build.
Apply vlnk→hlnk, VLNK→HLNK, Vlnk→Hlnk rename to all 7 reference
header and source files. These are the project-side copies used for
cross-referencing — the build applies the same transformation to the
vendored tarball at compile time.
Rename vlnk.c→hlnk.c, vlnk.h→hlnk.h. Update crc32.c and main_linux.c
references. The file format concept changes from 'Ventoy Link' to
'Hiperiso Link' throughout. hisolnk tool builds successfully (19K).
hiperiso_cmd.c: Remove stub implementations of hiperiso_gzip_compress,
lzx_decompress, xca_decompress. Restore real miniz-based gzip compression
and include miniz.h. Add 'Hypervisor (KVM + Boot Logging)' as option 7
in secondary boot menu with hiso_hv_mode env var check.
grub.cfg: Replace stripped 473-line version with full 2806-line config
restoring all OS-type direct boot paths (Linux, Windows, Unix, WIM, VHD,
IMG). Add hiso_hv_mode checks to all 8 menuentry functions and
post-secondary-menu hypervisor dispatch. Set HISO_HYPERVISOR_MENU=1
by default so secondary menu always appears.
Re-add 9 missing source files (huffman.c/h, lzx.c/h, miniz.c/h, xpress.c/h,
wimboot.h) to grub2-modsrc.tar.xz. Previous dead-code stripping incorrectly
removed these — they provide lzx_decompress, xca_decompress, and gzip
compression needed for WIM boot and initrd modification.
The awk patterns in hw_gen_pci_json() targeted a hypothetical output format
that never matched QEMU's actual HMP 'info pci' response:
- /^Bus / anchored to line start, but QEMU outputs ' Bus ' (2 leading spaces)
- /vendor_id = / expected 'vendor_id = 0x8086', but QEMU prints 'PCI device 8086:2922'
- /device_id = / expected separate line, but vendor:device are on the same line
- /class = / expected 'class = 0x010601', but QEMU prints 'SATA controller:' or 'Class 0106:'
- IRQ field expected 'IRQ 0.' but QEMU prints 'IRQ 5, pin A'
Result: pci_summary.json was always invalid JSON with orphaned key-value pairs.
Fix verified against QEMU source (pci-hmp-cmds.c:31-51) and tested with
realistic 4-device output: all devices correctly parsed with bus/dev/fn,
vendor_id, device_id, and IRQ fields.
Found by: 5-agent parallel review (QA execution agent)
vasilito