Proxmox VE 9.0-1 install via Ventoy - kernel panic

A

andreworg

New Member
Oct 30, 2025
5
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:
You must log in or register to reply here.
Top Bottom