When I used the automated deployment script from iventoy for installation, I encountered two issues. One was that several versions of CentOS 7 could not detect /dev/sr0, preventing me from proceeding with the installation process, as shown in Figures 1 and 2. The other issue was that several versions of CentOS 8 prompted me with a network unreachable error, preventing me from proceeding with the installation process. However, after entering emergency mode, I was able to ping normally, as shown in Figure 3;
By the way, I tried to use the kickstart7.cfg file in the example/ directory for CentOS 7.0 installation, but it also failed to install properly.
When I don't use the ks script for installation, it loads normally. Could it be that there's a problem with the ks script I wrote? Or is there some other reason? Could you please help me out.
When I try to change Secure Boot string to Bypass Secure Boot (means 0) Plugson just removes whole string and if you select follow UEFI Secure boot check then it will return but with option 1 and also with Secure boot disabled I cannot boot entirely. Also VTOY_WIN_UEFI_RES_LOCK resets when entering Plugson. Why developer not testing it before release??
Fix the boot issue when Secure Boot is disabled in the UEFI firmware. (#3650) Attention: Ventoy use a new UEFI secure boot CA since v1.1.14, so you need to enroll the new key for the first boot time. Please refer Notes
I have now inventoy 1.0.34 running only it does not work anymore (also the 1.0.26 does not work).
I think this is because the IP address given by the third party (the router) is a.b.c.20 for example while iVentoy only respond to ip address a.b.c.201 till a.b.c.221.
(I saw in WireShark the IP address given to the PXE Interface).
The DHCP server is in the same subnet (a.b.c.1/24) , On this DHCP server I configured option 66 and 67 (bootfile and next server).
I see that the PXE interface gets it's IP address but not within the configured range, even if I bind the PXE mac address to an IP address within the range it still doesn't work.
Looks like the iVentoy server does not respond at all? In the firewall I permit all traffic to and from the program 'iVentoy_64.exe'
The iVentoy is running on a Windows Server 2016.
Hello, I have been trying to find an easier alternative to implement the multi boot ISOs. I believe we can use UAPI.1 (The Bootloader Specification) to our advantage if we add two new keys to the conf file. I have also made the proposal to add those keys in the official github discussion thread for UAPI. I have written a detailed blog on how this will solve the need for hardcoded configs for each distribution. I will highly appreciate if the Ventoy dev takes a look at it and provides feedback on what I am trying to achieve. The blog is: https://splayer.4plt.ch/blogs/2-the-vent...index.html
I am also looking for feedback on the correctness of the facts I have presented in the blog.
If this is not the correct place to post this then I sincerely apologize and request to guide me to a proper channel.
Thank You.
First of all, big thanks to Longpanda, I know many people said it too many times, but I really wanted to thank to Longpande for keep developing this tool. It has been a great contribution to the whole IT world.
I work for a company that specializes in supporting supermarkets, we are developing HW and SW to enable stores, restaurants, petrol stations and many others. Some of our specific HW (and some 3rd party HW) struggles to boot in UEFI. Those machines ignore the UEFI standard and have troubles to boot from anything else in some circumstances (large drives) other than Microsoft's bootloader (/EFI/Microsoft/Boot/bootmgfw.efi).
I have created diagnostics tool for our engineers based on Ventoy using various ISO utilities, BIOS updates, the usual open source tools available and some specific to our machines. To make sure it boots on all UEFI machines, I had to modify the ventoy.disk.img.xz, unpack it, mount it and do the below:
From /EFI/BOOT/ copy BOOTX64.EFI, MokManager.efi, grub.efi and grubx64_real.efi into newly created folder: /EFI/Microsoft/Boot/
In /EFI/Microsoft/Boot/ rename BOOTX64.EFI to bootmgfw.efi
repack the ventoy.disk.img with xz
Once I install the ventoy, it works great. I could only copy the X64 EFI binaries as there is not enough space on the 32MB EFI FAT partition, which is fine as this only affectes our X64 machines (we don't use any other architecture).
My humble question would be if perhaps other people approach you to do something similar as some other BIOSes may ignore the UEFI specs and just look for Microsoft bootloader as the only option. If that's the case, would you consider adding these files so all UEFI firmware would work?
Attached screenshot shows the original /EFI/BOOT/ files on the left and the newly added (copied) /EFI/Microsoft/Boot/ files on the right.
