Presently vtoyboot.sh assumes that native boot disk is the first disk, which could be /dev/sda or/dev/mapper/ventoy and assumes that boot and root partitions are on it. It bails out if there is more than 1 /dev/[vsh]d? device.
vtoyboot just calls dracut on rootfs to create the initramfs with the vtoy-tools and puts it in /boot
Let vtoyboot.sh take
root partition mount-point (/) as argument-1 (for path to tools and kernel-modules)
target partition mount-point (/boot) as argument-2 (to place the initramfs)
target block device (/dev/vdb) as argument-3 (Not sure if argument-3 is really necessary, maybe to get disk identifiers such as mbr-identifier, disk-guid, part-guid and fs-guid ?)
target block device partition format (also maybe not required, maybe to distinguish between MBR, GPT-only, GPT with protective MBR)
./vtoyboot.sh / /boot /dev/vdb
Script should not assume that image-device as seen during qemu-boot (/dev/sdb) is same image-device as seen during nativeboot (/dev/mapper/ventoy)
Current Situation
vtoyboot only supports the case when boot disk is the vtoy image. This is understandable, and in most cases it may actually be that way.
However, owing to https://gitlab.com/qemu-project/qemu/-/issues/934 , I can't boot the efisys partition under hyperV/qemu.
So, I am forced to create a non-EFI boot disk with boot partition /dev/vda1 whose grub2 chainloads to the boot partition /dev/vdb2
However on upgrading kernel, I can't run vtoyoot.sh from inside the qemu-vm.
Providing the rootfs partition is sort of optional and maybe helpful in case disk image is not the bootup vdisk in the VM.
Also, what if I had other virtual-disks attached and mounted in the VM. They will also confuse vtoyboot.sh.
Desired outcome
In situations like this, which could be common, it would be convenient to run vtoyboot.sh from inside the qemu emulator, instead of making user to remember to run vtoyboot.sh later when native-booting.
workaround
workaround-1: Just reboot and do native-boot into the vdisk, selecting older kernel and run vtoyboot.sh again that way
workaround-2 (maybe?): try non-efi/non-pflash booting mechanism in qemu.
workaround-3 I could have tried to make EFIboot/nonefi-classic-grub2-boot work on the same drive. Possibly, when I had done this, though my laptop is set to uefi boot, and ventoy might have attempted to chainload the non-uefi-classic-grub2-boot which uses the protective-MBR ... or maybe i did not want to mess with ventoy's boot after I got it working, ... I can't remember. There probably is another bug here, that ventoy chainloads the nonefi-classic grub2 instead of the efi-grub2, when both grub2-s are present and when machine is efi enabled and booting up with efi.
log
vda: MBR; partitions: 128Mb ext4 with nonefi-classic-grub2
vdb: GPT; partitions: fat32, biosboot(not used), ext4 with efi-grub2, btrfs
[root@fedora vtoyboot-1.0.24]# sfdisk /dev/vda -l
Disk /dev/vda: 128 MiB, 134217728 bytes, 262144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xXXXX
:
Device Boot Start End Sectors Size Id Type
/dev/vda1 2048 262143 260096 127M 83 Linux
[root@fedora vtoyboot-1.0.24]# sgdisk /dev/vdb -p
Disk /dev/vdb: 97386496 sectors, 46.4 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): XXXX
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 97386462
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
:
Number Start (sector) End (sector) Size Code Name
1 2048 522239 254.0 MiB EF00 EFI System Partition
2 522240 526335 2.0 MiB EF02 BIOS boot partition
3 526336 2099199 768.0 MiB 8300 Linux filesystem
4 2099200 97384447 45.4 GiB 8300
[root@fedora vtoyboot-1.0.24]# cat /mnt/a/grub2/grub.cfg
echo "executing grub2.cfg on dosmbr boot partition"
sleep 3
insmod part_gpt
search --no-floppy --fs-uuid --set=dev XXXXUUIDXXXX
#set prefix=($dev)/grub2
#export $prefix
#configfile $prefix/grub.cfg
set root=($dev)
configfile ($dev)/grub2/grub.cfg
[root@fedora vtoyboot-1.0.24]# sh ./vtoyboot.sh
**********************************************
vtoyboot 1.0.24
longpanda admin@ventoy.net
https://www.ventoy.net
**********************************************
More than one disks found. Currently only one disk is supported.
Minor feature enhancement
Presently vtoyboot.sh assumes that native boot disk is the first disk, which could be /dev/sda or/dev/mapper/ventoy and assumes that boot and root partitions are on it. It bails out if there is more than 1 /dev/[vsh]d? device. vtoyboot just calls dracut on rootfs to create the initramfs with the vtoy-tools and puts it in /boot
Let vtoyboot.sh take
./vtoyboot.sh / /boot /dev/vdbScript should not assume that image-device as seen during qemu-boot (/dev/sdb) is same image-device as seen during nativeboot (/dev/mapper/ventoy)Current Situation
vtoyboot only supports the case when boot disk is the vtoy image. This is understandable, and in most cases it may actually be that way. However, owing to https://gitlab.com/qemu-project/qemu/-/issues/934 , I can't boot the efisys partition under hyperV/qemu. So, I am forced to create a non-EFI boot disk with boot partition /dev/vda1 whose grub2 chainloads to the boot partition /dev/vdb2
However on upgrading kernel, I can't run vtoyoot.sh from inside the qemu-vm. Providing the rootfs partition is sort of optional and maybe helpful in case disk image is not the bootup vdisk in the VM. Also, what if I had other virtual-disks attached and mounted in the VM. They will also confuse vtoyboot.sh.
Desired outcome
In situations like this, which could be common, it would be convenient to run vtoyboot.sh from inside the qemu emulator, instead of making user to remember to run vtoyboot.sh later when native-booting.
workaround
log
vda: MBR; partitions: 128Mb ext4 with nonefi-classic-grub2 vdb: GPT; partitions: fat32, biosboot(not used), ext4 with efi-grub2, btrfs