[RFE] autodetect/parametrize vtoyboot to skip if virtual-machine boot

[hgkamath]

Feature: to autodetect/parametrize vtoyboot to skip making dm-device. This allows for the usecase wherein the image can also be booted from inside a virtual-machine

I understand that vtoyboot is a script that introduces a script into initramfs bootsequence and uses dm/device-mapper to synthesize a 'ventoy' disk to mount and pivot-to-the-rootfs while native-booting from ventoy.

my setup

• I have 3 internal disks sda sdb sdc
• I intend to ventoy-native-boot an image (40GB raw) located on an ntfs3 partition sdc1
• ventoy is installed to sdc2, and can be used to boot images in sdc1.
• Sometimes I boot from my regular linux OS installed to sda5, and run a qemu VM

After running vtoyboot.sh inside the VM/qemu, quite expectedly, as it introduces script into initramfs, the image can no longer boot from inside the VM/qemu. It is however possible to boot into image via ventoy-native-boot.

It may be desirable for the vtoyboot initramfs script to skip and not do its thing (as though vtoyboot is not run), when being booted in a VM, as qemu already provides an emulated virtualdisk to the booted OS.

Q) is there a grub2 command line argument or detectible ventoy environment variable that when detected can skip making the dm device and continue to pivot to rootfs as normal and continue booting the main bootdisk ie /dev/sda ?

workarounds:

1. create another identical boot image (40GB raw), so that there are two boot images for ventoy-native-boot and VM-boot
2. or have a small 1gb boot partition virtual-disk for VM use, attach both virtual-disks to the VM and start VM-boot so as to start boot from the 1gb disk. When this small boot partition is booted in VM, it will pivot-to-the-rootfs on the original image.

• it is debatable whether it is correct to reuse a boot image in this way having alternate bootup-methods.
• other host disks will need to be mounted differently in each case, and so either it may need to be done manually, or be scripted to do differently based on boot environment detection.

my Apologies if I am missing something or understood wrong about vtoyboot, I am new to vtoyboot.

[ventoy]

vtoyboot does detect the boot environment when booting.
If currently is not booted from Ventoy then it will not create dm device and will continue the normal boot.

[ventoy]

1. Create a new disk image and boot from QEMU
2. Install a distro to the VM (e.g. Ubuntu)
3. After install, run vtoyboot in the system.
4. reboot the VM

Can step 4 boot normal to the VM? (I test with VirtualBox and this is OK)

[hgkamath]

okay, its my bad. Sorry for false alarm and thank you for replying. There have been package-updates in the intervening time and so bug may have been spurious.

I attempted a couple of VM boots, post-install of vtoyboot and image booted successfully to GUI.
Image installed was a fresh fedora 36 beta

host-kernel: 5.17.0-0.rc5.96.fc35.x86_64 (self built from srpm)
qemu: qemu-system-x86-6.2.0-2.fc35.1.x86_64 (self built from srpm)
guest-kernel: 5.17.0-0.rc7.117.fc36.x86_64 
[root@sirius gana]# XDG_RUNTIME_DIR=/run/user/1000 qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/OVMF_VARS.fd" -drive "index=2,format=raw,file=/vol/15KJ_Images/transcend/m02_lnx.raw.img.vtoy"  -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc"-net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait
qemu-system-x86_64: warning: hub 0 with no nics
gl_version 46 - core profile enabled
GLSL feature level 460

Its good to know that it will also work on virtualbox.

I should have been more perceptive and looked more closely to see how far into the boot process that spurious attempt had gone, and for what reason it stalled. I will do so next time if it ever reoccurs.

I will close this bug for now, and reopen only if I can recreate it.