Official FAQ
Ventoy Version
1.1.16
What about latest release
No. I didn't try the latest release.
Try alternative boot mode
Yes. I have tried them, but the bug still exist.
BIOS Mode
Legacy BIOS Mode
Partition Style
MBR
Disk Capacity
64GB
Disk Manufacturer
No response
Image file checksum (if applicable)
None
Image file download link (if applicable)
No response
What happened?
Live Injection does not inject files into a custom Ubuntu 26.04 (casper-based) ISO, even though the injection archive is correctly staged in the initramfs. hook.sh from the LiveInjection tool appears to never actually be invoked (or is invoked without the expected ostype argument), so it exits immediately without doing anything.
I use ventoy.json:
{
"injection": [
{
"image": "/custom_iso_2026-07-10_09-42-24.iso",
"archive": "/vpn-secrets-injection.tar.gz"
}
]
}
Injection archive built via ventoy/LiveInjection v1.0's pack.sh
Expected: /opt/vpn-secrets/{bootstrap.conf,secrets.env} exist in the booted live system.
Actual: /opt/vpn-secrets/ does not exist at all.
Investigation: Dropped into an initramfs shell right after casper-bottom scripts run (break=bottom). Found /live_injection_/ staged correctly (hook.sh, distro/, sysroot.tar.gz), but sysroot.tar.gz is still packed/unextracted and no log file exists — per hook.sh's own code, this means it hit its very first check (ostype=$1; [ -n "$ostype" ]) and exited immediately, implying it was called with an empty/missing argument, or never called. Confirmed via dmesg that /vtoy/vtoy runs as PID 1 init. Grepping the distro's own initramfs (/init, all of /scripts/, /ventoy/hook/) for live_injection finds nothing, confirming the (attempted) call happens entirely inside the closed /vtoy/vtoy binary. Statically verified all of debian/hook.sh's own prerequisites are met: /scripts/casper-bottom/ exists with an ORDER file, /root is the real final-rootfs mountpoint.
Question: Is there a known issue with Live Injection and layered-squashfs/newer casper ISOs where /vtoy/vtoy fails to determine/pass the OS type to hook.sh?
Official FAQ
Ventoy Version
1.1.16
What about latest release
No. I didn't try the latest release.
Try alternative boot mode
Yes. I have tried them, but the bug still exist.
BIOS Mode
Legacy BIOS Mode
Partition Style
MBR
Disk Capacity
64GB
Disk Manufacturer
No response
Image file checksum (if applicable)
None
Image file download link (if applicable)
No response
What happened?
Live Injection does not inject files into a custom Ubuntu 26.04 (casper-based) ISO, even though the injection archive is correctly staged in the initramfs. hook.sh from the LiveInjection tool appears to never actually be invoked (or is invoked without the expected ostype argument), so it exits immediately without doing anything.
I use ventoy.json:
{
"injection": [
{
"image": "/custom_iso_2026-07-10_09-42-24.iso",
"archive": "/vpn-secrets-injection.tar.gz"
}
]
}
Injection archive built via ventoy/LiveInjection v1.0's pack.sh
Expected: /opt/vpn-secrets/{bootstrap.conf,secrets.env} exist in the booted live system.
Actual: /opt/vpn-secrets/ does not exist at all.
Investigation: Dropped into an initramfs shell right after casper-bottom scripts run (break=bottom). Found /live_injection_/ staged correctly (hook.sh, distro/, sysroot.tar.gz), but sysroot.tar.gz is still packed/unextracted and no log file exists — per hook.sh's own code, this means it hit its very first check (ostype=$1; [ -n "$ostype" ]) and exited immediately, implying it was called with an empty/missing argument, or never called. Confirmed via dmesg that /vtoy/vtoy runs as PID 1 init. Grepping the distro's own initramfs (/init, all of /scripts/, /ventoy/hook/) for live_injection finds nothing, confirming the (attempted) call happens entirely inside the closed /vtoy/vtoy binary. Statically verified all of debian/hook.sh's own prerequisites are met: /scripts/casper-bottom/ exists with an ORDER file, /root is the real final-rootfs mountpoint.
Question: Is there a known issue with Live Injection and layered-squashfs/newer casper ISOs where /vtoy/vtoy fails to determine/pass the OS type to hook.sh?