Ventoy boots to menu but on selecting ShredOS .img file on a legacy only system you end up at the grub prompt. Works on UEFI & .iso
juncture6825 opened this issue · 67 comments
Hello! Every time I attempt to use the 0.34 shredos .iso file on the latest version of Ventoy, I get kernel errors on boot. And every time I try to use the latest shredOS .img file on Ventoy, it drops me into the Grub command line; it doesn't even boot. I have tried Ventoy with Secureboot enabled and disabled, and Ventoy on GPT and MBR. The same error still occurs. The .img file will drop me into the Grub cli, and the .iso will have kernel errors on boot, which causes it to freeze and never boot. I've tried this on multiple different USB sticks, one 64GB and another 128GB one. The same error happens on different USB sticks. I have also tried different computers to boot it on; the same errors appear on all computers. I've also tried older versions of both ventory and shredos. No luck.
ShredOS is advertised on both the Ventoy and ShredOS repo to be compatible with each other. I couldn't find anyone else having the same issue as me.
This is what happens when using the latest ShredOS img file on Ventoy:
This is what happens when using 0.34 ShredOS iso file Ventory:
Can you try booting an alternate Linux live usb or iso and assuming it boots successfully run the command lspci. Take a photo on your phone and post here. .this will display a list of hardware on your system.
Please check my issue also. https://github.com/Master-Koy/-Boot-Error-Stuck-at-Boot-in-Kali-Linux-in-Vmware
This isn't a ShredOS issue... You should ask in a Kali forum. But having said that recovering from a aborted apt upgrade I would use sudo dpkg --configure -a to restart the upgrade. But like I say this place is for ShredOS issues not general Linux issues.
I get exactly the same as juncture6825's pictures when I try to boot v2023.08.2_25.0_x86-64_0.35
Can you try booting an alternate Linux live usb or iso and assuming it boots successfully run the command lspci. Take a photo on your phone and post here. .this will display a list of hardware on your system.
I have attached a screenshot of lspci running Finnix on Ventoy. It's important to note that, ShredOS works fine on a usb drive written with rufus (same computer). And all other operating systems work fine on Ventoy.
@Binary-Bear To diagnose the issue I need you to produce the output of lspci just as @juncture6825 has done above so I can compared the two.
Please check my issue also. https://github.com/Master-Koy/-Boot-Error-Stuck-at-Boot-in-Kali-Linux-in-Vmware
This isn't a ShredOS issue... You should ask in a Kali forum. But having said that recovering from a aborted apt upgrade I would use
sudo dpkg --configure -ato restart the upgrade. But like I say this place is for ShredOS issues not general Linux issues.I understand what you mean to say. Really appreciate you. Can you please tell a few things before I leave.
I'm unable to login so how can I use the command which you mentioned....?
Normally, if you're lucky the Linux virtual terminals would be available ALT F2, ALT F3 etc and you would login via a terminal then run the command but you are running in vmware so whether that works depends on whether the ALT F2 keys are mapped and therefore work. I don't use or know anything about vmware so you are better off asking in the vmware forums. Sorry.
Sorry this is taking me a long time I am trying to find a Linux.iso so I can do lspci.
Just tried tinycore but when I type lspci in terminal it says "command not found"
@Binary-Bear Try system-rescue or gparted
Doing it with gparted
I have got stuck when trying to mount a flash drive to save the output to.
My flash drive is sdc
sudo mount /dev/sdc /store
I get an error.
mount.nilfs2: Error while mounting /dev/sdc on /store: Invalid argument
Before anyone suggests it I don't have a smart phone or a digital camera
Done it! ... I am going for a rest after this LOL.
00:00.0 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: NVIDIA Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2)
00:01.1 SMBus: NVIDIA Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.2 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:01.4 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:06.0 IDE interface: NVIDIA Corporation MCP78S [GeForce 8200] IDE (rev a1)
00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)
00:08.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 IDE interface: NVIDIA Corporation MCP78S [GeForce 8200] SATA Controller (non-AHCI mode) (rev a2)
00:10.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:14.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control
01:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cypress XT [Radeon HD 5870]
02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cypress HDMI Audio [Radeon HD 5830/5850/5870 / 6850/6870 Rebrand]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
I have got stuck when trying to mount a flash drive to save the output >to.
My flash drive is sdcsudo mount /dev/sdc /store
I get an error.
mount.nilfs2: Error while mounting /dev/sdc on /store: Invalid >argument
Just for reference, that command failed because the partition number is missing.
It should've been
sudo mount /dev/sdc1 /store
@Binary-Bear Your system appears to have an Nvidia embedded graphics co processor chipset as well as a AMD graphics system on a card. Can you confirm whether this the case. Is there a plug in graphics card and also a VGA connector that's mounted on the motherboard?
@Binary-Bear Your system appears to have an Nvidia embedded graphics co processor chipset as well as a AMD graphics system on a card. Can you confirm whether this the case. Is there a plug in graphics card and also a VGA connector that's mounted on the motherboard?
Forget the comment above, I just checked the motherboard spec and it doesn't provide a on board video graphics just the Nvidia co processor. You do both run a similar graphics card though AMD Cedar and Cypress. I wonder if there is something wrong with the driver for those graphics.
Just for reference, that command failed because the partition number is missing.
LOL Yes thank you, I learned the hard way!
I hope you can solve the problems we are having, I feel left out not having the latest version of shredos.
@Binary-Bear I'm just double checking a couple of things, I'm not sure whether we discussed this.
- I believe you are connecting your monitor via VGA. Is that correct? Or is it DVI or display port?
- When you edited grub.cfg did you edit both grub files or only one. Do you know whether your system boots legacy & UEFI or just one or the other.
I believe you are connecting your monitor via VGA. Is that correct? Or is it DVI or display port?
I connect to DVI via an adaptor to VGA cable.
This is a picture of the connector (one of the two red sockets)
When you edited grub.cfg did you edit both grub files or only one.
For the purpose of testing I am only using default .iso and .img with no modifications.
Do you know whether your system boots legacy & UEFI or just one or the other.
Legacy BIOS only the main-board is about 12 years old I think.
I thought 0.35 was working if you used Rufus to create the stick, apart from it being slow to load eventually it got there. Is that correct?
Yes 0.35 does work using Rufus albeit slow booting. Sorry, my comment about not having the latest version of shredos is referring to it not being on my boot (Ventoy/Yumi) flash drive.
I thought 0.35 was working if you used Rufus to create the stick, apart from it being slow to load eventually it got there. Is that correct?
0.35 and 0.34 both work completely fine when using Rufus. Neither work on Ventory even though they are advertised to work on Ventory. I don't understand why...?
@Binary-Bear Just to clarify a few more things so I understand it better. You mention Ventoy/Yumi which is basically a yumi front end that pulls in Ventoy. Have you tried using Ventoy 1.0.97 direct from the Ventoy page rather than using yumi. Just wondered if that worked. I use Ventoy Linux download direct from Ventoy
@juncture6825 Similar question, I assume Ventory is a typo. Are you using Ventoy direct from the Ventoy website. And are you using the Linux Ventoy download or the Windows Ventoy download?
@Binary-Bear Just to clarify a few more things so I understand it better. You mention Ventoy/Yumi which is basically a yumi front end that pulls in Ventoy. Have you tried using Ventoy 1.0.97 direct from the Ventoy page rather than using yumi. Just wondered if that worked. I use Ventoy Linux download direct from Ventoy
I normally use Ventoy/Yumi but since the release of ventoy-1.0.97-windows.zip yesterday I have just used Ventoy with the same results.
ventoy-1.0.97-windows.zip SHA256 = 44fb53f26872c6304e1cb3d47b65d0613665666100c48deeee4cd87901fb500f
@Binary-Bear When you copy the shredos .img file onto the Ventoy stick do you copy it into the root directory or do you copy it into a sub folder that you create?
@Binary-Bear When you copy the shredos .img file onto the Ventoy stick do you copy it into the root directory or do you copy it into a sub folder that you create?
Ignore that last question, I just tested Ventoy and ShredOS works even if I put the .img file in a sub folder off root. It still appears in the Ventoy boot menu and it works without any problems, at least on my system
@juncture6825 Similar question, I assume Ventory is a typo. Are you using Ventoy direct from the Ventoy website. And are you using the Linux Ventoy download or the Windows Ventoy download?
Hello! Yes sorry, Ventory was a typo. I mean Ventoy. I installed Ventoy from the official website that you linked, no forks no nothing. I set my Ventoy USB stick up on a Windows 11 22H2 computer, so yes the Windows version of Ventoy.
ShredOS worked in Ventoy for me
ShredOS worked in Ventoy for me
Did you use Ventoy Windows 10, 11 or Linux? What ISO/IMG file of ShredOS? Did you do anything specifically?
Same issue.
Tried some version from 2021 august and it failed, updated to latest shredOS, issue still persists. Im going to do as others said and put it on its own drive but this sucks. Please fix
Please would you provide the output of lspci ?
@p1r473 @Binary-Bear @juncture6825 @NastyFlytrap
- Are these all systems that predate 2011?
- More specifically, are these all systems with a BIOS that does not support UEFI and only provides legacy support?
I have now tried about 10 systems which all boot Ventoy with ShredOS fine and the eleventh board I tested was a old MSI-7366, i believe circa 2006. It booted Ventoy, obviously in legacy mode but then dropped into the grub command line without loading the ShredOS kernel.
Every other system I tested I believe had UEFI support with secure boot disabled although I need to double check that to be sure.
Seeing as Vanilla ShredOS boots fine on the same MSI-hardware using it's own GRUB but fails with Ventoy, it's possible this might only be a issue on old systems only that don't provide UEFI support.
Can you all confirm that all these systems that drop to the GRUB prompt are all legacy only bios?
I also want to make you aware of this thread on the Ventoy forum. So is it a Ventoy problem or a ShredOS problem, is it both or neither?
At the moment we are still trying to figure out some commonality between systems that exhibit the behaviour of dropping to grub. And that is why DETAILED information about the problem is required.
At the bare minimum when posting for the first time the following should be provided as routine:
- make/model of system or make/model of motherboard if home build
- output of lspci
- CPU type more /proc/cpuinfo
- Legacy or UEFI boot.
- Number of GPU's on system and connection method from graphics to monitor, VGA, DVI, HDMI or Display Port.
Here is a video showing what was previously Ventoy with ShredOS on a legacy only bios that ends up at the grub prompt. For this to work the ShredOS img must reside in the root of the Ventoy stick, however that only applies to legacy bios. The reasons ShredOS fails to boot is that it is expecting the ShredOS USB to be present as hd0 not hd1 and that's why it fails. UEFI doesn't fail because it works completely different.
The commands you would type at the grub prompt are as follows, the console and loglevel are absolutely necessary don't leave them out or get them wrong else the screen will get garbled and keyboard may not work properly.
grub> linux (hd1,msdos1)/boot/shredos console=tty3 loglevel=3
[ Shredos loads ....... to 100% then you type 'boot` at the grub prompt]
grub> boot
As to whether there is anything I can do in ShredOS to resolve this, other than always build an .iso for Ventoy! Anyway that's why Ventoy & ShredOS work on UEFI with .img files and don't on legacy. I'm not even sure it's all legacy systems. I would have to dig out some really old legacy to test some more.
So I think the solution is to always have both ShredOS .iso & .img on your Ventoy stick. .iso should work on all systems.
Ventoy.boot.legacy.VID20240129194520-1.mp4
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
The video on my system is displayed all wrong with the comment overlaying the video using the Chrome browser so if yours looks like this... then click on the [ ] symbol bottom right to go full screen so you can see the video and if you can't see that symbol, then it displays properly in Chromium & Firefox.
@p1r473 @Binary-Bear @juncture6825 @NastyFlytrap
* Are these all systems that predate 2011? * More specifically, are these all systems with a BIOS that does not support UEFI and only provides legacy support?I have now tried about 10 systems which all boot Ventoy with ShredOS fine and the eleventh board I tested was a old MSI-7366, i believe circa 2006. It booted Ventoy, obviously in legacy mode but then dropped into the grub command line without loading the ShredOS kernel.
Every other system I tested I believe had UEFI support with secure boot disabled although I need to double check that to be sure.
Seeing as Vanilla ShredOS boots fine on the same MSI-hardware using it's own GRUB but fails with Ventoy, it's possible this might only be a issue on old systems only that don't provide UEFI support.
Can you all confirm that all these systems that drop to the GRUB prompt are all legacy only bios?
All the computers ive tested on are modern 2019+ systems that support UEFI. None of these systems are legacy only bios.
I also want to make you aware of this thread on the Ventoy forum. So is it a Ventoy problem or a ShredOS problem, is it both or neither?
At the moment we are still trying to figure out some commonality between systems that exhibit the behaviour of dropping to grub. And that is why DETAILED information about the problem is required.
At the bare minimum when posting for the first time the following should be provided as routine:
* make/model of system or make/model of motherboard if home build * output of lspci * CPU type more /proc/cpuinfo * Legacy or UEFI boot. * Number of GPU's on system and connection method from graphics to monitor, VGA, DVI, HDMI or Display Port.
I saw the thread. The problem is that the issue happens on 32GB and 64GB USB drives. So it cannot be related to the 128GB USB drive.
I'm using UEFI, AMD CPU & GPU connected via HDMI. All the equipment ive tested on is modern systems.
Here is a video showing what was previously Ventoy with ShredOS on a legacy only bios that ends up at the grub prompt. For this to work the ShredOS img must reside in the root of the Ventoy stick, however that only applies to legacy bios. The reasons ShredOS fails to boot is that it is expecting the ShredOS USB to be present as hd0 not hd1 and that's why it fails. UEFI doesn't fail because it works completely different.
The commands you would type at the grub prompt are as follows, the console and loglevel are absolutely necessary don't leave them out or get them wrong else the screen will get garbled and keyboard may not work properly.
grub> ls (proc) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) grub> linux (hd1,msdos1)/boot/shredos console=tty3 loglevel=3 [ Shredos loads ....... to 100% then you type 'boot` at the grub prompt] grub> bootAs to whether there is anything I can do in ShredOS to resolve this, other than always build an .iso for Ventoy! Anyway that's why Ventoy & ShredOS work on UEFI with .img files and don't on legacy. I'm not even sure it's all legacy systems. I would have to dig out some really old legacy to test some more.
So I think the solution is to always have both ShredOS .iso & .img on your Ventoy stick. .iso should work on all systems.
Ventoy.boot.legacy.VID20240129194520-1.mp4. . . . . . . . . . . .. . . . . . . . . . . . . . . .
Do I need to create Ventoy with GPT instead of MBR then? Or do I just wait for the latest .iso image to drop?
Do I need to create Ventoy with GPT instead of MBR then? Or do I just wait for the latest .iso image to drop?
You could try GPT, however building a .iso just moved up my priority list so if I can clear enough space on my hard disk to do a .iso build that may happen before the end of the week.
Are these all systems that predate 2011?
For me, yes.
More specifically, are these all systems with a BIOS that does not support UEFI and only provides legacy support?
For me, yes.
Can you all confirm that all these systems that drop to the GRUB prompt are all legacy only bios?
For me, yes.
So is it a Ventoy problem or a ShredOS problem, is it both or neither?
Not sure... but the only time I have this problem with Ventoy is when I am booting shredos.
So is it a Ventoy problem or a ShredOS problem, is it both or neither?
Not sure... but the only time I have this problem with Ventoy is when I am booting shredos.
Is that because all your other images are .iso files ?
Is that because all your other images are .iso files ?
Yes they are!
I saw the thread. The problem is that the issue happens on 32GB and 64GB USB drives. So it cannot be related to the 128GB USB drive.
I'm using UEFI, AMD CPU & GPU connected via HDMI. All the equipment ive tested on is modern systems.
That 128GB limit was system dependent, he did mention it may be less than that on other systems, i.e 8GB on some HP systems for instance, but that's only for old systems anyway.
And just to confirm we are talking about the drop to grub, not about the hang just after the common interrupt messages, which looks to me like it could be a framebuffer to Display Rendering Manager (DRM) issue
Is that because all your other images are .iso files ?
Yes they are!
So the answer for you and because of the vintage of your system is to hold on for the .iso file which I'll try to build by the end of the week.
However you might want to try those grub commands , ls, linux and boot just to see if you can get the .img booting like in the video above.
grub> ls
(proc) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0)
grub> linux (hd1,msdos1)/boot/shredos console=tty3 loglevel=3
[ Shredos loads ....... to 100% then you type 'boot` at the grub prompt]
grub> boot
Here's the entry in the buildroot menus that configure the boot partition, but ventoy puts ShredOS into hd1 and Ventoy takes over hd0 and that's why it fails and drops to grub. For UEFI although grub is still used to load the kernel I guess the kernel is found on hd0??
If you were building from source you could build a special for Ventoy where the boot partition in the buildroot config was changed from hd0 to hd1 and maybe that would then boot fine. I don't really want to do that though as a .iso would serve the purpose and be useful for DVD/CD too.
I got shredos to start booting by using a different command.
I noticed after typing "ls" I received a different output than you.
In your video your output was : (proc) (hd0) hd0,ms2 hdo,msdos1 hd1 hd1,msdos1 fd0
When I typed "ls" the output I received was : (proc) (hd0) (hdo,msdos2) (hdo,msdos1) (hd1) (hd2) (hd2,msdos1)
When I typed "linux (hd1,msdos1)/boot/shredos console=tty3 loglevel=3" the output said "error disk "hd1,msdos1 not found"
So I tried the following which started to boot shredos: "linux (hd2,msdos1)/boot/shredos console=tty3 loglevel=3"
So using (hd2,msdos1) got shredos to start booting but the bad news is that it froze on 100% and did not finish.
@Binary-Bear
Did you type boot? the linux command simply loads the file to 100% then does nothing until you type boot.
Sorry you are correct I did not type "boot" again at the end as I assumed once shredos was booting that was it.
After loading shredos to 100% I typed "boot".
I received an error.
Decompressing Linux...
uncompression error
-- System halted
@Binary-Bear That's interesting, uncompression error could indicate a bad memory location in RAM, corrupted .img on USB, data corruption during the load process from USB. How much RAM is on this system? ShredOS needs a minimum of 512 MByte but ideally more depending upon how many discs are being simultaneously wiped.
I would probably do the following
- Confirm the sha1sum checksum of the .img that's actually on the USB stick.
- Confirm CPU RAM is at least 512MB
- Run memtest on the RAM overnight.
SHA1 is correct on USB
There is 8GB RAM
I have run memtest recently as a test to see if I could load another .iso with Ventoy. RAM is good.
What other .isos have you got on the same USB stick, are any Linux, like gparted and do they all boot ok?
Is this the same system that had those awful USB load speeds of 620KiB/s?
gparted and memtest both boot ok using Ventoy/Yumi
Yes same system booting at 620KiB/s
You know gparted includes nwipe. I don't know whether it's the latest version of nwipe, i.e v0.35 but may be worth checking which version they include.
As for what is causing the uncompression error, all I can think of is the USB bus. How fast does gparted take to boot up of the same USB stick?
How fast does gparted take to boot up of the same USB stick?
I think gparted loads faster. I will test again.
I've added the grub notes to the MSI legacy motherboard details in regards to what you need to do if you end up at the grub prompt. See the USB boot speed charts #209
gparted boots at about 19.2MB/s
shredos remains at about 620KiB/s
Both using exactly the same hardware.
How do you determine it boots at 19.2MB/s?
It is part of the gparted boot screen output.
It is part of the gparted boot screen output.
That's odd, I've got both gparted-live-1.1.0-8-i686.iso and gparted-live-1.5.0-6-amd64.iso on my Ventoy flash drive and when I boot either I don't get any mention of boot speed. Takes about 40 seconds after the initial selection screen where you select gparted live. Are you running a different version?
I am using gparted-live-1.5.0-6-amd64.iso.
When you boot to the first options screen choose the second option.
Gparted Live (Default settings & to RAM)
The install speed will then be displayed.
Thanks, got it. I'm getting about 35MB/s on this old 2007 MSI board.
I don't think comparing ShredOS & gparted is a fair comparison as their boot methods are completely different. Here's my reasoning:
When ShredOS loads the kernel it's not using any Linux kernel drivers as such as obviously the kernel has not booted yet, grub is using it's own drivers. The first and only file being loaded by grub is shredos and it's relatively big at 218MByte. Gparted follows the two stage boot where you have vmlinuz and initrd.img. I believe the first stage is only the kernel & drivers and nothing else so the file is quite small, maybe a tenth of the size of the ShredOS file. gparted then uses the kernel drivers and not grub drivers to load the filesystem and required files.
So the slowness in speed may be because there is an issue with the grub driver or maybe that's the way it is with your hardware but with gparted it's not apparent because the first stage is ten times smaller. The second stage is loaded by the kernel drivers.
If this is the case, then if ShredOS gets any larger I might have to look at have a two stage boot so the initial stage drops below 10MB. Maybe it has nothing to do with the grub drivers, maybe it's the speed of the bios. The shredos kernel file has grown to such as size due to the DRM graphics drivers, they now take up over 100MB out of the 218MB. They are necessary however for various reasons to do with APIC and unfreezing drives for running secure erase.
Anyway, that doesn't explain the un-compression error that occurs, so maybe there is a very subtle bug on your hardware. We really could do with an identical motherboard to see if they both behaved exactly the same. Other than that I'm pretty much out of ideas. Other than write ShredOS to a SATA drive. Now that should load really fast ! :-)
We really could do with an identical motherboard to see if they both behaved exactly the same.
LOL It just so happens that I have two of these computers :)
Both have the same issues.
The two stage boot sounds interesting and would be a huge upgrade to shredos.
If it helps, one of the computers ive tested it on has an ASUS motherboard, and the other is an ASUS laptop. These are all modern systems.
Hopefully a solution will be available soon so I can use Ventoy with ShredOS.
Hi PartialVolume
I wonder if this might help you find out what is going wrong with Ventoy and shredos?
Something else which might help explain the troubles with Ventoy. Link
@PartialVolume
shredos.x86_64-2023.08.2_25.0_x86-64_0.35_nomodeset.iso works in Ventoy in both normal grub and grub2 mode.
Thanks!