Proxmox VE 9.0-1 install via Ventoy - kernel panic

A

andreworg

New Member
Oct 30, 2025
7
3
3
Hi,
I'd like to share what happened to me today, hoping that it will save others some sweat.

I installed Proxmox VE from the latest ISO (currently 9.0-1) after booting it through Ventoy.
The installed system could not boot; I got a purple screen with the following message:

KERNEL PANIC!
Please reboot your computer.
VFS: unable to mount root fs on unknown-block(0,0)

I finally found the root issue: the installer carried over to the installed system a kernel parameter that was clearly injected by Ventoy working in GRUB mode:

linux /boot/vmlinuz-6.14.8-2-pve root=/dev/mapper/pve-root ro rdinit=/vtoy/vtoy quiet

the rdinit=/vtoy/vtoy parameter was clearly the culprit.

I actually found some reference to this issue, along with a resolution, on other threads. But I decided to post this anyway.
I'm not 100% sure, but if I got everything right, this may be an installer issue that may be addressed.

Happy hacking, -a
 
  • Like
Reactions: johnw40223
could you walk me through that a little better a am new to linux world having the same issue. not sure where to go to make that change. any help would be greatful thanks
 
UPDATED TO ADD: new fix, see later post for more details.

1) Boot into rescue mode

2) Remove the problematic rdinit=/vtoy/vtoy parameter from /etc/default/grub.d/installer.cfg, or remove the file altogether if there are no other parameter additions you need

3) update GRUB bootloader config by running

update-grub

4) Check that the generated /boot/grub/grub.cfg no longer contains rdinit=/vtoy/vtoy

5) Reboot the system.


Previous post contents:
WARNING: this won't fix the issue for good, it will come back after update-grub is run (e.g. after a kernel update).

I haven't got the system available right now, just following my notes.

Boot into rescue mode, then remove any occurrence of rdinit=/vtoy/vtoy from /boot/grub/grub.cfg .

These commands might help you do that:

# Remove the problematic parameter
sed -i 's/ rdinit=\/vtoy\/vtoy//g' /boot/grub/grub.cfg

# Verify it's removed - should return nothing
grep rdinit /boot/grub/grub.cfg

Then of course reboot.
 
Last edited:
  • Like
Reactions: Onslow
Hi all,
guess what: I just updated the kernel in my pve, rebooted and... the dreaded purple screen of death reared its ugly head again!

I found a reference to rdinit=/vtoy/vtoy it in /etc/default/grub.d/installer.cfg :
Code: 
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rdinit=/vtoy/vtoy"

It seems to be executed by /etc/grub.d/20_memtest86+ :
Code: 
config_item()
{
    for x in /etc/default/grub /etc/default/grub.d/*.cfg; do
        if [ -f "$x" ]; then
            # Lose any output here so we don't confuse our caller
            . "$x" > /dev/null
        fi

That's what makes it come back when update-grub gets run.

Long story short, I edited my previous post with a new fix.

Happy hacking, -a
 
Last edited:
In all of my Proxmox different installations, there is no /etc/default/grub.d/installer.cfg. Maybe Ventoy adds it? You can probably remove it.
 
You are right. In the example I made, only the rdinit part gets added; so if you remove it, you'd just set the env var to its own value, which obviously makes no sense. So you may as well remove /etc/default/grub.d/installer.cfg altogether.

What actually happened in my case is that I had to add parameters to the Linux cmdline during installer boot (modprobe.blacklist=nvidiafb nomodeset) otherwise it would hang, and they were carried over during installation. I don't know if /etc/default/grub.d/installer.cfg got created because of my additions, or if Ventoy's rdinit addition would be enough to get it created. But in case you actually need these additional params in the installed system, if you remove the /etc/default/grub.d/installer.cfg file you'd have to put them elsewhere.
 
i tried removing installer.cfg didnt do anything so ill try what you said andreworg nvm had to update grub thanks
 
Last edited:
Hello,

I know that this is an old thread, but I looked through the 20_memtest86+ file and its not clear where to place the code you added above. I just installed 8.4 again. I lost my boot drive. So I decided to start again using zfs raid10. Every time I have to do a restart, rdinit=/vtoy/vtoy is appended to the kernel command line. So where in this file should this code be placed? I'm a my memory isn't what is used to be :(. So if you could spell it out for me tx.
 
ParasiticTwin said:
Hello,

I know that this is an old thread, but I looked through the 20_memtest86+ file and its not clear where to place the code you added above. I just installed 8.4 again. I lost my boot drive. So I decided to start again using zfs raid10. Every time I have to do a restart, rdinit=/vtoy/vtoy is appended to the kernel command line. So where in this file should this code be placed? I'm a my memory isn't what is used to be :(. So if you could spell it out for me tx.
Click to expand...
Not sure I get what you mean. 20_memtest86+ executes any /etc/default/grub.d/*.cfg; I did not add any code, just advised to remove anything that possibly adds rdinit=/vtoy/vtoy to GRUB_CMDLINE_LINUX, resulting in it being added in entries in grub.cfg when it is rebuilt, e.g. after an update. Hope that helps.


uzumo said:
Since this issue doesn't occur in the new version of Ventoy, why not update Ventoy and reinstall it?

There's no point in continuing to use a version of Ventoy that has this problem, is there?

https://www.ventoy.net/en/distro_iso/proxmox_ve.html
Click to expand...

Not sure I get this either. Provided that the issue at hand is no longer present in newer versions of Ventoy—and i think the green flag in the test reports says nothing about this, since it's not really a issue rather than a solution—reinstalling Proxmox to fix the unwanted behavior seems overkill to me. Or maybe you meant something else.
 
ParasiticTwin said:
I just installed 8.4 again. I lost my boot drive. So I decided to start again using zfs raid10.
Click to expand...

If you really just want to know the solution, that’s fine too.

It’s just that, since you’ve already reinstalled it, I thought it would be a good idea to check whether the issue has been resolved in the latest version.

If you fix it that way, your current problem will be solved, and you’ll likely be able to continue using your existing Ventoy installation with the ISO without having to do any further work or modify Ventoy itself. If you don’t mind the same thing happening again the next time you reinstall, then please do as you like.

*Well, either way, I don’t mind, so please do as you like.

The URL might have been wrong, but I’ve always been installing the newer version of Ventoy USB, and the issues I used to have just haven’t happened at all lately.

Update
I was just curious, so I gave it a try using version 1.1.05, which I have on hand. If you proceed with the installation in normal mode, there’s no problem, but if you use GRUB2 mode, the reported issue occurs. Sorry about that.
 
Last edited:
  • Like
Reactions: andreworg
uzumo said:
Update
I was just curious, so I gave it a try using version 1.1.05, which I have on hand. If you proceed with the installation in normal mode, there’s no problem, but if you use GRUB2 mode, the reported issue occurs. Sorry about that.
Click to expand...
Yep, that's it. Reading back my first post, I realize I wasn't too clear about that. This parameter injection is peculiar to GRUB2 mode, and the easy way - if you are aware of the issue beforehand, obviously - is to use regular mode.
The fact is that the injected param gets picked up by some installers, including Proxmox's, and ends up in the installed system, breaking the installed system's boot process.
As discussed elsewhere, that is not really an issue in Proxmox, because this carrying over may be for good reason, as for instance was in my case I reported above. Maybe the installer could be fixed to avoid carrying over this particular string, and that's probably not a bad idea since Ventoy seems to be quite popular, but then again there may be good reasons not to do it.
i also think that it should be documented that using Ventoy in GRUB2 mode exposes to issues like this when booting images for installation, but I'm not sure it's not and honestly haven't checked yet.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back