[issue]: Ventoy used with -s -and -g creates non bootable disk.

[EricV]

Official FAQ

• I have checked the official FAQ.

Ventoy Version

1.0.96

What about latest release

Yes. I have tried the latest release, but the bug still exist.

Try alternative boot mode

I do not want to disable secure boot and in any case I will not be allowed to on professional laptop.

BIOS Mode

UEFI Mode

Partition Style

GPT

Disk Capacity

1TB

Disk Manufacturer

samsung T5 SSD

Image file checksum (if applicable)

None

Image file download link (if applicable)

No response

What happened?

First the EFI boot partition type is bizzare (FAT16 should be FAT32 on most PC) and the partition flags are wrong also (should be boot,esp and not hidden, no_automount and I dunno what else). The fact is that the BIOS when F11 does not propose to boot on the newly created ventoy image on the T5.

[EricV]

Should I add that creating disk image with rufus or dd for debian image works on the same laptop in secure UEFI mode and can be booted using the F11 boot device selection option used by the BIOS. Here the disk is not even proposed and this is not surprising given the partition type and flags. Sfdisk on the created image does not list the fat16 partition as EFI boot poartition.

[EricV]

I have copied the FAT16 content, and recreated a FAT32 partition with the same content and correct flags. I still does not boot. So either, the UEFI BIOS is not able to access partition that are after a certain number of blocs (SSD disk not usb stick), or the content is incorrectly signed. Will try to move the EFI partition ate the beginning of the disk to see it it help.

[steve6375]

'It does no boot' is not a very good description of the problem! It is like saying 'my car does not work'. Totally useless description.
Millions of people all over the world use Ventoy - so your problem is most likely to be due to your equipment.
i.e. Your USB drive and target PC.
Since we have no details on what these are, your problem report is pretty useless!

[EricV]

I wonder if you even did read the first comment after the bug itself but anyway.

It creates a non bootable disk because the UEFI BIOS does not recognize the disk as a bootable disk. Many user use ventoy, is fair. How many use the Linux version to create the image and specify -s and -g?

As long as the UEFI BIOS does not propose me to boot the ventoy created disk, what else can I say?

The PC is fine. It does boot from USB with EFI signed code created with other tools (rufus, debian iso on usb, ...). The disk is fine. I Can access it from Linux with gparted and boot it with other system installed.

[steve6375]

Ventoy places the FAT16 partition at the end of the disk. The most common problem that people have is that they use a fake cheap USB drive which does not actually contain the stated size of flash memory chips and often these chips are faulty too.
Because the UEFI files are placed at the end of the disk, if there is no memory there or the memory is faulty, the USB drive may not be UEFI-bootable.
So we still do not know exactly what your PC is (PC make model year BIOS version, BIOS settings, etc.) and we still do not know exactly what your USB drive is (make, model, stated capacity, cost, where purchased) or if you have verified that it has the full storage capacity expected and has no errors (e.g. by testing with validrive or H2TESTW or fakeflashtest under Windows or F3 under linux).

The other problem is that some BIOSes, when in Secure Boot mode, do not list partitions which contain unsigned EFI boot files (e.g. /EFI/BOOT/BOOTX64.EFI which is insecure and is not signed). Because Ventoy needs to manipulate ISOs, etc. in order to multiboot different source files, it cannot be signed. So you may need to disable Secure Boot in your BIOS configuration settings. Since you have given no details about Secure Boot (or any other BIOS details), it is difficult to know how to help.

https://ventoy.net/en/doc_secure.html

[EricV]

The disk is a samsung T5 SSD. Brand new and working. I want to replace all my usb bootable keys with a multi iso solution (I have maybe 10+ for various partitionning recovery usage).
The laptop is an MSI bravo 17 A4DDR
BIOS version is the last one available on manufacturer site : AMERiCAN Megatrend INK: E17FKAMS.117

Could you elaborate on "BOOTX64.EFI which is insecure and is not signed". I do not understand. This would mean that you sometime modify /EFI/BOOT/BOOTX64.EFI on the fly or that you modified some code and did not had it sign by microsoft?

What will happen If I use my internal disk bootx64.efi and replace /EFI/BOOT/BOOTX64.EFI

