Manjaro Stable and Testing on same machine- Grub problems

Oh boy. Have done a search here prior to posting and didnt find anything that answered my question so…

I run Manjaro Stable and Testing on different drives on the same desktop, bare metal,UEFI. On testing tonight when installing the 510 kernel I ended up fragging GRUB-it was a somewhat involved change necessitating upgrading NVidia 450 to 455 to get the 510 kernel to install with the NVidia package (before my attempt I was running 450 on 59-and the install program would not load the NVidia package). Chroot didnt fix things, what did was reinstalling Stable on its drive,SDA- it re created the FAT32 partition, re installed GRUB, found testing on the other drive and all is good.

When I update either system, GRUB gets updated if a kernel is included. How does the first OS -in this case Testing-on SDB-know that GRUB is now on the FAT32 partition at the start of SDA? what needs to be done to make updates not a pain and make the entire system unbootable the way I did earlier? I have run this way for a while and so far have had no problems but earlier when things were broken I found 2 GRUB.cfg files on the FAT32 drive before reinstalling Stable on SDA…this seems like its probably a stupid question but my history here to fore has been running Windoze and Manjaro dual boot on the same system. This is the first time I have run 2 Manjaro installs on the same system(sans Windoze). If I now do an update to Testing on SDB, should it find GRUB on SDA and update that? At this point both Stable and Testing are bootable and running but with an update that requires a GRUB update, then what?
Thanks.

I suggest you boot off a live USB then mount each system manually - in turns.

Repeat below steps for both installations

mount /dev/sdy2 /mnt

Then chroot

manjaro-chroot /mnt /bin/bash

Then

 pacman -Syu

Then

 mkinitcpio -P

Then

os-proper

Then

grub-mkconfig -o /boot/grub/grub.cfg

When you are done check the efi boot entries

efibootmgr
1 Like

Hi Linux
Thanks for the kind reply and interest. I understand chrooting, have done that a few times. Understand using os-prober as well. What I dont understand is how it might work with 2 different branches on the same machine, which reveals my lack of understanding about how Grub would interact with them. Grub, currently on the UEFI partition on SDA was installed by Stable on SDA. Testing is on SDB. I am able to boot Testing because os-prober found it when I reinstalled Stable (SDA). In the event that I update Testing(SDB) with for example a new kernel-where it needs to update its boot options… does it go out, search the machine, find the bootable partition on SDA and update that Grub? I have done the steps to make the machine work again although nucking and paving SDA may have been a bit drastic-I think I could have saved stable but was late, tired yadayada. I am trying to understand HOW both OS’es interact with Grub in this situation and learn a bit more than I knew when I started.
Again many thanks for the interest.

Added- on Testing had 57,58,59 and 510 kernels. Booted into testing, removed 57 and 58 kernels and their associated NVidia 455xx drivers all from CLI. Testing generated a new Grub config file as part of the removal process. Rebooted. Looked at the advanced options for the testing version, Manjaro Linux 20.2 on SDB1. Grub still showed 57 and 58 installed. Booted into Stable, “update-grub” rebooted and 57 and 58 disappeared from the advanced options for testing on SDB1. SO testing on SDB1 is updating Grub somewhere but its not the grub that appears when the machine is booted.

if you have stable on sda and testing in sdb
check in /etc/fstab , each have own /boot/efi & grub UUID

there is only version VMlinuz-X-Y ( so you boot on Stable or Testing from last update & build hook )
if on sda it should be vmlinuz-5-9
and on sdb vmlinux 5-10 ,
you always boot on last save boot ok ( systemd & grub conf )

1 Like

Stephane

Thanks for the information. Will check and get back with that. I dont think I am ever seeing the sdb grub. Updates on testing do not cause changes in Grub. Only after I boot SDA and then update grub, do the changes appear in the Grub I see when I first boot the machine…Testing updates update Grub just not the one that appears at boot. Case of the lost or hidden Grub, no??
Thanks and Regards.

Each Manjaro installs its own grub and makes itself first in boot order. It sounds like your testing Manjaro is second in boot order. This means that you have to update-grub in your stable Manjaro whenever you add/remove a new kernel series in either installation. The grub associated with stable is the grub that appears at boot time rather than the grub installed by testing.

1 Like

jbMacAz
I sort of figured that…curious about a couple of things…where the “second” i.e. grub not appearing at boot…puts its info, on the FAT UEFI partition on the other drive? Would be interesting to try to make both grubs write to the same file on the FAT UEFI partition… I have friends that have 3 or 4 Linux distros on one machine and wonder how they handle that. One way would be to install via Architect and not install grub…
Thanks for the reply and interest.

This is a common problem on multi-boot setups. Only one install can be first in boot order. Most of the time the issue has been debian distros won’t boot arch based distros, so the Arch distro has to be first in boot order. In this case, if both manjaro installs share the EFI partition, they are both writing to the same folder boot/efi/EFI/manjaro. Thus you’d only see one manjaro option in boot menu. To fix that, you would need to boot the testing manjaro and then use a longer form of grub-install to specify a name such as manjaro2.
sudo grub-install --bootloader-id=manjaro2
Then you would have both manjaros at the setup boot menu and you could pick which grub menu to launch.

But in multi-boot setups, the distro which controls grub has to be updated when the kernels change in any of the distros! Otherwise, old entries persist.

1 Like

Thanks very much for this…great idea… What you say about the first has to be updated to reflect the status of the second is what I have found.

1 Like