History:
I am a true multi-booter. That is to say, I have more than one OS (all currently linux, of course!
) that I boot to. I have my main OS - I call my "daily driver" and a few others for testing, backup, etc.
I have, in the past, maintained a separate GRUB partition. This becomes cumbersome because you have to manually edit the grub.conf to add or change kernels, etc. I considered writing a script that would automagically update the grub.cfg but I never got around to it. My situation is complicated slightly more by the fact that my old BIOS doesn't like booting to drives other than sda. It will, but it gets befuddled on drive letter assignment and this causes all kinds of shenanigans.
Currently, I use my daily driver (Kubuntu 12.04) as my GRUB maintainer and have just left GRUB within the install. It's no more or less work than a separate boot partition and unlikely that I'll delete my Kubuntu install anytime soon. If I do though - I'll have to reinstall GRUB again from somewhere else.
The Issue:
This week, I added a new SSD to my 'puter and installed 12.04 to it and had to go through the Install-reboot-update grub-reboot-update kernel-reboot-update grub-reboot thing and got real tired of it real fast. Here's the minimum steps required:
1. Install new drive and boot to USB drive to do new install.
2. When done, reboot computer to OS that is "hosting" GRUB. Run update-grub.
3. Reboot and select your now available new install.
4. Update the new install - oh look, new kernel.
5. Reboot to GRUB host again, run update-grub again.
6. Reboot to the new OS and start configuring.
7. Repeat ad nauseum.
So you see this quickly becomes tiresome. Multiply this by 3 or 4 Ubuntu based OS's which all get kernel updates the same day and well...
...you should be able to feel my pain by now.
The New Concept: A GRUB partition that needs no updating!
Earlier this week I commented on a thread re. GRUB chainloading and a light bulb appeared! What if I had a GRUB partition with a simple grub.cfg that had nothing in it except a chainload to each of my bootable OS's? GRUB uses a different method these days instead of the old "chainload" entry, but for ease of discussion - let's use the word chainload anyway.
The Set Up:
1. Install GRUB to a separate partition and to the MBR of drive sda.
2. Manually create a chainload stanza for every bootable partition on the system. In theory, you could just add them all. You should not use UUID's as they would change if you did a new install. I think I would use a menu entry name that made sense to me like "Kubuntu Backup", "Kubuntu 12.04", "BackTrak", "Testing" and so on for each OS rather than plain partition names. Set the default to my daily driver.
3. Here's the key part: Install GRUB from each OS to it's own partition PBR. Set the GRUB menu to not appear at all.
How it should work:
1. When you boot up, you see a list of your OS's.
2. Select the one you want. GRUB chainloads to the OS partition and chains to the GRUB there but no second menu appears.
3. While using any of the OS's, whenever you run update-grub, it automatically updates it's own GRUB and will always boot to the latest kernel. If you wiped out an install and installed a new OS, you would not have to update the GRUB partition as the chainloading would not be dependent on the kernel or OS on any given partition.
Basically this method should eliminate two-thirds of the reboots for updates. As an additional safety step, you could have a duplicate GRUB partition on another (or every) drive in case your main drive failed. IT uses less than 200MB so space isn't an issue. The only time you'd need to access the GRUB partition is when there was an update to grub that you wanted to install.
I will attempt this in the near future but I wanted to hear comments regarding the idea.
If it works well, I will turn this thread into a How-To if others are interested.
I am a true multi-booter. That is to say, I have more than one OS (all currently linux, of course!
) that I boot to. I have my main OS - I call my "daily driver" and a few others for testing, backup, etc.I have, in the past, maintained a separate GRUB partition. This becomes cumbersome because you have to manually edit the grub.conf to add or change kernels, etc. I considered writing a script that would automagically update the grub.cfg but I never got around to it. My situation is complicated slightly more by the fact that my old BIOS doesn't like booting to drives other than sda. It will, but it gets befuddled on drive letter assignment and this causes all kinds of shenanigans.
Currently, I use my daily driver (Kubuntu 12.04) as my GRUB maintainer and have just left GRUB within the install. It's no more or less work than a separate boot partition and unlikely that I'll delete my Kubuntu install anytime soon. If I do though - I'll have to reinstall GRUB again from somewhere else.
The Issue:
This week, I added a new SSD to my 'puter and installed 12.04 to it and had to go through the Install-reboot-update grub-reboot-update kernel-reboot-update grub-reboot thing and got real tired of it real fast. Here's the minimum steps required:
1. Install new drive and boot to USB drive to do new install.
2. When done, reboot computer to OS that is "hosting" GRUB. Run update-grub.
3. Reboot and select your now available new install.
4. Update the new install - oh look, new kernel.
5. Reboot to GRUB host again, run update-grub again.
6. Reboot to the new OS and start configuring.
7. Repeat ad nauseum.
So you see this quickly becomes tiresome. Multiply this by 3 or 4 Ubuntu based OS's which all get kernel updates the same day and well...
...you should be able to feel my pain by now.
The New Concept: A GRUB partition that needs no updating!
Earlier this week I commented on a thread re. GRUB chainloading and a light bulb appeared! What if I had a GRUB partition with a simple grub.cfg that had nothing in it except a chainload to each of my bootable OS's? GRUB uses a different method these days instead of the old "chainload" entry, but for ease of discussion - let's use the word chainload anyway.
The Set Up:
1. Install GRUB to a separate partition and to the MBR of drive sda.
2. Manually create a chainload stanza for every bootable partition on the system. In theory, you could just add them all. You should not use UUID's as they would change if you did a new install. I think I would use a menu entry name that made sense to me like "Kubuntu Backup", "Kubuntu 12.04", "BackTrak", "Testing" and so on for each OS rather than plain partition names. Set the default to my daily driver.
3. Here's the key part: Install GRUB from each OS to it's own partition PBR. Set the GRUB menu to not appear at all.
How it should work:
1. When you boot up, you see a list of your OS's.
2. Select the one you want. GRUB chainloads to the OS partition and chains to the GRUB there but no second menu appears.
3. While using any of the OS's, whenever you run update-grub, it automatically updates it's own GRUB and will always boot to the latest kernel. If you wiped out an install and installed a new OS, you would not have to update the GRUB partition as the chainloading would not be dependent on the kernel or OS on any given partition.
Basically this method should eliminate two-thirds of the reboots for updates. As an additional safety step, you could have a duplicate GRUB partition on another (or every) drive in case your main drive failed. IT uses less than 200MB so space isn't an issue. The only time you'd need to access the GRUB partition is when there was an update to grub that you wanted to install.
I will attempt this in the near future but I wanted to hear comments regarding the idea.
If it works well, I will turn this thread into a How-To if others are interested.
Comment