Installed EndeavourOS or other Arch alongside other Distro, then Kernel Panic later

If you are running just EndeavourOS (or other Arch-based Distro) on your computer, or even dual-booting with Windows, and you then choose to install an additional Distro that is not Arch-based, then this article is for you.

If you are dual-booting or multi-booting even one more Linux that is not Arch-based, chances are you are going to come across a Kernel Panic.

It will occur following updates and upgrades executed on the non-Arch distro, which are sufficient to cause that distro to assume the spot of Primary Partition, that is, top of your Grub Menu.

This article applies to Grub only, although I would be interested to hear from rEFInd users and users of other bootloaders.

The packages updated and upgraded which will generate this change in order include but are not limited to some combination of the following:

Your kernel
Grub, grub-efi, grub-pc, grub-signed and so on
Shim, shim-signed
Some major firmware updates
Other (you’ll find them, or they'll find you!)

You’ll reboot your computer, the other distro will now be in top spot and work fine, and then you key down to choose EndeavourOS and

Kernel Panic

The Kernel Panic will dump you to a black and white (tty-style) screen with output looking similar to the following

Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0)

This will be followed by a CPU reference, hardware name, a call trace, a Kernel Offset, and end with

—[ end Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0) ]—

You cannot exit or get a response other than to power down and start again, and this time not choose EndeavourOS

It has been said that the only way to prevent this circumstance is to be sure the EndeavourOS (or other Arch, Arch-based) Grub is in control.

That is not so.

It is simply a matter of generating a file called


and storing it in your (/boot/grub) folder (could be (/boot/grub2) in some distro families) and an entry or entries for that will appear at the end of your Grub Menu once you reboot. No need to update Grub. Just do it.

I will now show you how to do this.

I will take the shortest way to summarising it, because I know there are users out there in need of this, and then I will fill out more detail for those generally and genuinely interested. So it may be a Thread in instalments.


If you are a user of Timeshift, BackInTime, Snapper or similar system restore tool, first take a snapshot/image of whatever working OS you have operating and safeguard that.
Get the UUID of the root partition of your Endeavour or other Arch-based distro and have it handy, you will need to enter it. This can be obtained by a number of methods, including, but not limited to the following-
    In Gparted, right click the root partition, click info
    In Terminal use blkid | grep -i (label of distro if labelled)
    Check for it in /etc/fstab
    Other means
Decide what text editor, whether CLI or GUI, you want to use to make a small text file, and be aware that the resulting file will need to be placed in (/boot/grub), or specifically, in the folder where your grub.cfg file is stored.
This will require root privileges, for example sudo, or assuming the non-Endeavour, non-Arch-based distro (for example boot into Linux Mint) that is in the primary partition (top) spot on your Grub Menu.
Boot to the non-Endeavour, non-Arch-based distro (for example boot into Linux Mint) that is in the primary partition (top) spot on your Grub Menu.


A typical EXT4 UUID will be in the format of 32 digits and alphabetical characters, structured like this (8 then 4 then 4 then 4 then 12, separated by dashes)


For this exercise I will use


and you substitute the value by copying/pasting the result you got from Prep Step 2. 1.-4. above.

Either use touch to create the file custom.cfg and then your favourite text editor, or I just use nano as follows
sudo nano custom.cfg

and enter this text, where the string of n’s is the UUID for your Endeavour or other Arch-based distro’s root partition

menuentry “EndeavourOS - configfile” {
insmod part_gpt
part part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn
configfile /boot/grub/grub.cfg

The part in quotes in the first line is a choice for you, you could call it
“My beloved EndeavourOS” if you wished.

Other than that, make sure the syntax matches exactly, including those two curly brackets.

  1. Save and exit, or exit and save, the file, with it in (/boot/grub) or wherever your grub.cfg file is.

  2. Reboot (no need to update grub)

If you have followed the above correctly, when you see your Grub Menu it will have an additional entry at the end saying what was in that first line. That is your new entry point to EndeavourOS or your chosen Arch-based distro.

There will still be the other entry for EndeavourOS in the ordered Grub Menu list, but if you choose that you will still encounter the Kernel Panic, so practise picking the end one.

I will have more to follow this, but this will get you going for now, and eliminate that Kernel Panic.

In upcoming Posts I will detail how this method compares with others, and why this occurs with Arch-based distros and not others.

Enjoy your Linux.



I am not sure, but I seem to recall once reading an alternate way to deal with a new distro (not arch-based) install that changes a UUID.

Not sure about that one @garybean without some more information. If you think of anything further, add to it and we can take a look at it. Starting on the “why it happens” shortly. Wizard

possibly this bug (ubuntu multiboot install on existing arch installation was unique to ubuntu)

if I recall correctly the reason was mentioned somewhere, unfortunately where is lost to me

perhaps adding opensuse to an existing arch installation does not share this quirk

Hi, the solution above is for multiboot out of a non-arch-distro, in your case if you use the suse-grub. As long as non-arch-grub is used, look as sudo in /boot/grub/grub.cfg, if there is in section 30 for suse behind initrd: /boot/grub/intel-ucode.img and then /boot/grub/vmlinuz~or something similiar. Only deleting the …intel-ucode part will start suse. But it is not lasting, grub-mkconfig will destroy it again.

The ‘fix’ being to have EndeavourOS do the grub generation is not the only way - just the easiest. EndeavourOS has the tools to ‘repair’ the grub entry, including on regeneration. Essentially the ‘other’ grubs do not allow for multiple initrd entries, and often (usually) select the wrong one to initialize. The fault lies in the operation of os-prober, and apparently they won’t address it.

I could ‘solve’ the problem with the EndeavourOS tools, or by putting up with hand editing the grub.cfg after each time it is generated, or by making a custom entry for each bootable distro, or… but I choose to eliminate it by using rEFInd, which can handle it all seamlessly. Check out our Wiki for more information on rEFInd.

BTW - choosing the fallback entry for EnOS will also get you rebooted, thus making any editing easier…

1 Like

Each distro will not move since years, the “bug” is known. The easiest way for solving would be to change the two /boot -orders, then other grubs will fetch the first, right one. Maybe EnOS has to change intern the order again. But a simple if-then-else-loop in the EnOS-code of grub could solve the issue.
if intel-ucode.img is truth then initrd /boot/intel-ucode.img /boot/initramfs-linux.img else initrd /boot/initrd.img-5.x.0-xx-generic
The OS-prober has only to search for Intel-ucode in /boot also and say ‘truth=the file is there’ or nothing.

I think that is not far from what it already does. Of course, amd-ucode has to be allowed for as well :grin: We need the right mitigations, after all!

I got the impression that, provided the order is correct, a version of the initrd file can be generated with BOTH contents - so that could be another way out of it. I still find rEFInd the easiest way to handle diversity (5 distros on here, 8 on another box ATM).

Not a bug, and not at all unique to Ubuntu, but I will explain with a fuller Post below some time my today.

Thanks, think also it is not such a great thing, more like refractory children, because it’s lasting since several years.
Forgot amd-ucode, my “solution” is thought as suggestion only. (for the code of grub-mkconfig)
To unify both contents will not work, because the ucode.img-file is per content a cfg-file => and this is handled from the most used distros as such.

menuentry “EndeavourOS - configfile” {
insmod part_gpt
part part_msdos …
in Mint use ‘My beloved EnOS’ instead of “My beloved”, otherwise the text will not be shown.

Today i got my 1st Kernel Panic with EOS, this post is a lifesaver, thank you! :+1: :grinning:

1 Like