Support booting of .VHD in VirtualBox/VMware after installing vtoyboot - Add fallback if Ventoy is not active

[ThelloD]

I would like to be able to boot Kali Linux (encrypted volume) from from a .VHD disk image using virtualization (VirtualBox or VMware) while still being able to boot this .VHD file using Ventoy.

Booting from the .VHD in VirtualBox worked fine before running "vtoyboot.sh". Unfortunately, after following the install instructions and running vtoyboot.sh, I'm no longer able to boot the from the .VHD using VirtualBox. The boot attempt hangs with the following message: Waiting for encrypted source device /dev/mapper/ventoy3

Booting the .VHD using Ventoy works fine, but vtoyboot seems to break compatibility with virtualization solutions. The problem occurs because the boot routine waits for the /dev/mapper/ventoy3 which will not appear the boot is not initialized using Ventoy.

It would be great, if vtoyboot would first verify, if booting is attempted using Ventoy, and if Ventoy is not active (e.g. booting the VHD using VirtualBox), to skip all customizations that have been applied by vtoyboot.

(On a side note, it would be great if either uninstall instructions would be added or vtoyboot.sh would also offer an uninstall routine)

Is there any chance that vtoyboot will skip its routines if Ventoy is not active and therefore allow booting of disk images in a virtual machine?

[ThelloD]

Further investigation showed that apparently the issue was caused by installing the Nvidia driver while the guest OS was booted via Ventoy. Therefore, it seems I have to apologize for creating this inaccurate bug report. Because of the changelog of 1.0.4 (No need to run vtoyboot.sh again after initramfs file updated (e.g. after install some drivers)) and the the fact that booting hanged while waiting for /dev/mapper/ventoy3 I assumed that installing the Nvidia driver should not have an impact on vtoyboot and that this issue is caused by vtoyboot.

I've started over again but this time I installed the Nvidia drivers while the guest system was booted within VirtualBox. After booting the .VHD using Ventoy, the Nvidia driver was loaded successfully and switching back to VirtualBox booting the .VHD as a virtual machine still worked. 👍

Unfortunately I don't know whether running vtoyboot.sh would have fixed the issue or if the Nvidia driver messed up some other config files as well. Therefore, I'll leave the issue open for now in case you want to take a look as well, but personally I'd also be fine if you would like to close the issue.

[ventoy]

Yes. It's better to install all the drivers in the VirtualBox firstly, after that copy the vdi file to Ventoy disk and boot. But normally, the system will look for partition uuid not fixed device name(e.g. /dev/sda1 /dev/mapper/ventoy). I don't known why kali use /dev/mapper/ventoy3 instead of UUID, maybe because you use encrypted volume?

[DRRDietrich]

I'm having the same problem with a Fedora 33 VM. However, I use virt-manager, kvm and qemu. The system also runs from an encrypted partition (btrfs-luks). It ran smoothly in virt-manager until I ran the vtoyboot.sh. After that it ran without any problems with ventoy, but no longer in virt-manager. (There it could only be started with kernel versions that were not modified by the script)

[candrapersada]

@ThelloD (On a side note, it would be great if either uninstall instructions would be added or vtoyboot.sh would also offer an uninstall routine)

why is there no uninstall in vtoyboot?

[urigg]

I'm having same issues with dual booting Debian with encrypted root:

• Update initramfs from vtoy: Does boot on vtoy but not in VirtualBox
• Update initramfs from VirtualBox: Does boot on both ways.

I've debugged through the initramfs and found the reason in my case: The root file system in VirtualBox was /dev/sda3, and in vtoy /dev/mapper/ventoy3. When running mkinitramfs inside VirtualBox, the generated crypttab uses UUID to find the source partition, when running in vtoy, it was using /dev/mapper/ventoy3 literally.

Source was /usr/share/initramfs-tools/hooks/cryptroot, that has a detection for everything /dev/mapper, and refuses to use UUIDs in that case. By sabotaging that detection (changed it to /dev/xxmapper) I was able to regenerate an initrd that allowed me to boot in VirtualBox again.