Updated Kernel on Linux Mint, now cannot boot Manjaro

Hi Everybody,

I’m quite new to linux world. I decided to install linux mint and it worked fine. But then I also decided to install Manjaro KDE. I was able to boot all the OS: Windows, Mint, Manjaro. Today I have installed the update on Manjaro (a lot), rebooted and installed the update on Mint (few, including new kernel). When I tried to boot againt into Manjaro I got the kernel panic. Some solution on the web are to run
update-initramfs -u

from Mint but Manjaro still daes not boot.


I’m not so good in computer skils, therefore I kindly ask you a step by step procedure in order to recover my Majaro partition.

1 Like

This is a known issue. The Grub bootloader settings of most distros cannot boot Manjaro and Arch. You need to make Manjaro take control of Grub again. Here is a guide:
It is not very easy to understand, but if you basically run
manjaro-chroot -a
on a Manjaro live USB you will get the system chrooted automatically and then can run
sudo grub-install --recheck /dev/sda sudo update-grub


Not clear to a not expert like me. Could you please explain it step by step? For instance, what does mean “I chrooted”?

It means this:

You could have found an explanation if you tried to search.

1 Like

Also FYI I moved your post to a separate topic, because it is unrelated to the topic where you posted. You problem is much simpler. And I posted a clear solution.

1 Like

Perhaps this will be easier to follow and to do?

Don’t forget to go to “When booted section” after you boot to Manjaro

When booted into Manjaro, at terminal,

sudo grub-install /dev/sda
sudo update-grub

Yeah, this is a method without chroot.


first of all thank you for your support.

I boot into the Manjaro XFCE live CD and executed the following commands:

but I got the error cannot find EFI directory.

Therefore I have tried the following:

but it still does not work.

How cn I report here the terminal output? I have it into a txt file, maybe you can check it.

1 Like

It is much more simpler to accomplish. Since you have grub controlled by Mint it detects the wrong kernel image when intel-ucode package is installed.

Let’s say you have the linux44 kernel installed. On Manjaro you would have then followed initrd line:

initrd	/boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img

On Mint you have instead this line:

initrd	/boot/intel-ucode.img

To boot into Manjaro you simply select the boot entry in your Mint grub and press the E button for editing that one. Search for the line were you find the intel-ucode.img and replace it with the proper initramfs image. Press then CTRL+X to start your Manjaro. Within Manjaro you simply remove the package intel-ucode and call update-grub. Then reboot and do the same update-grub command in Mint. Next reboot you can check it again. The initrd line should now be:

initrd	/boot/initramfs-4.4-x86_64.img
1 Like

Did you do this first? That is… boot into manjaro, not livecd.

grub> search.file /boot/intel-ucode.img root
grub> configfile /boot/grub/grub.cfg

If you follow phim post, it will work but you will not have intel-ucode activated in your boots.


Hey!, this worked for me! It was very useful. Thanks! (Sorry for my English…)

1 Like

Hallelujah for this post! I’ve been running into various Grub issues with kernel updates on multi-booted systems, both in EFI and older BIOS computers. Today, yesterday I updated (stupid - if it ain’t broke, don’t fix it …) Peppermint, a downstream Mint distro, and it left me with a kernel panic on an attempted Manjaro boot. My “solution” this time was to reinstall Manjaro. Next time I’ll be sure to refer to this information. Thanks again.

1 Like

The reason is the intel-ucode we use, microcode updates for cpu, firmware.
Other distros load it later and not immediately with the bootloader, but an early service perhaps.


You got XY distro and manjaro installed, and XY distro has the actually controlling grub, ie the grub that boots the system. From manjaro installation, the XY grub. This XY grub likely doesn’t detect the intel-ucode from manjaro’s /boot
directory, thats loaded together with the kernel’s initramfs. That’s the point, XY grub fails to load manjaro.

There is another solution, instead of changing to manjaro grub.
You could simply modify directly the XY’s /etc/grub.d/10_linux to make it detect intel-ucode.img

