Make maintaining GRUB easier for multi-booters, a "How To."

[oshunluvr]

This is a followup to this thread about Chainloading GRUBs as a concept. I had considered (and tried) a stand-alone GRUB partition as the solution, but after working through it and a suggestion from Vinny (thanks again Vin, great idea!), I think this is the best approach.

This idea is for multi-boot users - meaning you boot from one install to another often enough that you'd like it to be a little easier.

For the purposes of this post, I will call the install you use to maintain the GRUB that you boot to the "Host-OS" and all other installs "Sub-OS." I will not explain how to use sudo to get this done. If you don't know how to complete these tasks, you likely shouldn't be doing this anyway.

The problem: As noted in the above linked thread - is when you update a kernel in one a Sub-OS, you have to reboot into your Host-OS to update your GRUB menu so you can then again reboot into your updated Sub-OS. This can be a PITA if you have many (I have 6) and you get kernel updates regularly. Here's how you can cut back on the reboots considerably:

For each Sub-OS:

When you install each of these, do not allow GRUB to be installed to the Master Boot Record (/dev/sda). Instead, point each Sub-OS GRUB install at it's Partition Boot Record (/dev/sdXY - where X equals the drive letter and Y equals the partition number). All Ubuntu derivatives should allow you to select this option if you select the Manual Partitioning option during install. For other distros, search out how to do this before running the installer.

Edit the /etc/default/grub file and add this line:

GRUB_DISABLE_OS_PROBER=true

This will leave only the Sub-OS's kernels in it's menu and has the added benefit of update-grub completing much faster.

OPTIONAL: If you don't want to see the Sub-OS menu at all, edit GRUB_TIMEOUT=10 to GRUB_TIMEOUT=0. The menu should not appear unless there was a failed boot on the previous attempt. If you opt to allow the Sub-OS menu to appear, you can return to the Host-OS grub menu by pressing ESC prior to the boot starting. A good compromise is to set GRUB_TIMEOUT to 1 or 2 thus allowing 1 or 2 seconds to hit ESC.

Once your edits are complete, run update-grub to create your menu. Repeat the above for each subsequent Sub-OS install.

For Windows, you have to let it do it's thing and then re-install GRUB from a linux distro. There are 100's of post on the web cover that topic.
If you've already installed everything and want to "upgrade" using this post, not to worry. Continue here and then read "Relocating GRUB" below.

Your Host-OS:

Install and allow GRUB to install to /dev/sda.

Edit the /etc/default/grub file and add this line:

GRUB_DISABLE_OS_PROBER=true

Add a chainload/configfile stanza for each Sub-OS.

Edit your /etc/grub.d/40_custom and add one of these stanzas for each Sub-OS depending on their type:

For each Sub-OS that uses GRUB2:

menuentry 'MENU_ENTRY' {
set root='(hdX,msdosX)'
configfile /boot/grub/grub.cfg
}

Substitute whatever name you want for MENU_ENTRY. This is what will appear in your Host-OS grub menu. You can name the OS, like "BackTrack 5" or "Ubuntu with Unity" or use something more general like "Drive 2 Partition 2"

Replace the "X" in hdX and "msdosX" with the drive number of the partition containing the target grub.cfg file. Remember GRUB counts drives from 0 but partitions from 1. So the second drive is "hd1" but the second partition is "msdos2."

Note the path to the grub.cfg file. If you use a separate /boot partition, this needs to be /grub/grub.cfg as /boot is the mount point rather than a folder.

You can use a "search --set root" entry instead of the "set root=" but it's more verbose and I can't see a reason why it's better unless you're in the habit of moving drives around.

For Sub-OS's that use other boot loaders (GRUB-legacy, Windows, syslinux):

menuentry 'GRUB1 MENU_ENTRY' {
set root='(hdX,msdosX)'
chainloader +1
}

You may also need to add the insmod command for some other file system types like btrfs or ntfs:

menuentry 'Windows 7' {
insmod ntfs
set root='(hdX,msdosX)'
chainloader +1
}

NOTE: I don't have access to Windows 7 or GRUB1. Someone please test and verify the correct entry.

The stanzas will appear in the menu in the order you put them into 40_custom.

Run update-grub and when you reboot, you should have a nice clean menu and the ability to boot to every other partition you set up.

The end results:
When you start up, you will see your Host-OS kernels and a list of the other boot-able partitions, labeled the way you want. When you select a Sub-OS that uses GRUB2, you will get a second menu (or not if you opted out of it) and your kernel options. When you update a kernel in a Sub-OS, you will only need to reboot once to access the new kernel.

***TAKE NOTE*** Since GRUB is being hosted by the Host-OS, if you decide to wipe this install you will have to re-do the above entries. I suggest making a backup copy of 40_custom somewhere not with the Host-OS install. This will make the edits much easier down the road.

Neat Tip: Each Sub-OS will display it's own GRUB2 menu setup when you link to it. A cool addition is to use unique backgrounds for each install.Then you get an obvious visual cue as to which OS you're about to launch.

Tip #2: Add USB Booting From GRUB.

Relocating GRUB

If you've already installed everything and want to switch over to a single main grub in this way or you want to change the Host-OS on your existing setup - the fix is only a few steps away!

1. Boot into the new Host-OS
2. Do all the edits outlined above
3. Install grub from the new Host-OS to the MBR: grub-install /dev/sda
4. Update grub to create your new configfile: update-grub
5. Reboot.

Please review this post and note any errors or confusing parts. If you try it with success, post that too!.

[vinnywright]

nice job with the how to @oshunluvr

just adding that "for me" the

menuentry 'MENU_ENTRY' {
set root='(hdX,msdosX)'
configfile /boot/grub/grub.cfg
}

had to be

menuentry 'MENU_ENTRY' {
set root=hdX,msdosX
configfile /boot/grub/grub.cfg
}

dont know why,,,,,maby I had a space at root='( and grub would not load the line but when I changed it to, set root=hdX ,it worked ........go figure ?

VINNY

O and thanks for the acknowledgement

[jlittle]

You can use a "search --set root" entry instead of the "set root=" but it's more verbose and I can't see a reason why it's better unless you're in the habit of moving drives around.

If you have lots of distros and partitions, I'd have thought you'd be manipulating (resizing, deleting, adding) partitions, which can easily change the device numbering, in which case you'd be glad of the search approach.

Regards, John

[oshunluvr]

@Vinny: That's odd. When I get a chance I'll see if you way works with my system or not.

@Jlittle: I mentioned it for that very reason, but as for myself, I have not re-partitioned in years. I have 3 hard drives plus an SSD. I initially created the space for 3 distros on the HD's and when I added the SSD recently I made room on it for three more. I learned a while back to take time to plan partitioning well and do it once.

I may be doing some re-partitioning soon however, as my hard drives are well past their expected life and one of them has started kicking errors out through s.m.a.r.t.

[oshunluvr]

@Vinny: Interesting that both entries work equally well for me.

Note for BTRFS users:

The grub.cfg file is reachable with:

insmod gzio
insmod btrfs
set root=hdX,msdosX
configfile /@/boot/grub/grub.cfg

or

set root=hdX

if you have the whole drive in use with BTRFS.

[vinnywright]

@Vinny: Interesting that both entries work equally well for me.

well that would seem to confirm that in my frenzied haste to achieve this glorious result I most likely inserted some offending white space in my line
:cool:

VINNY