Announcement

Collapse
No announcement yet.

Making GRUB easier for a true multi-boot system -> CONCEPT

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Making GRUB easier for a true multi-boot system -> CONCEPT

    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.

    Please Read Me

    #2
    Sounds interesting. Of course, we all are more than willing to let you be the lab rat in this experiment!:eek:
    Windows no longer obstructs my view.
    Using Kubuntu Linux since March 23, 2007.
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes

    Comment


      #3
      " ... 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?"

      We used to do this exactly in GRUB legacy (my how to's showed how). But it was preferred to use configfile as it seemed "cleaner," slicker, and WOULD bring up each OS menu.lst (grub.cfg). However, at the time I wrote my GRUB2 GUIDE how-to (it's pinned sticky here at KFN), configfile wasn't working too good, and preferred by many people NOT to use it for such.

      Your chainload should work fine. Set the OS-partition labels using, e.g., live gparted CD, right?


      "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."

      Yes, necessary, of course--and not a bad idea to do in general, being prepared for rescue-booting (manually at the grub prompt) should the need arise.


      Now, just one thing. Rusty here, as I've only recently started using 12.04 (and still have my trusty 8.04.3 running on my 2nd PC at my desk) ... but I THOUGHT that when a new kernel is installed, the system (not sure where the call comes from) automatically issues a grub update and a new grub.cfg is generated. That is, no need for manual reboots to update the grub menu. I'm certain I read this somewhere?
      An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

      Comment


        #4
        Anything that simplifies, makes better and is somewhat easier to install/fix is good, Try it out. Need to show these boot partitions, how to do i.e. I myself still do not know how to make a seperate partition for /home (?). I don't want to destroy anything so haven't been able to do it. Keep up the good thoughts.
        Tabko-00 9-15

        Comment


          #5
          I discovered one thing in the new docs for GRUB 2.0 - They recommend setting GRUB to not install to any boot record and also to turn off the OS_PROBER function. Then, update-grub will not read the other partitions. I can see an advantage to allowing it to do that though - if you accidentally select the wrong OS you could directly go to any other. Another solution would be to add a return boot to the main grub install. Then it's only one extra step to any other install. However - both these functions would require a slight delay at the initial boot to display the menu.

          Likely, I will opt for the quickest - straight shot to each install and just trust I will select the correct option each time.

          Please Read Me

          Comment


            #6
            @Qqmike: Yes, grub-update is called automatically. The reboots in my first post are required to boot to the newly installed kernel after grub has been updated.

            Please Read Me

            Comment


              #7
              I'm writing the grub.cfg now but waiting for an rdiff-job to finish before rebooting to test. Likely won't be today since I'm heading outside in a bit for yard work.

              Please Read Me

              Comment


                #8
                "docs for GRUB 2.0 - They recommend setting GRUB to not install to any boot record..."

                You mean to any partition boot sector? If so, they had been saying that all along. However, I THOUGHT that advice could safely be overlooked; that is, for most applications, it would be safe enough to install GRUB to a partition boot sector.
                An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                Comment


                  #9
                  Originally posted by Qqmike View Post
                  "docs for GRUB 2.0 - They recommend setting GRUB to not install to any boot record..."

                  You mean to any partition boot sector? If so, they had been saying that all along. However, I THOUGHT that advice could safely be overlooked; that is, for most applications, it would be safe enough to install GRUB to a partition boot sector.
                  Actually, I think it's better to have it installed to the PBR - just in case something else fails you'd have a chance at booting to something.

                  Please Read Me

                  Comment


                    #10
                    Originally posted by Tabko-00 View Post
                    Anything that simplifies, makes better and is somewhat easier to install/fix is good, Try it out. Need to show these boot partitions, how to do i.e. I myself still do not know how to make a seperate partition for /home (?). I don't want to destroy anything so haven't been able to do it. Keep up the good thoughts.
                    Tabko-00 9-15
                    Unfortunately, the Ubuntu world has not made a separate /home migration utility. Mandriva used to have one, but I haven't used that distro in 4 years so I can't say if it does any longer. If you want help with how to move your /home, start a thread with the details of your current setup and we'll walk you through it.

                    Another solution is to leave /home where it is and move your data (Doc, pics, vids, etc.) to a separate data partition. You can then link to the new location or use bind mounts. It's really not hard. Linux was created to easily allow use of multiple devices for storage.

                    Please Read Me

                    Comment


                      #11
                      oshunluvr, OK, we are on the same page on everything up through your Post #9 -- I just read it all and caught up.
                      An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                      Comment


                        #12
                        Originally posted by Snowhog View Post
                        Sounds interesting. Of course, we all are more than willing to let you be the lab rat in this experiment!:eek:
                        Chicken!

                        Please Read Me

                        Comment


                          #13
                          Originally posted by oshunluvr View Post
                          Chicken!
                          Cluck, cluck.
                          Windows no longer obstructs my view.
                          Using Kubuntu Linux since March 23, 2007.
                          "It is a capital mistake to theorize before one has data." - Sherlock Holmes

                          Comment


                            #14
                            Yes, looks like I did this in
                            GRUB 2: A Guide for Users
                            http://www.kubuntuforums.net/showthr...uide-for-Users
                            Section 4, Special Topics
                            under these topics:
                            Boot menu: Making your own custom grub.cfg
                            4 ways to boot an OS: configfile, symlinks, direct booting, chainloader
                            Dedicated GRUB 2 partition: How to build it

                            And, therefore, I tested it very well (at the time), and it should work (though maybe menuentry formats/syntax are now different or more complicated).
                            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                            Comment


                              #15
                              Originally posted by Qqmike View Post
                              but I THOUGHT that when a new kernel is installed, the system (not sure where the call comes from) automatically issues a grub update and a new grub.cfg is generated. That is, no need for manual reboots to update the grub menu. I'm certain I read this somewhere?
                              .deb files contain, in addition to the bits to be installed, a series of scripts:

                              * preinst - run before installation
                              * postinst - run after installation
                              * prerm - run before removal
                              * postrm - run after removal

                              The postinst script for kernel images executes all files in /etc/kernel/postinst.d. One of these is zz-update-grub, which in trun calls the "real" update-grub under certain circumstances.

                              Comment

                              Working...
                              X