And I'm glad the secure boot refuse to boot anything non signed! I do not want to disable secure boot even for trying (and on some other professional laptops I will not be allowed to do it anyway)

The doc you pointed is when you manage to boot up to shim layer. And I'm familiar with that as I need to add keys to sign Linux dkms modules with my own keys.

[steve6375]

ALL UEFI x86 64-bit firmware boots from the \EFI\BOOT\BOOTX64.EFI file.
That is how UEFI booting works.
The EFI file has to be on a FAT partition (FAT12/16/32). Some BIOSes also have other filesystem drivers too - e.g. an Asus UEFI BIOS can often boot the BOOTX64.EFI file from an NTFS partition as well.
If you have enabled Secure Boot, then the BIOS will only boot EFI files which have been signed.
Some BIOSes may check this file to see if it is signed and will not list the partition as a boot option. Some BIOSes allow the user to disable booting from external USB drives.
Ventoy has 'Secure Boot' support but this means that it relies on the BIOS first booting from its unsigned EFI boot file and then getting an error and it runs MOKManager automatically (the -s option adds the EFI file and MOKManager files into the FAT partition).
MOKManager must be manually used by the user to add a hash key which will whitelist the unsigned Ventoy BOOTX64.EFI file and so allow the BIOS to treat the unsigned Ventoy BOOTX64.EFI file as being 'OK' to boot, despite the fact that it is unsigned and insecure.
So the whole process of booting in Secure Boot mode to Ventoy relies on the UEFI firmware first booting to the insecure Ventoy BOOTX64.EFI file and then running MOKManager.
Once the hash key has been enrolled and added to the BIOS UEFI 'whitelist' then the UEFI BIOS on that target system will boot to Ventoy without any error until a user deletes the hash key from the BIOS whitelist.
The MOKManager process is clearly shown on the Ventoy web page. See the animate GIF at https://ventoy.net/en/doc_secure.html

P.S. The Ventoy BOOTX64.EFI contains the Ventoy boot code. It cannot be substituted with a different version,

[EricV]

So you do not support secure boot this is a misleading false advertisement. I just wasted my time. But at least this is clear now. I will open another bug for it.

[steve6375]

OK. Can you close this issue please as you clearly did not understand the product despite it being documented.

[EricV]

Documented where? Could you give me a ponter saying it assumes the secure boot UEFI BIOS is broken? You write in your advertisement that UEFI secure boot mode IS supported. Ventoy dev teams does not seems to understand the concept of secure boot and trusted chain. As long as a single element in the boot chain is not signed, the rest cannot be considered secure anymore. The shim key enrolment is just a joke as in your case the first boot element is not signed. Signing the rest afterwards is void. The bug report is valid I do not see why I should close it.

[steve6375]

I am not the developer. Just trying to help you as no one else seemed to help with your issue, probably due to your lack of clear explanation of the issue.
If you know of a multiboot solution in the whole world that will directly boot multiple iso files from an unmodified secure uefi bios, please tell us.

[EricV]

I'm desperately seeking for it and due to somehow false advertising I hoped to have found one.

[steve6375]

I am the developer of Easy2boot which does have a method of booting multiple secure bootable images, but it requires you to switch in a .imgptn file using a legacy or non secure system or a windows utility first, before you can secure boot to the selected image.
Or you can add a 3rd winpe partition to the e2b usb drive, secure boot to winpe, and use the windows utility to switch in the desired uefi image and reboot.
It's a lot more awkward than Ventoy but at least it allows you to secure boot to a variety of payloads.

[steve6375]

Of course, you could always purchase an iodd drive. Then you will have no secure boot issues 😉

[EricV]

If I write code in the iodd drive that is not signed and contains malware, it does not protect me.

[steve6375]

The iodd drive is a virtual drive emulator, so you select the iso and then the uefi bios just sees a cd/dvd boot drive
So if the iso contains a signed efi boot file it will secure boot, if the iso contains an unsigned boot file, the uefi bios will refuse to boot it, if secure boot is enabled in the BIOS.
Perhaps you are not familiar with these devices?

[steve6375]

P.s. when I say that the Ventoy efi file is not signed, I mean not signed with a Microsoft certificate and so not accepted as secure.

[EricV]

Perhaps you are not familiar with these devices?

