[SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

BAK · 2015-02-07 05:01:04

I have Arch, openSUSE, and some other distributions installed on an EFI system, with each of the distributions' GRUBs installed in the EFI partition. I would like to use the GRUB bootloader provided by the openSUSE installation to boot all of the other distributions because it is themed very nicely. Unfortunately when booting Arch from the openSUSE GRUB entry there is a kernel panic. I think the problem is due to the openSUSE GRUB (version 2.02-beta2) only sees the intel-ucode image and not the intel-ucode image and the initramfs. (Compare the last line in each of the following code blocks)

The following is the openSUSE grub.cfg entry for Arch.

menuentry 'Arch (on /dev/sda25)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-963e8032-adb9-4abc-ac98-570a30f6f7bd' {
	insmod part_gpt 
	insmod ext2
	set root='hd0,gpt25'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt25 --hint-efi=hd0,gpt25 --hint-baremetal=ahci0,gpt25  963e8032-adb9-4abc-ac98-570a30f6f7bd
	else
	  search --no-floppy --fs-uuid --set=root 963e8032-adb9-4abc-ac98-570a30f6f7bd
	fi
	linuxefi /boot/vmlinuz-linux root=UUID=963e8032-adb9-4abc-ac98-570a30f6f7bd rw resume=/dev/disk/by-uuid/69bb9b40-aedd-4278-ac57-0113a7dc816f splash=silent quiet showopts video.use_native_backlight=1
	initrdefi /boot/intel-ucode.img
}

The following is Arch's grub.cfg entry in its own grub.cfg.

menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-963e8032-adb9-4abc-ac98-570a30f6f7bd' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt 
	insmod ext2
	set root='hd0,gpt25'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt25 --hint-efi=hd0,gpt25 --hint-baremetal=ahci0,gpt25  963e8032-adb9-4abc-ac98-570a30f6f7bd
	else
	  search --no-floppy --fs-uuid --set=root 963e8032-adb9-4abc-ac98-570a30f6f7bd
	fi
	echo	'Loading Linux linux ...'
	linux	/boot/vmlinuz-linux root=UUID=963e8032-adb9-4abc-ac98-570a30f6f7bd rw  resume=/dev/disk/by-uuid/69bb9b40-aedd-4278-ac57-0113a7dc816f splash=silent quiet showopts video.use_native_backlight=1
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux.img
}

I can do one of the following:

either edit the openSUSE grub.cfg entry for arch to include the intiramfs, but the comments in the grub.cfg files say not to edit the file
add a manual entry for Arch in /etc/grub.d, but I'd like something automatic, and I'm not sure how to do this
try to find an updated package in openSUSE like Arch's grub 2.02-beta2-5
wait for the openSUSE update and continue to use Arch's GRUB
add the intel-ucode.img to the FILE list in /etc/mkinitcpio.conf, I'm not sure if this will work

I think the last option will be best, if I understand what the purpose of the FILE list in /etc/mkinitcpio.conf does. I would appreciate any suggestions on how to resolve this.

Last edited by BAK (2016-02-04 23:29:15)

ewaller · 2015-02-07 05:10:06