I can’t give a one-size-fits-all solution here, because the /etc/grub.d/ scripts may look slightly different on each distro.
But, if you compare(eg with diff) the two /etc/grub.d/10_linux files, from XY and manjaro, you quickly get the difference where it detects intel-ucode.img. You could also search in manjaro’s 10_linux script for

if test -e "/boot/intel-ucode.img" ; then
    gettext_printf "Found Intel Microcode image\n" >&2
    intel_ucode="$(make_system_path_relative_to_its_root /boot/intel-ucode.img)"


if test -n "${initrd}" ; then
    # TRANSLATORS: ramdisk isn't identifier. Should be translated.
    message="$(gettext_printf "Loading initial ramdisk ...")"
    sed "s/^/$submenu_indentation/" << EOF
	echo	'$(echo "$message" | grub_quote)'
	initrd	${intel_ucode} ${rel_dirname}/${initrd}

and integrate in in the XY’s 10_linux.

Phew, long explanation for so little change. :smiley:

1 Like

Perhaps little change, but justified if big results ensue. Thanks much!

To check if other distros boot later, as you claim and I dispute

dmesg | grep microcode

To doublecheck, go and do same with Manjaro.
Also repeat same with Manjaro this time without intel-ucode in the initrd line.

In both non-manjaro and manjaro with intel-ucode, you’ll see something like

microcode updated early to revision yxzz, date = xxxxx

So it is not true that other distros “load it later”

We can make a fuzz of it, or simply say, other distros don’t load it with bootloader together with initramfs. On gentoo, its entirely optional, ucode is not installed by default but it would start with an early service. Having intel cpu, I don’t use ucode on gentoo.
The point was to make the foreign grub add the proper ucode line for a manjaro install in grub.cfg.

The main problem with this is that it really gives Manjaro a reputation as a distro that does not play well with other distros’ grub.

How many similar such threads have been started in this forum, because people install other distros after Manjaro and let the latest distro take over as controlling grub only to find to their puzzlement that they can no longer boot into Manjaro? Or the user has an earlier-installed distro that used to control grub and it has just received kernel upgrades, triggering the update-grub process and stealing back control of grub, except of course that grub can’t boot into Manjaro?

Manjaro is my main rolling distro and controls grub on my machine, but as a multibooter, this quirk of Manjaro is a little annoying.

1 Like

As you know long time ago, I agree with you.
As I also know, you and I don’t have a problem with it, because we know how to ‘work it’.

Just glad you are talking out on behalf of people who don’t know ‘how to work it’.
I stopped talking, as you know on this for a long time now (and do not wish to talk further).

I’m here in my earlier post objecting the untruth that other distros do not load intel-ucode ‘earlier’. And object to people telling others to uninstall intel-ucode as a solution.

Thanks for speaking out.

I don’t know anything about the technical aspects of loading the intel-ucode, so can’t comment on that.

I just wonder if there is a solution to this whole issue so that other distros’ grub don’t have a problem detecting and creating a correct grub entry for Manjaro.

Out of curiosity, does Arch behave the same as Manjaro? In other words, is this a Arch-family thing?

There are quite a few actually,
We can add a custom.cfg to the other distro.
In that, we can do one of 4 things
o multiboot to the core.img/core.efi
o configfile to the grub.cfg
o chainload
o boot directly the manjaro sym-linked kernel

I do none of the above but I use my own grub that boots the direct sym-link kernel

Yes, Arch does the same thing. Interestingly, Arch grub cannot boot manjaro, but Manjaro can boot Arch. That’s because Arch does not modify its grub to handle Manjaro; Manjaro modifies to handle intel-ucode in Arch. Antergos (like Gentoo, as artoo said) does not install intel-ucode at all. But user can install it and modify the grub.cfg themselves to boot. Antergos grub (without modification) cannot handle its intel-ucode that users install.

Distros like Ubuntu, Debian, mageia, Fedora… okay all else :grin: builds into the kernel intel ucode (not as modules) nut into the initrd files. They boot earlier. And don’t require modification of grub.

1 Like

Forum kindly sponsored by Bytemark