Arch Linux Boot Mistake?

My main system is running Endeavouros/Xfce perfect, here on this pc I have Arch/Xfce(nvme) & used a spare ssd and decided to install Arch/Cinnamon using the Archfi script all went well…kind of lol. Now I can’t boot into my main drive witch is my nvme with Arch/Xfce, but it boots to my spare ssd with Arch/Cinnamon lol. Even if i go to the bios and select the intel nvme and boot all i get is a black screen, then i have to go back into the bios to set it to boot to my ssd. Weird thing is on boot screen it does give me a choice of what i want to boot to. Both versions of Arch have os-prober installed, I’m sure I goofed up somewhere. :crazy_face:

The mistake is not yours - it exists in Grub2 and os-prober. Basically it allows grub to make an entry that tries to load microcode instead of the initramfs file! There are a number of ways to fix it - or avoid it - but the simplest fix should be:

  1. choose the fallback entry for EndeavourOS
  2. once you’re in, in a terminal do
sudo grub-mkconfig -o /boot/grub/grub.cfg

which should rebuild your EndeavourOS grub to recognize and boot the others OK. Leave EndeavourOS in charge of booting, and all is well. EOS has incorporated a fix for this problem.

If EOS ‘loses control’, it is usually easy to find a boot order selection in your BIOS to give control back.

More info (and alternatives) available on request :grin:

EndeavourOS is on a totally separate computer(Main pc) from this one, this one only has Arch/Xfce(nvme) & Arch/Cinnamon(ssd) :smiley:

Would a: sudo grub-mkconfig -o /boot/grub/grub.cfg Still work?

Not likely to fix things, if EOS is not there. OK - couple of possibilities for a quick fix. First off, the boot to fallback will work for getting in. Once there, you can edit the /boot/grub/grub.cfg file for a quick fix. It will NOT stay fixed, though, as any grub update will overwrite it.

There will be an entry like this in in the grub.cfg file:

	menuentry 'Arch Linux (on /dev/nvme0n1p5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-linux--b46c18cf-fa73-4255-b1b0-920904264e6b' {
		insmod part_gpt
		insmod ext2
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root  b46c18cf-fa73-4255-b1b0-920904264e6b
		else
		  search --no-floppy --fs-uuid --set=root b46c18cf-fa73-4255-b1b0-920904264e6b
		fi
		linux /boot/vmlinuz-linux root=UUID=b46c18cf-fa73-4255-b1b0-920904264e6b rw loglevel=3 quiet
		initrd /boot/amd-ucode.img 
	}

The last text line is the problem causing the failure to boot. it should read:

		initrd /boot/amd-ucode.img /boot/initramfs-linux.img

so if you make it so, it should work.
How you make it remain so, is more problematic. There are ways, but few are them are simple to explain! One that is simpler is to avoid grub entirely, and replace it with a boot manager called rEFInd. I did a wiki on it here at EndeavourOS:


which explains its use for multi-boot.

Interesting that Arch can create its own grub correctly, but not recognize that even other Arch entries need the same thing!

Blockquote### BEGIN /etc/grub.d/10_linux ###
menuentry ‘Arch Linux’ --class arch --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-simple-65cdaeb5-0816-4be5-b4b8-99fd7a4d6879’ {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 10CE-55ED
else
search --no-floppy --fs-uuid --set=root 10CE-55ED
fi
echo ‘Loading Linux linux …’
linux /vmlinuz-linux root=UUID=65cdaeb5-0816-4be5-b4b8-99fd7a4d6879 rw loglevel=3 quiet
echo ‘Loading initial ramdisk …’
initrd /amd-ucode.img /initramfs-linux.img
}
submenu ‘Advanced options for Arch Linux’ $menuentry_id_option ‘gnulinux-advanced-65cdaeb5-0816-4be5-b4b8-99fd7a4d6879’ {
menuentry ‘Arch Linux, with Linux linux’ --class arch --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-linux-advanced-65cdaeb5-0816-4be5-b4b8-99fd7a4d6879’ {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 10CE-55ED
else
search --no-floppy --fs-uuid --set=root 10CE-55ED
fi
echo ‘Loading Linux linux …’
linux /vmlinuz-linux root=UUID=65cdaeb5-0816-4be5-b4b8-99fd7a4d6879 rw loglevel=3 quiet
echo ‘Loading initial ramdisk …’
initrd /amd-ucode.img /initramfs-linux.img
}
menuentry ‘Arch Linux, with Linux linux (fallback initramfs)’ --class arch --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-linux-fallback-65cdaeb5-0816-4be5-b4b8-99fd7a4d6879’ {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 10CE-55ED
else
search --no-floppy --fs-uuid --set=root 10CE-55ED
fi
echo ‘Loading Linux linux …’
linux /vmlinuz-linux root=UUID=65cdaeb5-0816-4be5-b4b8-99fd7a4d6879 rw loglevel=3 quiet
echo ‘Loading initial ramdisk …’
initrd /initramfs-linux-fallback.img
}
}

END /etc/grub.d/10_linux

Blockquote

Heres mine, I’m going to change the last line like you said and see what happens lol.

Watch out for one thing - it looks your system runs from / not from /boot - and the entries are relative to that! Match the call to /amd-ucode.img with /initramfs-linux.img and all should be OK.

1 Like

That worked, thanks!

The simplest way to fix it is to use systemd-boot and not grub. I’ve returned to systemd-boot from grub and I feel free again!

1 Like

Can that be done without a re-install? :nerd_face: :smiley:

Yes it can. I am not sure that it simplifies anything though, as it requires quite a lot of configuration. In particular, to enable multi-boot you must ensure that it is not set up to boot from the esp. As mentioned before, rEFInd is a good way to go for easy multi-boots, that rarely require any actions on arrival of new kernels, or on any updates other than to itself. System-d boot (following on from Gummiboot) seems to be as ‘clean’ as it gets though.

1 Like

Ok question for you freebird54, I reinstalled Arch/Cinnamon & I’m getting ready to add EndeavourOS to my other ssd. Should i install rEFInd now or wait till after i add EndeavourOS to that ssd?
Thanks!

It doesn’t actually matter much - even 1 install should pick up whatever is bootable that you have. If you install it in the current system, it should pick it up automatically. When you first boot after installing a new ‘distro’, however, your system will probably come up with the new grub instance. To get rEFInd back (so to speak), you may need to pop into BIOS on boot to set boot priority back to rEFInd. If you wait to install it until AFTER the distros are all in, rEFInd will probably have control from then on (until another install of a distro). Hopefully you followed all that!

It may sound a little confused, but what happens on a rEFInd install is that a few pieces are put into the main system (/usr/share/refind) and some are put into the esp. The parts in the esp are usable, if you will, by all the systems using it. The only other thing it does is put refind-linux.conf alongside your bootable kernel file (for EndeavourOS it’s in /boot). refind-linux.conf gives boot options a place to live for each distro. A read through the wiki will give you more if you want it :grin:

The main thing I like is that very little has to be set up, and even less needs to be changed as you go along - and no black screen or kernel panic boots like grub!

1 Like

I waited for your reply before i did anything, going to do the EndeavourOS install later this afternoon.

Thank you!

Yoicks! It better work :grin: - I guess we’d better make sure of that…

1 Like