Apparently I am also facing the rather common problem now after my dualboot Ubuntu installed updates and also updated grub overwriting the Manjaro grub.
My first question is, how to get Manjaro back. I read there can be some lines added to the Ubuntu grub config file (Kernel Panic VFS unable to mount root fs on unknown-block(0,0)), but that lines are probably outdated and for my recent Manjaro installation I’d need some new lines to paste in there. If there is an easier way to recover, I’d be glad, since I don’t really like messing with grub config files.
Second question: I think this will always happen, when Ubuntu updates grub and if I am right that the lines for the grub config file are not “paste and forget”, but actually have to be adjusted to fit the installed Manjaro version (including kernel version) then this is not really a longterm solution. So is there a good way to go to not face this again?
If I had searched and found an answer which has been used successfully, I think I’d probably have tried the solution rather than posting a second thread with an identical title. That said, I know what I’m doing…
Sure, the kernel version would need to be changed to fit your kernel (and only you know which kernel you have installed) but I don’t see what would have changed within either GRUB or Ubuntu in twelve months.
Why not try the same lines but adjust for your kernel?
Since you’re new to Manjaro and looks like newish to linux, we’ll once again (done ad nauseam, perhaps ad vomitum) state that other OS’s bootloader will not boot manjaro and end with kernel panic that you experienced.
We will not go into why that’s so and definitely will not go into whether that’s correct to do. just that the simplest way out of this is to let manjaro’s grub be the default grub and boot every other OS’s from its grub.
See this topic (the first post) on how to go about it.
You do not have to remove Ubuntu’s grub, just set it to its own partition - if bios-legacy. If uefi, set efibootmgr to default to manjaro as first bootorder.
Warning: GRUB strongly discourages installation to a partition boot sector or a partitionless disk as GRUB Legacy or Syslinux does. This setup is prone to breakage, especially during updates, and is not supported by the Arch developers.
So this does not seem to be a nice solution for this, unfortunately.
The point is that you have two GRUB instances which conflict. Manjaro installs GRUB, Ubuntu installs GRUB.
Only Manjaro will configure GRUB correctly for Manjaro.
If you want to use Ubuntu to manage Manjaro’s GRUB entries then you will need to perform the necessary manual configuration to Ubuntu’s GRUB configuration, and you should go and ask on the Ubuntu forum.
If you use only Manjaro to manage GRUB then the various instructions on the forum and wiki will work and you will have no issues.
Other potential solutions include:
use a Manjaro live image to restore Manjaro’s GRUB every time it breaks
install the Ubuntu GRUB to the Ubuntu partition, then Ubuntu can update Ubuntu’s GRUB without affecting Manjaro’s GRUB in the disk’s MBR
remove Ubuntu’s GRUB package so it won’t update it, and instead use Manjaro to update the loader entries when you update Ubuntu’s kernels
Of course, if you want an answer where you don’t have to do anything to resolve the situation you’ve created by having conflicting bootloader configurations then you’re going to be waiting for a long time.
Ideally I’d prefer using the Manjaro GRUB. However, how are Ubuntu support Forums going to help me to get the correct configuration to boot Manjaro properly? But ok, I guess your point here is that you are not willing to invest time into investigating how grub is configured on Ubuntu (or how to fix this on Ubuntu side), which I can understand.
I guess this can only be achieved by telling Ubuntu not to install their GRUB into the MBR anymore, correct?
And from my understanding this can be either done by uninstalling GRUB from Ubuntu (which apparently results in the need to update GRUB on Manjaro when the Ubuntu kernels are updated) or telling Ubuntu to install their GRUB onto the partition, not the MBR, which is “strongly discouraged” by the GRUB developers.
However I also read something about chainloading (https://askubuntu.com/a/705115), so maybe there is another way?
Unfortunately this look rather like workarounds to me.
I’d be cool with an answer requiring a one time action and which is not “strongly discouraged”. But maybe that is not possible due to the nature of my problem. In that case, I’d still be glad to have a starting point where to address this, even if it takes very long.
If you had searched more, to repeat jonathon, you can see several posts.
This topic here with the same heading as this topic can explain how you can set grub to Ubuntu’s partition. And yes, there is this ‘severe’ warning that you talked about. The grub developers decided to leave the warning there for people who might not have or set a bootloader before setting to partition. BTW, I’ve been doing this for, like centuries.
And, since your search foo is weak, here’s another topic here for you how to boot Manjaro from Ubuntu.
As said, we’re doing this because you’re new. Hopefully we should not need more ‘hand-feeding’ in the future.
It appears you’re completely misunderstanding that having two distros manage GRUB will not work without reconfiguring one of them.
Given that Manjaro’s GRUB configuration will work for both distros, you need to do “something” to Ubuntu’s GRUB configuration.
@gohlip has already pointed you in the direction of posts on the Manjaro forum. It is completely pointless repeating information which is already available. The entire point of the Web is using hyperlinks to point to information which already exists. If you’d like help with any of those threads please do ask.
If you’d like help configuring Ubuntu, please post on the Ubuntu forum.
The reason why grub-setup does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the /boot/grub/i386-pc/core.img file and the prefix directory /boot/grub . The sector locations of core.img may change whenever the file system in the partition is being altered (files copied, deleted etc.).
However I found a workaround on that same page now:
My biggest problem was to find reliable information, since there were different solutions for the problem in the various threads (including one that is actually discouraged in the way it is listed there). In retrospective there does not seem to be a thread around here “with an answer requiring a one time action and which is not “strongly discouraged”.”
From my understanding and correct me if I am wrong this is generally not the case. In fact afaik it works with almost every distribution apart from Manjaro. But yes, probably having the system set up like this is not the best idea. My problem is that I just installed Ubuntu by default and Manjaro with the install assistant. This is the outcome I got. So if this is not good, then maybe there can be changed something in order to avoid this.
I am totally ok with hyperlinks and did not want it to appear like I was requesting you to repeat this information.
After thinking about it, I wonder (just technically), whether I will need to update grub on Manjaro regularly in order to get the correct Ubuntu entry after an Ubuntu kernel update. And if so, whether chainlinking or whatever could fix that.
Strongly recommend you do not do this.
Whenever there’s any grub-install (not grub-update), a new core.img will be generated.
If the attributes for it cannot be changed, that grub-install will fail.
chattr -i /boot/grub/i386-pc/core.img
before doing the grub-install. And really, there’s no point.
core.img will only be damaged if we resize that partition to the left. Of course, deleting, formatting the partition will destroy it also, but then the OS itself will be destroyed, isn’t it? So …what? And furthermore, if the core.img is destroyed, it can be restored with a simple ‘–no-bootsector’ or another ‘grub-install’. A trivial matter. Another thing, even if the core.img is destroyed and the OS is intact, booting up with existing grub.cfg will not fail, as it does not assess core.img.
Yes, of course. Unless you use the entries in my second link.
Use the entries in the second link. What’s this chainlinking? Do you mean chainload?
Isn’t that also one of the few entries in my link that would boot? It is, as noted there, the least preferred.
Well, clel, you’d do well as a manjaro user, always questioning status quo, established method, and disputatious. Don’t take that a compliment.
Ok, so basically installing GRUB from Ubuntu to the partition is putting it into an unused place where it does not get launched by default from my understanding.
When this is correct, then I’d also understand why it is not really important, if that installation would get corrupted by some reason and I’d also see that there is no need to do the chattr stuff. So after I already did this, can this simply be undone by chattr -i /boot/grub/i386-pc/core.img?
Just for the record, when you say:
There is a section on the Arch Wiki I linked above saying
The sector locations of core.img may change whenever the file system in the partition is being altered (files copied, deleted etc.).
Both statements are not conflicting with each other, but if I read the Arch Wiki correctly, also when the sector locations of core.img change it can screw up the setup (which in this case would not matter, since this GRUB installation is not used).
Sorry, I meant chainload. Your second link is only sensible, when having both GRUB from Manjaro and Ubuntu install to MBR, correct? So a different approach then installing Ubuntu GRUB to the partition (just for understanding).
I know, it can be annoying for the people trying to help. From my perspective it was basically trying to make sense of the different information I was confronted with which at first look seemed contradictory to me. In the end now I think I have understood the problem up to the extend that the information available all makes sense.
Thanks to all for taking that patience and answering my questions, I appreciate that!
Just FYI, if the system is uefi, there is no core.img but core.efi, we do not use ‘mbr’ but the $esp; ‘setting grub’ to partition does not make sense; the issues you raised here are moot in such a system. Just setting up efibootmgr to whatever default bootentry would do. It is much simpler.
No, I don’t mind your asking these questions actually. It makes us question our accepted norms and if these norms are valid and so change if they do not make sense. If the norms stand, it makes a better understanding of the norms as well.