hgkamath
commented
1 year ago TLDR: This comment is about secureboot investigation. I don't think secureboot is the issue
The thing is the EFI parition on the main SSD, is different from the EFI partition inside the vtoy-image
[root@fedora tmp]# blkid | grep 2c1fa
/dev/sda1: UUID="4AC2-A5E2" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="2c1fa0a2-9abe-4b33-88df-46df556287ec"
[root@fedora tmp]# efibootmgr | grep Fedora
Boot0001* Fedora HD(1,GPT,585525aa-723b-4695-954a-cf6db7ab7262,0x800,0x7f000)/File(\EFI\Fedora\shimx64.efi)
Boot0003* Fedora HD(1,GPT,2c1fa0a2-9abe-4b33-88df-46df556287ec,0x800,0x82000)/File(\EFI\fedora\shim.efi) File(.䍒)I will try do this inside a qemu-VM on win10, so that it presents only 1 attached disk, to eliminate this confusion.
Below is running vtoyboot.sh -s inside single vdisk qemu-VM on win10
root@fedora vtoyboot-1.0.25]# ./vtoyboot.sh -s
**********************************************
vtoyboot 1.0.25
longpanda admin@ventoy.net
https://www.ventoy.net
**********************************************
Current system use dracut as initramfs tool
updating the initramfs, please wait ...
updating initramfs for 6.1.8-200.fc37.x86_64 please wait ...
grub mkconfig ...
PROBE_PATH=/usr/sbin/grub2-probe EDITENV_PATH=/usr/bin/grub2-editenv MKCONFIG_PATH=/usr/sbin/grub2-mkconfig
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
/etc/grub2.cfg --> /boot/grub2/grub.cfg
biosgrub partition exist
GPT check /dev/vda failed, code=5
recover shim efi ...
no backup file found, no need.
vtoyboot process successfully finished.unsure how this matters uefi changes inside qemu-VM are not persistent. I think the vtyoboot.sh in qemu-VM is bailing out without properly installing signed kernel-object, because it assumes regualar non-efi grub2 just because it found a biosgrub partition.
No change on reboot to ventoy
[root@fedora vtoyboot-1.0.25]# cat /etc/os-release | grep ^VERSION=
VERSION="37 (Workstation Edition)"
[root@fedora gana]# dmesg | grep dm_patch
[ 6.156108] dm_patch: module verification failed: signature and/or required key missing - tainting kernel
[root@fedora vtoyboot-1.0.25]# journalctl -k | grep taint
Feb 12 19:23:26 fedora kernel: dm_patch: module verification failed: signature and/or required key missing - tainting kernel
[root@fedora vtoyboot-1.0.25]# grep dm_patch /proc/modules
[root@fedora vtoyboot-1.0.25]#
[root@fedora gana]# mount -t ntfs3 /dev/sdc1 /mnt/c1
mount: /mnt/c1: /dev/sdc1 already mounted or mount point busy.
dmesg(1) may have more information after failed mount system call.It seems to me this dm_module needs to be signed and accepted by UEFI.
I have my own MOK, (gana), is there a way I can get dm_patch*.ko files to be signed by my own signing MOK private key?
[root@fedora tools]# pwd
/root/tmp/vtoyboot-1.0.25/tools
[root@fedora vtoyboot-1.0.25]# find . | grep dm_patch
./tools/dm_patch_64.ko
./tools/dm_patch_32.ko
[root@fedora tools]# modinfo ./dm_patch_64.ko
filename: /root/tmp/vtoyboot-1.0.25/tools/./dm_patch_64.ko
license: GPL
author: longpanda <admin@ventoy.net>
description: dmpatch driver
depends:
retpoline: Y
intree: Y
name: dm_patch
vermagic: 5.13.19-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SMP mod_unload modversions
[root@fedora tools]# ./vtoydump64 -lv
=== ventoy runtime data ===
disk name : /dev/sdc
disk size : 2000398934016
disk part : 1
filesystem: ntfs
image size: 49861885952
image path: /transcend/m02_lnx.raw.img.vtoy
=== ventoy image location ===
0 97386496 linear /dev/sdc1 1973076888
[root@fedora tools]# ./vtoycheck64 /dev/mapper/ventoy
biosgrub partition existboot sequences
There are about 4 ways, I intend this image to be booted
details of boot sequence during QEMU-VM-UEFI boot
- qemu UEFI
by default looks for EFI SYS partition inside image
/dev/vda1 - grub-EFI shim has a grub config-file with a config-command that continues by loading grub config and bootloader spec on
/dev/vda2.[root@fedora vtoyboot-1.0.25]# cat /boot/efi/EFI/Fedora/grub.cfg search --no-floppy --fs-uuid --set=dev 4394595a-336c-4b9d-a5e7-5c6e1c676b0b set prefix=($dev)/grub2
export $prefix configfile $prefix/grub.cfg
3. grub-EFI shim reads the bootloaders entries, and OS boot inside VM proceeds
#### details of boot sequence during QEMU-VM MBR non-efi regular boot type-1
This I used before I managed to get EFI working in QEMU.
I used a smaller 256MIB disk containing a boot ext4 partition.
QEMU has 2 disks attached the small one is hdd1 and the 40GiB one is hdd2.
While this boot sequence is no longer used, I know it works, and is a failsafe if qemu EFI boot screws up.
1. qemu reads mbr of the small disk, loads stage-1 from mbr, followed by stage-2 from parition-1, which is a ext4 partition with non-efi regular grub2.
2. A single line config command transfers control to the grub2 config files in hdd2 partition-3 (ext4) boot partition and proceeds to load the grub2 config files, bootloader spec, and proceeds to boot OS
#### details of boot sequence during QEMU-VM protective MBR non-efi regular boot type-2
I had this in mind when making this partition, but I do not use this boot method, and do not believe I fully set it up. In theory it is possible.
1. qemu reads the protective mbr, before the gpt, sees the 4MiB partition-2 (type EF02), which contains grub2 x86-64 stage-1, loads the stage-1 core. The stage-1 core-file chains to stage-2 in the partition-3 ext4 boot partition /grub2/x86_64 folder, which then parses the grub configuration
2. grub-2 on partition-3 ext4, parses the grub2 config files , bootloader spec and proceeds to boot OS
#### details of boot sequence during real-UEFI boot
1. HP UEFI
- by default probes on Drive1 SSD (```/dev/sda```) for for EFISYS partition (```/dev/sda1```)
- and then by default load the ```EFI/BOOT``` Microsoft bootloader for Win10
However, by pressing F9, I make it load the ```EFI/Fedora``` grub-EFI shim bootloader
2. grub-EFI shim has a grub config-file with a config-command that continues by loading grub config and bootloader spec on ```/dev/sda7```.[root@fedora vtoyboot-1.0.25]# cat /mnt/a1/EFI/fedora/grub.cfg search --no-floppy --fs-uuid --set=dev 46ea2285-3971-4e8e-9412-7a34fa16de09 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg
3. User selects 15KJ_Ventoy from the menu
- The manual configuration is made in custom.cfg , which makes grub-EFI chain-load to ventoy EFI-loader on 32Mb Ventoy partition ```/dev/sdc2```. The ventoy partition type is changed from EFI_SYS (```EF02```) to ```0700``` because ```/dev/sdc``` has its own EFI_SYS partition . ( ```/dev/sdc3``` is also a EFI partition on Drive3 (HDD2) that has EFI loaders for another Linux and Win11, but that does not play a role here. )[root@fedora vtoyboot-1.0.25]# cat /mnt/a7/grub2/custom.cfg menuentry "15KJ_Ventoy" { insmod part_gpt insmod fat insmod search_fs_uuid insmod chain search --fs-uuid --no-floppy --set=root 3A2F-294B chainloader /EFI/BOOT/BOOTX64.EFI }
4. ventoy grub-EFI then scans ```/dev/sdc1``` and populates its menu
5. user selects ```m02_lnx.raw.img.vtoy```
6. ventoy grub-EFI using loopback emulation loads the kernel and initramfs from partition-3 (boot partition inside image) and starts boot sequence. Job of Linux OS coming up is to treat loopback device as ```hd3``` and pivot onto root filesystem at ```(hd3,gpt3)```
### issue still happens after disabling secureboot
I have disabled secureboot temporarily in the HP UEFIBIOS setup. But ```dm_patch``` failed to patch. Hence, this bug might not be due to secureboot signatures or EFI MOK keys.[root@fedora gana]# grep dm_patch /proc/modules [root@fedora gana]# mount -t ntfs3 /dev/sdc1 /mnt/c1 mount: /mnt/c1: /dev/sdc1 already mounted or mount point busy. dmesg(1) may have more information after failed mount system call. [root@fedora gana]# dmesg | grep dm_p [ 5.781574] dm_patch: module verification failed: signature and/or required key missing - tainting kernel [root@fedora gana]# mokutil --sb-state SecureBoot disabled
### Ref
- [ventoy/DMPATCH/dmpatch.c](https://github.com/ventoy/Ventoy/blob/master/DMPATCH/dmpatch.c)
ventoy
youk
DevReaper0
and copy the 
Description
VTOY_LINUX_REMOUNThas been enabled using global plugson.But,
VTOY_LINUX_REMOUNTis not working.This feature (https://github.com/ventoy/Ventoy/issues/1326, https://github.com/ventoy/Ventoy/issues/2234, ventoy/vtoyboot/#43, also filed by me) used to work for me before. It has been some time since I last booted this way. So there is no reason why this should not work. [EDIT] Reason it is not working is that the dm_patch is out of compatibility sync with the linux kernel 6.1.11
dm-patch is not loading, Hence, cannot mount
/dev/sdc1dmesg shows:
[ 6.220342] dm_patch: module verification failed: signature and/or required key missing - tainting kernel[EDIT] I determined this message isn't only a secureboot signature issue, it throws up even if secureboot is disabled. I think it is thrown because its an external binary kernel module, the kernel decided that such binary blobs are taint. The signature/taint warning is thrown even when the dm_patch module loads and host-partition is mountable, not just when it is rejected.misc
log
I wonder if the module was compiled/built for kernel-5.13.19
Also tried