Great. Indeed I looked as some thing that was different. I've seen one but it can contain only four iso. Will continue looking to see if I find something suitable (I have maybe 12 isos...).

[EricV]

P.s. when I say that the Ventoy efi file is not signed, I mean not signed with a Microsoft certificate and so not accepted as secure.

That rings a bell. If it is signed it means, you expect the signature to be verified by another component. So now I'm not sure about the ventoy secure boot trust chain. Per se, it is not problematic to have part of the bootchain signed and verified using non Microsoft keys. Typically grub fails into that category on Linux distrib with shim build with a distribution key build-in. But some elements have to be signed with Microsoft key : the one used by UEFI BIOS.

Is there somewhere a document that describes the ventoy bootflow from the BIOS and the keys used by each stage?

[steve6375]

Perhaps you are not familiar with these devices?

Great. Indeed I looked as some thing that was different. I've seen one but it can contain only four iso. Will continue looking to see if I find something suitable (I have maybe 12 isos...).

No - you can have THOUSANDS of ISOs on an IODD and you can mount up to FOUR at any one time - i.e. the BIOS can see 4 different USB DVD virtual drives at the same time. You can have four VHDs mounted, so the BIOS can see four different USB drives at any one time.

i.e. The IODD devices are what every multibooter needs and they can secure boot with no issues (as long as the ISO is signed
if you want secure booting and designed to be booted as a DVD or USB disk drive).

[EricV]

OK. thanks a lot. I will look at such a device because it would fulfill my need.

[EricV]

Since I have mokutil on my Linux and Linux shim can register my own created key (use that for DKMS modules), may I try to enroll the key in ventoy EFI using user space Linux mokutil? Will UEFI BIOS accept it as a valid key and allow to launch BOOTX64.EFI ?

[steve6375]

Why not try it? I Googled and found this...
https://docs.oracle.com/cd/F22978_01/tutorial-mokutils-uefi/#before

Import certificate into the MOK list
Use the mokutil command to request that the certificate that you have extracted from the source package is included in the MOK list:

Copy

mokutil --import ./secureboot.cer

The command prompts you to enter and confirm a password for the MOK enrollment request. You can use any password for this purpose, but you should note the password that you use, as you are prompted for it again when the system reboots.

Do not import the CA certificate, securebootca.cer, that is included in the source packages. Importing the CA certificate allows any kernel that uses a certificate signed by the same CA to load and renders UEFI Secure Boot ineffective.

Reboot the system and complete enrollment
Reboot the system.

The pending MOK key enrollment request is detected, and you must complete the enrollment from the UEFI console. You are prompted for the password that you set when you imported the certificate. When you have entered the correct password, the certificate is added to the MOK list and is automatically propagated to the system key ring on this boot, as well as subsequent boots.

[EricV]