I would edit the file (bullet 1). If that works, then I would look on the SUSE side and see if you can figure out how to make it support "other" distributions (That might be bullet 2, but I don't know either).

The only problem with editing the file is that will be overwritten when SUSE updates grub.

BAK · 2015-02-07 05:37:22

Thank you for your response.

Until their version of GRUB can handle the ucode image in addition to the regular initramfs, I think I will edit the grub.cfg file and update it when necessary.

What if I just uninstall the intel-ucode package from my Arch installation, delete the intel-ucode.img and update GRUB in openSUSE. The performance loss because of the missing ucode will be insignificant, I assume.

openSUSE's GRUB does actually support other distributions. It boots all of the other distributions installed on this machine, including Manjaro (which doesn't have the ucode image because I didn't know to install it) . It just doesn't in Arch's case because it is the only one that has two components to load during the initramfs loading stage, the intel-ucode.img and the initramfs-linux.img.

shulamy · 2015-02-07 10:20:23

i would try os-prober on suse

and check if it change arch entry in suse grub

ezik

random-nick · 2015-02-07 11:04:34

Can't you just copy over the theme to Arch's GRUB?

Salkay · 2015-05-27 23:39:17

Same problem with Ubuntu's grub. Has anyone reported this grub bug upstream?

Last edited by Salkay (2015-05-28 00:52:24)

Lone_Wolf · 2015-05-28 14:13:03

What if I just uninstall the intel-ucode package from my Arch installation, delete the intel-ucode.img and update GRUB in openSUSE. The performance loss because of the missing ucode will be insignificant, I assume.

On broadwell / haswell intel processors not applying the microcode update may result in unstable systems, see http://www.anandtech.com/show/8376/inte … broadwelly .

For systems running kernels prior to 3.17, early loading is not needed.

BAK · 2016-02-04 23:05:06

The issue, briefly, is that openSUSE's GRUB implementation only tries to load only the microcode image as if it was the actual initramfs instead of both the microcode image and the initramfs image as Arch does .

initrdefi /boot/intel-ucode.img

vs.

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

My solution is to manually edit openSUSE's /etc/boot/grub2/grub.cfg file genrated by grub2-mkconfig to include both images as ewaller originally suggested in the first reply.

initrdefi	/boot/intel-ucode.img /boot/initramfs-linux.img

See this for more on this.

This issue can be marked solved.

Last edited by BAK (2016-02-04 23:16:02)

ewaller · 2016-02-04 23:12:37

I am glad you got it working

BAK wrote:

My solution is to manually edit openSUSE's /etc/boot/grub2/grub.cfg file genrated by grub2-mkconfig to include both images.

I think I said that just about one year ago.

This issue can be marked solved.

We leave that to you. Just edit your first post in the thread -- there is an option to edit the thread name. Just prepend [SOLVED]. You may need to truncate the title a little to get it to fit.

2ManyDogs · 2016-02-04 23:13:40

The "correct" way to add a custom entry to grub.cfg is to add it to /etc/grub.d/40_custom. grub-mkconfig should pick this up and add it to grub.cfg, even when suse updates grub.

See the "GNU/Linux menu entry" section of the wiki topic: https://wiki.archlinux.org/index.php/GR … b-mkconfig

BAK · 2016-02-04 23:27:35

ewaller wrote:

I am glad you got it working
BAK wrote:
My solution is to manually edit openSUSE's /etc/boot/grub2/grub.cfg file genrated by grub2-mkconfig to include both images.
I think I said that just about one year ago.
This issue can be marked solved.
We leave that to you. Just edit your first post in the thread -- there is an option to edit the thread name. Just prepend [SOLVED]. You may need to truncate the title a little to get it to fit.

I actually had it working a long time ago. I actually edit the grub.cfg entries for all of the other distributions except Ubuntu for other reasons. I just started to think about it lately because of a review of Manjaro I read that because of the reviewer's lack of understanding of the way Arch deals with the microcode image, may give the impression that it is the distribution's fault.

BAK · 2016-02-04 23:36:14

2ManyDogs wrote:

The "correct" way to add a custom entry to grub.cfg is to add it to /etc/grub.d/40_custom. grub-mkconfig should pick this up and add it to grub.cfg, even when suse updates grub.
See the "GNU/Linux menu entry" section of the wiki topic: https://wiki.archlinux.org/index.php/GR … b-mkconfig

Yes, I thought as much, but since the other method solved my problem, I didn't act on this. But, won't using /etc/grub.d/40_custom result in multiple entries, ones generated by /etc/grub.d/30_os-prober and from /etc/grub.d/40_custom?

2ManyDogs · 2016-02-04 23:51:08

I always disable os-prober and just use custom entries in 40_custom. grub updates run much faster if os-prober doesn't run. I have several machines with multiple distros on them, and have one distro (usually Debian) controlling grub. Most distros don't change the name of the kernel and initramfs when they are updated, so running os-prober for each update is not necessary. This method works for me, but it is only one option. Editing grub.cfg is fine, but remember you will lose your changes if suse runs grub-mkconfig during an update.

Last edited by 2ManyDogs (2016-02-04 23:53:37)

michis · 2016-02-05 01:06:03

Just to mention another possible solution...

For my multiboot setup I have one small separat boot partition with only grub installed. The grub in the MBR points to that partition.
Each disrtibution is installed to its own partition with grub (or other boorloader) installed to that partition and NOT in the MBR.

Then you can chainload all the other bootladers from the bootpartition's grub.
This way you don't have to care about which distribution controls the grub in the MBR and if any updates regenerate grub.cfg

The boot partition is NOT mounted in any distribution.

Last edited by michis (2016-02-05 01:12:28)

Arch Linux

#1 2015-02-07 05:01:04

[SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#2 2015-02-07 05:10:06

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#3 2015-02-07 05:37:22

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#4 2015-02-07 10:20:23

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#5 2015-02-07 11:04:34

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#6 2015-05-27 23:39:17

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#7 2015-05-28 14:13:03

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#8 2016-02-04 23:05:06

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#9 2016-02-04 23:12:37

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#10 2016-02-04 23:13:40

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#11 2016-02-04 23:27:35

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#12 2016-02-04 23:36:14

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#13 2016-02-04 23:51:08

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

#14 2016-02-05 01:06:03

Re: [SOLVED] Booting Arch Using Another Distribution's GRUB Fails w/ KP

Board footer