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