openssl x509 -in /mnt/ENROLL_THIS_KEY_IN_MOKMANAGER.cer -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b2:94:8e:b3:ca:bc:48:27:a0:a5:67:a2:b9:59:d4:63
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=grub
Validity
Not Before: Feb 24 22:38:00 2019 GMT
Not After : Feb 21 22:38:00 2029 GMT
Subject: CN=grub
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a0:49:c2:cc:f7:74:33:1a:4c:6d:99:6d:3e:90:
40:ee:b8:35:4e:1b:94:a5:2e:62:74:e2:33:1c:6b:
7d:7c:67:bb:5e:66:e0:28:19:dc:92:7d:9e:c1:c5:
0e:f8:92:9f:b1:ee:bd:69:f1:34:55:92:13:81:b1:
c3:d3:ad:40:c2:b2:b0:3d:04:8e:2a:f8:0b:40:13:
b6:f0:48:87:55:65:6b:d4:c4:10:6b:03:dc:de:74:
65:cc:c9:6c:9f:29:df:c3:f9:b3:2e:64:6b:dc:00:
99:fd:09:5d:03:0c:63:13:b4:7c:89:25:9f:ae:f1:
34:79:6a:a4:cc:a0:fa:11:52:25:17:11:01:c3:03:
69:77:6e:4d:9c:b8:f0:3d:2f:b7:ec:0b:f0:f5:96:
b4:4a:a6:ed:79:35:b9:e9:23:ec:75:ae:33:b5:b4:
73:db:c4:6b:34:93:65:cf:92:37:87:44:30:90:38:
8f:e0:ae:af:47:25:ae:8e:e2:1e:d9:16:3d:11:dc:
33:94:c9:4e:8e:9a:f0:25:62:7c:c6:c6:c4:c8:32:
5d:e1:b2:5b:cf:9a:08:dc:34:da:5e:d3:4a:21:1e:
8b:97:93:fb:ba:85:95:bc:f4:a2:af:89:b3:b0:ea:
1d:c3:30:c1:81:bf:c9:e6:e6:f4:9a:da:9b:aa:e6:
af:c5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
D9:39:39:5C:DA:05:9C:19:A6:99:C8:5F:38:56:D0:23:BE:25:90:07
Netscape Cert Type: critical
SSL Client, SSL Server, S/MIME, Object Signing, SSL CA, S/MIME CA, Object Signing CA
X509v3 Extended Key Usage:
Code Signing
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
D9:39:39:5C:DA:05:9C:19:A6:99:C8:5F:38:56:D0:23:BE:25:90:07
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
36:db:96:f2:3c:8d:67:cd:f9:62:04:c9:37:22:a0:29:00:9b:
2f:95:8e:9c:a4:0b:c0:d5:be:04:76:f5:d8:2c:08:94:3c:c8:
89:c6:34:38:fc:30:b2:03:46:da:da:38:1b:ed:fa:49:c8:af:
88:b2:b5:c7:4f:d5:c1:d2:99:5c:4b:e9:7e:a7:4d:c6:08:83:
e5:21:1e:3d:bd:88:35:2f:2c:35:d5:42:17:ee:18:f8:27:80:
31:1a:c3:99:93:78:37:e0:32:35:6f:ac:1d:33:97:27:f4:3c:
76:3e:dc:f6:aa:75:b0:c8:2f:a0:0b:cb:99:c0:b9:2b:77:79:
be:d4:bb:0f:94:f7:d8:c4:2e:93:45:6c:41:fd:87:f1:09:06:
e0:31:8a:2b:00:36:28:ef:1a:ce:1f:72:d4:70:d0:00:e7:0a:
aa:7d:d0:0a:d5:57:a5:5f:ec:60:ff:30:6f:92:cb:67:59:3d:
93:95:46:60:33:82:f0:7f:14:79:43:b5:34:4c:4a:ed:76:5f:
d4:9c:a0:6a:2e:86:6b:9b:26:67:13:22:c1:50:32:a6:4a:45:
dc:c7:f7:d5:8c:c9:e4:0c:0e:bc:b4:cc:a1:7b:db:b4:a1:41:
69:0b:b9:04:36:b8:5b:fa:fd:24:39:95:8e:29:34:37:d7:ec:
88:80:0b:f8

Then:

mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 53:61:0c:f8:1f:bd:7e:0c:eb:67:91:3c:9e:f3:e7:94:a9:63:3e:cb
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ed:54:a1:d5:af:87:48:94:8d:9f:89:32:ee:9c:7c:34
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Debian Secure Boot CA
Validity
Not Before: Aug 16 18:09:18 2016 GMT
Not After : Aug 9 18:09:18 2046 GMT
Subject: CN=Debian Secure Boot CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9d:95:d4:8b:9b:da:10:ac:2e:ca:82:37:c1:a4:
cb:4a:c3:1b:42:93:c2:7a:29:d3:6e:dd:64:af:80:
af:ea:66:a2:1b:61:9c:83:0c:c5:6b:b9:35:25:ff:
c5:fb:e8:29:43:de:ce:4b:3d:c6:12:4d:b1:ef:26:
43:95:68:cd:04:11:fe:c2:24:9b:de:14:d8:86:51:
e8:38:43:bd:b1:9a:15:e5:08:6b:f8:54:50:8b:b3:
4b:5f:fc:14:e4:35:50:7c:0b:b1:e2:03:84:a8:36:
48:e4:80:e8:ea:9f:fa:bf:c5:18:7b:5e:ce:1c:be:
2c:80:78:49:35:15:c0:21:cf:ef:66:d5:8a:96:08:
2b:66:2f:48:17:b1:e7:ec:82:8f:07:e6:ca:e0:5f:
71:24:39:50:0a:8e:d1:72:28:50:a5:9d:21:f4:e3:
61:ba:09:03:66:c8:df:4e:26:36:0b:15:0f:63:1f:
2b:af:ab:c4:28:a2:56:64:85:8d:a6:55:41:ae:3c:
88:95:dd:d0:6d:d9:29:db:d8:c4:68:b5:fc:f4:57:
89:6b:14:db:e0:ef:ee:40:0d:62:1f:ea:58:d4:a3:
d8:ba:03:a6:97:2e:c5:6b:13:a4:91:77:a6:b5:ad:
23:a7:eb:0a:49:14:46:7c:76:e9:9e:32:b4:89:af:
57:79
Exponent: 65537 (0x10001)
X509v3 extensions:
Authority Information Access:
CA Issuers - URI:https://dsa.debian.org/secure-boot-ca
X509v3 Authority Key Identifier:
6C:CE:CE:7E:4C:6C:0D:1F:61:49:F3:DD:27:DF:CC:5C:BB:41:9E:A1
Netscape Cert Type: critical
SSL Client, SSL Server, S/MIME, Object Signing, SSL CA, S/MIME CA, Object Signing CA
X509v3 Extended Key Usage:
Code Signing
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
6C:CE:CE:7E:4C:6C:0D:1F:61:49:F3:DD:27:DF:CC:5C:BB:41:9E:A1
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
77:96:3e:47:c9:ce:09:cf:8b:89:ce:59:ed:26:0e:26:0b:b9:
ad:a9:2b:bd:a1:eb:88:79:02:ff:31:de:fe:f5:6a:07:ef:61:
13:11:70:1e:bf:9c:4e:66:6c:e1:62:12:97:01:57:65:47:dd:
4a:c6:f7:f4:de:a8:f1:13:62:cc:83:57:ac:3c:a6:91:15:af:
55:26:72:69:2e:14:cd:dd:4d:b3:d1:60:24:2d:32:4f:19:6c:
11:5e:f2:a3:f2:a1:5f:62:0f:30:ae:ad:f1:48:66:64:7d:36:
44:0d:06:34:3d:2e:af:8e:9d:c3:ad:c2:91:d8:37:e0:ee:7a:
5f:82:3b:67:8e:00:8a:c4:a4:df:35:16:c2:72:2b:4c:51:d7:
93:93:9e:ba:08:0d:59:97:f2:e2:29:a0:44:4d:ea:ee:f8:3e:
02:60:ca:15:cf:4e:9a:25:91:84:3f:b7:5a:c7:ee:bc:6b:80:
a3:d9:fd:b2:6d:7a:1e:63:14:eb:ef:f1:b0:40:25:d5:e8:0e:
81:eb:6b:f7:cb:ff:e5:21:00:22:2c:2e:9a:35:60:12:4b:5b:
5f:38:46:84:0c:06:9c:cf:72:93:62:18:ee:5c:98:d6:b3:7d:
06:25:39:95:df:4e:60:76:b0:06:7b:08:b0:6e:e3:64:9f:21:
56:ad:39:0f

[key 2]

!!my personal key. Deleted!!

