If you have Arch Linux installed and install openSUSE, the ability to boot into Arch Linux leads to no where unless you insert the missing part.
Here is what the Arch Linux entry looks like:
menuentry 'Arch Linux (rolling) (on /dev/sdc6)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-bbca28b2-503e-4dc8-9850-c54bd0492da8' {
insmod part_gpt
insmod fat
set root='hd2,gpt1'
if x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1 688D-126B
else
search --no-floppy --fs-uuid --set=root 688D-126B
fi
linuxefi /vmlinuz-linux root=UUID=bbca28b2-503e-4dc8-9850-c54bd0492da8 rw quiet
initrdefi /intel-ucode.img
}
This is what is should look like:
menuentry 'Arch Linux (rolling) (on /dev/sdc6)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-bbca28b2-503e-4dc8-9850-c54bd0492da8' {
insmod part_gpt
insmod fat
set root='hd2,gpt1'
if x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1 688D-126B
else
search --no-floppy --fs-uuid --set=root 688D-126B
fi
linuxefi /vmlinuz-linux root=UUID=bbca28b2-503e-4dc8-9850-c54bd0492da8 rw quiet
initrdefi /intel-ucode.img /initramfs-linux.img
}
If I have grub on openSUSE, I have to press ‘e’ and edit that line to insert the red part or it will not boot into Arch.
I opened this bug hoping that others that are affected can add their name to it. https://bugzilla.opensuse.org/show_bug.cgi?id=1101942
You can use YaST’s bootloader module to make the addition persistent. And please file a bug report. I know some Arch + openSUSE users, sure openSUSE controls GRUB, haven’t heard any of them, except for them hardly using Arch anymore
This is known problem. os-prober does not handle multi-file inited well, and fixing it turned out not so straightforward. Bug is there, it just needs someone to do the actual coning …
Thanks, I’ll try that. Actually, the last system that installs grub or even updates grub is in control of grub. I like to multi boot several systems and when another system besides Arch updates grub, I boot into Arch, either entering the missing part or using the fallback kernel and re-install grub on Arch.
I am starting to really like openSUSE Tumbleweed but, I really like Arch Linux too. They are both rolling releases with cutting edge technology
Several years ago I, along with the help of a couple others wrote a How To in the Ubuntu Forum about customizing grub on Legacy/MBR partitioned systems. That evolved into a Wiki. It works quite well and is being used by lots of people.
Just a hint here. You can install Leap or Tumbleweed without any bootloader, then boot Arch and rebuild its GRUB from there so that it recognizes the other system just installed.
The Leap/TW installer should complain that “The installed system might be impossible to boot”, just ignore it.
Please be aware that the version of GRUB packaged with other distros (I don’t know about Arch actually) might not recognize a BTRFS filesystem the way openSUSE uses it, so it might be better to use ext4 for the / (root) partition. But if you are currently using the Arch GRUB to boot openSUSE you should have discovered that already.
No, it won’t work (as long as other systems are using the same grub2/os-prober combination). os-prober gets bootloader entries from other system’s bootloader configuration. If other sytsem does not have bootloader, os-prober will not be able to reference it.
What is needed in this case is grub2 that is not installed on disk (this is what “grub2-install --no-bootsector|no-nvram” do depending on platform). This will continue to maintain grub.cfg used by os-prober to extract bootloader entries but will not install bootloader itself. I think it was mentioned as possible future feature but I may be wrong.
Maybe this is what the openSUSE installer does when you edit the installation summary and tick “Do not install bootloader”. When doing so to test a beta or TW snapshot I find that grub.cfg is installed but the bootloader is still under control of my main install (usually a stable Leap) and can be rebuilt from there. Apparently the GRUB2 package itself is installed and configured but the actual bootloader is not written to disk, but I’m not smart enough to check the installer code to confirm that.
I do not know; I’d expect it to not install anything. What “grep LOADER /etc/sysconfig/bootloader” says?
On legacy BIOS it is possible to select grub2 and uncheck all Boot Loader Location in “Boot Code Options” tab; in this case code that calls grub2-install is skipped. It won’t work on EFI though.
I also fired up the Leap 15 installer (without actually committing to disk) and even with “Bootloader not managed” and the usual warnings in red the GRUB packages were still selected for install, including grub2-x86_64-efi.
To be honest, the last time I tried that “trick” the main install controlling the bootloader was Leap 42.3 and the test install without a bootloader was an Ubuntu one; I don’t know if something has changed with the “big rewrite” of YaST code.
Whatever you were looking for has been wiped by two recent “clean installs”. On the next beta install in an UEFI system I will pay close attention to the details and file a bug report if needed.
My feeling is that editing the Boot summary in the installer to “Bootloader not managed” still installs files but the EFI boot priorities are not touched, so that on the next reboot you still find your “old” EFI entry at the first place and your “old” GRUB menu on the screen.
But, as said, I cannot prove that at the moment: readers of this thread are warned, anyway.
As best I recall, I see “Do not install bootloader” rather than “Bootloader not managed”. But that probably has to do with the translation.
Yes, my understand is that if I select “Do not install bootloader”, then the packages for “grub2”, “grub2-efi” and “shim” will still be installed. However, the commands “grub2-install” and/or “shim-install” will not be run.
Presumably the point of not installing a bootloader, is that you want to install that manually yourself with different command line options. So you still need the packages to be installed.
Actually installation without bootloader is intended for containers where you do not need bootloader at all. I’d rather suspect some dependency pulls it in.
Found out, in case this wasn’t already known, that this problem is only on EFI systems. I have a 9 year old PC that does not have this problem. It lacks the /intel-ucode.img part of the kernel line.
I got Tumbleweed installed on it after much time as it’s very slow and many headaches, dead ends, etc. It kept getting an error "error no such device: (a UUID was listed) and the grub-rescue prompt after that.
I tried every solution that fixed other problems that were exactly the same and nothing changed. Thought I lost it but after fighting for nearly 2 days and with a Windows recovery DVD in the drive it booted into openSUSE finally when I told the BIOS to boot from the HD and I was able to recover the PC.
So, this problem with Arch Linux and EFI systems is prevalent across all Debian distros, openSUSE and I’m sure there are others I have not tried.
It would be nice if it gets fixed though, which is my hope.
Could you tell me how to make the addition persistent? I don’t find any setting to edit that.
Also, when I manually add ‘/boot/intel-ucode.img’ (the part missing) at boot, I get the error that the file is not found.
I successfully booted Arch before with openSUSE grub, but I used the ‘40_custom’ file, and doing the same, adding that missing part to the generated entries. Why it doesn’t find the img?
It’s the first time I install Linux (Arch) on the extended partition. It’s a Bios system, bootloader installed in dev/sda. Does it mean I can’t boot Arch from the extended partition?
