What to do when one of your installations goes missing on a multi-boot BIOS system

Posted 10-14-2015 at 01:06 PM by donatom
Updated 10-14-2015 at 01:26 PM by donatom

I have several multiboot systems (Arch, Fedora, Mint, Ubuntu, etc.). On each I have chosen to make Fedora the "master" distro; that is the distro that controls grub. On occasion, after a system upgrade when Fedora updates the kernel, I "lose" one of my installations -- usually Arch Linux. What I mean by "lose" is that the distro is still on the grub menu but when chosen, booting fails.

Why does this happen? Well, when Fedora updates the grub configuration (grub.cfg), it changes the UUID for my Arch root partition. I am not sure why this is so, but it does happen.

The fix is quite simple. I run:

Code:

 # blkid

to find the correct UUID for the partition of the "lost" installation.

This is what I get:

Code:

 # blkid /dev/sda5
/dev/sda5: LABEL="arch-rt" UUID="f93f9318-9b9a-4751-bc14-e50b3b69f117" TYPE="ext4" PARTUUID="0006deba-05"

I used the /dev/sda5 with the blkid command so that I wouldn't be presented with all the UUID's for all the partitions on my drive.

I then open the /etc/grub2/grub.cfg in my Fedora installation and look for the menuentry for the missing installation. I then examine all the UUID's to make sure they correspond to the UUID I got from the blkid command. I then copy and paste the correct UUID (you have to do this in several places).

This is what output for my /etc/grub2/grub.cfg looks like (after scrolling down to the Arch menuentry):

Code:

 menuentry 'Arch Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-ad4103fa-d940-47ca-8506-301d8071d467' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  ad4103fa-d940-47ca-8506-301d8071d467
	else
	  search --no-floppy --fs-uuid --set=root ad4103fa-d940-47ca-8506-301d8071d467
	fi
	echo	'Loading Linux core repo kernel ...'
	linux	/boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 rw  quiet
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initramfs-linux.img

You will notice that the UUID for this installation is not correct, so you would have to paste the correct UUID in several (4) different places.

You would then save the corrected grub.cfg. You can now restart and try to boot the "missing" installation.

I have had to do this on several systems. Fedora is not the only distro that can change the UUID; I have had the same experience with Debian.

Recently I had this happen to two of my installations: ubuntu 14.04 and Arch Linux. I tried running

Code:

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

which updates the grub.cfg file in Fedora. After this I was able to boot ubuntu, but Arch remained unbootable. By the way, you use

Code:

 update-grub

in Debian to update the grub.cfg file.

If you would like to change the "master" installation to another one, you would run

Code:

 install-grub /dev/sda

when running the installation that you want to make "master" of grub. You probably would also want to run "grub2-mkconfig -o /boot/grub2/grub.cfg" for Fedora or "update-grub" for a Debian-type installation. On Debian or Debian-like distros you find the grub.cfg file by navigating to /etc/grub/grub.cfg.

The above information is obviously for BIOS boot systems but quite possibly would work on UEFI boot systems.

Posted in Uncategorized

Views 1895 Comments 2

« Prev Main Next »

Total Comments 2

Comments

	Thanks for this post! I found it quite informative...the only thing was you didn't say where the partitions that one would have to edit are...I think that would be the final touch tho. Thanks for posting, Nbiser
	Posted 10-14-2015 at 04:20 PM by Nbiser

Where are the problematic partitions?

Let's say your Ubuntu installation won't boot after your "master" installation (Fedora, etc) installs a new kernel. The master installation will automatically update grub and sometimes the new grub.cfg has an erroneous UUID.

You are going to make changes in the master installation's grub.cfg. In order to know what partition is being affected by the faulty grub.cfg, you would run gparted and look for the partition that contains Ubuntu. I place labels on each of my installations which makes this much easier. To label your installation right-click on the partition in gparted and write a description like Ubuntu14.04-Root.

You don't, however, need to know the partition number to make corrections. You can compare the out put of blkid to the grub.cfg on the master installation.

Here is the output of blkid (you don't have to designate a partition; it will show UUID's for every partition on your hard drive):

Code:

[root@arch Desktop]# blkid
/dev/sda1: UUID="c94da9f3-4c31-432c-8864-38dfa57ad11e" TYPE="ext4" PARTUUID="0006deba-01"
/dev/sda5: LABEL="arch-rt" UUID="f93f9318-9b9a-4751-bc14-e50b3b69f117" TYPE="ext4" PARTUUID="0006deba-05"
/dev/sda6: LABEL="ArchHome" UUID="fa0c4003-2000-4ce0-aba0-d6bf8728c451" TYPE="ext4" PARTUUID="0006deba-06"
/dev/sda7: LABEL="FedoraHome" UUID="4dc82f48-586e-4f63-9d30-6cfb59a3ce2d" TYPE="ext4" PARTUUID="0006deba-07"
/dev/sda8: UUID="3c424b0d-6273-4f73-b066-9a95f513d640" TYPE="swap" PARTUUID="0006deba-08"
/dev/sda9: LABEL="FedoraRoot" UUID="893c917a-9277-4927-82c4-62a296edf65b" TYPE="ext4" PARTUUID="0006deba-09"
/dev/sda10: UUID="1d572792-ec58-48c9-8430-1cf20db80b53" TYPE="ext4" PARTUUID="0006deba-0a"

Hope this clarifies things.

Posted 10-15-2015 at 06:08 PM by donatom donatom is offline