[key 3]
SHA1 Fingerprint: 54:f4:18:74:f4:d8:84:28:09:bc:be:88:10:65:92:0a:17:56:5d:25
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b2:94:8e:b3:ca:bc:48:27:a0:a5:67:a2:b9:59:d4:63
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=grub
Validity
Not Before: Feb 24 22:38:00 2019 GMT
Not After : Feb 21 22:38:00 2029 GMT
Subject: CN=grub
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a0:49:c2:cc:f7:74:33:1a:4c:6d:99:6d:3e:90:
40:ee:b8:35:4e:1b:94:a5:2e:62:74:e2:33:1c:6b:
7d:7c:67:bb:5e:66:e0:28:19:dc:92:7d:9e:c1:c5:
0e:f8:92:9f:b1:ee:bd:69:f1:34:55:92:13:81:b1:
c3:d3:ad:40:c2:b2:b0:3d:04:8e:2a:f8:0b:40:13:
b6:f0:48:87:55:65:6b:d4:c4:10:6b:03:dc:de:74:
65:cc:c9:6c:9f:29:df:c3:f9:b3:2e:64:6b:dc:00:
99:fd:09:5d:03:0c:63:13:b4:7c:89:25:9f:ae:f1:
34:79:6a:a4:cc:a0:fa:11:52:25:17:11:01:c3:03:
69:77:6e:4d:9c:b8:f0:3d:2f:b7:ec:0b:f0:f5:96:
b4:4a:a6:ed:79:35:b9:e9:23:ec:75:ae:33:b5:b4:
73:db:c4:6b:34:93:65:cf:92:37:87:44:30:90:38:
8f:e0:ae:af:47:25:ae:8e:e2:1e:d9:16:3d:11:dc:
33:94:c9:4e:8e:9a:f0:25:62:7c:c6:c6:c4:c8:32:
5d:e1:b2:5b:cf:9a:08:dc:34:da:5e:d3:4a:21:1e:
8b:97:93:fb:ba:85:95:bc:f4:a2:af:89:b3:b0:ea:
1d:c3:30:c1:81:bf:c9:e6:e6:f4:9a:da:9b:aa:e6:
af:c5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
D9:39:39:5C:DA:05:9C:19:A6:99:C8:5F:38:56:D0:23:BE:25:90:07
Netscape Cert Type: critical
SSL Client, SSL Server, S/MIME, Object Signing, SSL CA, S/MIME CA, Object Signing CA
X509v3 Extended Key Usage:
Code Signing
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
D9:39:39:5C:DA:05:9C:19:A6:99:C8:5F:38:56:D0:23:BE:25:90:07
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
36:db:96:f2:3c:8d:67:cd:f9:62:04:c9:37:22:a0:29:00:9b:
2f:95:8e:9c:a4:0b:c0:d5:be:04:76:f5:d8:2c:08:94:3c:c8:
89:c6:34:38:fc:30:b2:03:46:da:da:38:1b:ed:fa:49:c8:af:
88:b2:b5:c7:4f:d5:c1:d2:99:5c:4b:e9:7e:a7:4d:c6:08:83:
e5:21:1e:3d:bd:88:35:2f:2c:35:d5:42:17:ee:18:f8:27:80:
31:1a:c3:99:93:78:37:e0:32:35:6f:ac:1d:33:97:27:f4:3c:
76:3e:dc:f6:aa:75:b0:c8:2f:a0:0b:cb:99:c0:b9:2b:77:79:
be:d4:bb:0f:94:f7:d8:c4:2e:93:45:6c:41:fd:87:f1:09:06:
e0:31:8a:2b:00:36:28:ef:1a:ce:1f:72:d4:70:d0:00:e7:0a:
aa:7d:d0:0a:d5:57:a5:5f:ec:60:ff:30:6f:92:cb:67:59:3d:
93:95:46:60:33:82:f0:7f:14:79:43:b5:34:4c:4a:ed:76:5f:
d4:9c:a0:6a:2e:86:6b:9b:26:67:13:22:c1:50:32:a6:4a:45:
dc:c7:f7:d5:8c:c9:e4:0c:0e:bc:b4:cc:a1:7b:db:b4:a1:41:
69:0b:b9:04:36:b8:5b:fa:fd:24:39:95:8e:29:34:37:d7:ec:
88:80:0b:f8

So key 3 is indeed identical to the one in the root of ventoy efi partition.

However, when I use sbverify to check how the bianry is signed I hardly see it is the same signature:

sbverify --list /mnt/EFI/BOOT/BOOTX64.EFI

warning: data remaining[808656 vs 934024]: gaps between PE/COFF sections?
signature 1
image signature issuers:

• /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
  image signature certificates:
• subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
  issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
• subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
  issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
  signature 2
  image signature issuers:
• /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
  image signature certificates:
• subject: /CN=openSUSE Secure Boot Signkey/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
  issuer: /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org
  root@pink-floyd3:~#

[EricV]

So I signed the EFI/BOOT/BOOTX64.EFI with my own key (or more precisely added my own key to the signature and still it does not work. Shim add the key in the MOK (Machine Owner Key) database that is probably not the one used by UEFI bios called db. I have no clue on how to add a key on db except recreating the whole trust chain PK see https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11 . The BIOS do not allow key management. Some do.