Announcement

Collapse
No announcement yet.

HOW TO create and use a dedicated GRUB partition.

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

    HOW TO create and use a dedicated GRUB partition.

    Multi-booting, new installs, updates, removing old installs - all of these events can delete or damage your GRUB and thus your ability to boot. One solution is to separate GRUB completely from an install so it "lives" on it's own so no one installation can remove or damage it.

    GRUB exists in two locations - it resides on your boot device in an area unused by your partitions and also has files within the Linux installation that installed it. It's the second part - these files - which are mostly at risk. If you remove the install that "owns" grub, you remove the files that grub needs to boot.

    If you are or plan on installing more than one Linux distro, preventing the removal of grub is easy to do and manage. I will not discuss installing GRUB initially. This how-to assumes you have already installed GRUB at least once and are able to boot to your system.

    This is a moderately advanced operation. If you are not comfortable recovering an unbootable system and re-installing grub, I do not recommend you attempt this. Sometimes things go wrong. You should be able to fix a non-booting GRUB installation by yourself before trying something this advanced. This how-to is primarily useful for multi-booting Linux installs.

    Step 1: prepare a partition for GRUB.
    A dedicated GRUB partition only needs a dozen or so megabytes. The minimum partition size if you're using the Partition Manager is 8MB. I recommend at least 24MB (that's MEGAbytes not gigabytes) and using EXT2 as the file system format. EXT3/4 have journaling which is not necessary for this usage. My GRUB partition has 14MB of used space because I also have memtest on the GRUB partition. Without memtest, you'll use about 6MB. If you are worried about GRUB getting larger in the future, you could go larger, to say 64MB. It is just megabytes after all. You'll hardly notice the used bytes.

    Create and format this partition to EXT2 using your preferred tools.

    For the example commands in this how-to, I will use sda1 as the GRUB partition and sda as the boot drive. Obviously, use the device names of your boot drive and new GRUB partition as you follow these steps.

    Step 2: Mount the GRUB partition.
    Make a mount point for the GRUB partition and mount it:

    sudo mkdir /mnt/grub
    sudo mount /dev/sda1 /mnt/grub


    Step 3: Copy GRUB to the new partition.

    From the install you are currently booting from, install GRUB to the new partition.

    sudo grub-install --root-directory=/mnt/grub /dev/sda

    This command does two things:
    1) It modifies the boot record of sda to look in /dev/sda1 for grub's files.
    2) It copies the files grub needs to boot to /dev/sda1 (/mnt/grub) in the proper directory structure.

    If you do a file listing of /mnt/grub right now, you will see the GRUB files are there with one very large exception: There is no grub.cfg file. If you rebooted right now, your boot would fail. This is OK because we are going to create a custom grug.cfg manually. Other files you may have added to customize your GRUB look - background images,fonts, or themes are also not copied be the above command. You'll have to copy those manually if you want to continue using those.

    Step 4: Make a custom grub.cfg
    One thing that grub does for you is update its grub.cfg each time you update your kernel. We don't want to lose this functionality. Also, some distros use different setting for the construction of grub.cfg. We don't want to lose that either. We preserve these things by allowing each install to retain it's own grub.cfg and then set up our dedicated grub to link to those files. This results a nested grub menu. When you first boot you will see the menu from your manually created grub.cfg. When you select on of the entries, you will now see the grub.cfg from the selected installation. Another real advantage to this method is if you initially select the wrong menu item from your custom grub.cfg menu, hitting the "ESC" key before the boot process begins will return you to back to your custom menu.

    To create your first custom grub.cfg we will use your current grub.cfg and modify it. Use your favorite editor if you don't like Kate.

    kate /boot/grub/grub.cfg

    Now delete everything after the line:

    ### BEGIN /etc/grub.d/10_linux ###

    and add this menu stanza:
    Code:
    menuentry 'Kubuntu 16.04' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@Kubuntu_16_04/boot/grub/grub.cfg
    }
    Let me break down each line because there are some important things to note in the above;


    Code:
    menuentry 'Kubuntu 16.04' {
    This first line is title or name that you will see in your initial grub menu. Use whatever you would like to see between the quotes.


    Code:
    insmod part_gpt
    This indicates that I'm using a GPT partition table. If you're using MBR on this drive, use "part_msdos" instead of "part_gpt


    Code:
    insmod btrfs
    This indicates that i'm using the BTRFS file system with this particular install. If you're using something else you'll need to change it. For example EXT4 would need "ext4" is place of "btrfs".


    Code:
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    This is the UUID of the file system I want to boot to. Change this to reflect yours.


    Code:
    configfile /@Kubuntu_16_04/boot/grub/grub.cfg
     }
    Finally, this is the location of the installation grub.cfg that I'm going to link to. I use BTRFS so the subvolume name is in there as well. This should reflect your installation's grub.cfg full path from the root of the installation. If you are using EXT4 it should look like this:
    Code:
    configfile /boot/grub/grub.cfg.
    Don't forget the bracket - it signals the end of the stanza (the opening bracket in at the end of the menuentry line.

    You will need to repeat the above stanza for each installation you want to boot this way. I have six distros installed and bootable through this custom grub.cfg. As you add or delete Linux installs, you will need to return to this menu and manually edit the stanzas to reflect the changes you made.

    When you're all done, save the file as /mnt/grub/boot/grub/grub.cfg.


    On reboot, you should see your custom grub.cfg. When you select an entry, you should then see the grub entries from the selected distro. ESC will bring you back to your custom menu.

    Here's what mine looks like:
    Code:
    menuentry 'KDE Neon' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@KDEneon/boot/grub/grub.cfg
    }
    menuentry 'KDE Neon - new' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@KDEneon_new/boot/grub/grub.cfg
    }
    menuentry 'Kubuntu 16.04' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@Kubuntu_16_04/boot/grub/grub.cfg
    }
    menuentry 'Ubuntu 16.04' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@Ubuntu_16_04/boot/grub/grub.cfg
    }
    menuentry 'Manjaro free' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@Manjaro_free/boot/grub/grub.cfg
    }
    menuentry 'Manjaro nonfree' {
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        configfile /@Manjaro_nonfree/boot/grub/grub.cfg
    }
    menuentry 'Memory test (memtest86+)' {
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
        knetbsd /boot/memtest86+.elf
    }
    menuentry 'Memory test (memtest86+, serial console 115200)' {
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
        linux16 /boot/memtest86+.bin console=ttyS0,115200n8
    }
    menuentry 'KDEneon ISO' {
        set isofile="/neon-useredition-20170608-2351-amd64.iso"
        loopback loop (hd0,2)$isofile
        linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
        initrd (loop)/casper/initrd.lz
    }
    ### END Custom menu###

    Optional features:

    Memtest:
    I also copied the three memtest files:
    Code:
    memtest86+.bin
    memtest86+.elf  
    memtest86+_multiboot.bin
    from one of my installs to my grub partition under /boot. This allows me to run memtest from the first grub menu and also allows me to purge memtest from all my subsequent installs. I didn't see a need for six copies of memtest to be installed. Look at the bottom of your current grub.cfg or my custom one above to see how to add memtest to your custom grub.

    Booting an ISO from grub:

    Also note in my custom grub.cfg the last entry:
    Code:
    menuentry 'KDEneon ISO' {
        set isofile="/neon-useredition-20170608-2351-amd64.iso"
        loopback loop (hd0,2)$isofile
        linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
        initrd (loop)/casper/initrd.lz
    }
    With this I can boot directly to an ISO. Not all ISOs are bootable this way, but it's a neat feature if you want to try out a new distro on your hardware before you install it and don't want to make a liveUSB. The entry may vary for the ISO of your choice, but that for another thread.

    Default timeout and menu selection:
    To set the default distro to boot to, look for this near the top of your custom grub:
    set default="0"
    which will always boot the first menuentry in the list and you may not want that. By using the menuentry title in the quotes instead of a number, you will always boot to your choice regardless of the order of the stanzas in grub.cfg, so change it to
    set default="YOUR MENU ENTRY HERE"

    You obviously also need to see this first menu or you won't be able to select a non-default choice so make sure your custom grub.cfg has a suitable timeout setting.

    An important final note: As you install each new Linux distro, DON'T INSTALL GRUB TO SDA! This will remove Step 3 and prevent you from using the custom menu. Most installers will allow you to install grub to a partition instead of the drive. This is one way around this. If you have a second drive, just install grub to sdb instead of sda. This will allow you to continue to use your custom grub. If you forget or the installer won't allow you to avoid installing it's grub to sda, just redo Step 3 and you should be back in business.

    One interesting other thing to note; If you use only EXT4 and aren't in the habit of redoing your partitions, you could have a custom grub that never needed editing. Just use device names or labels in place of UUIDs to identify the partitions and use generic menu titles like 'Partition 4' as your menuentry.
    Last edited by oshunluvr; Feb 18, 2018, 10:54 AM.

    Please Read Me

    #2
    The above updates previous how-to's to the case of GRUB2--and especially the "new" menuentry syntax GRUB2 introduced (versus the GRUB Legacy). The key to any of this is bouncing off the governing configfile.
    This topic--Building a separate GRUB2 partition--has been covered here in Section 4 of this (older) how-to:

    GRUB 2 A Guide for Users
    https://www.kubuntuforums.net/showth...l=1#post193705

    Also, the above (Post #1) applies to the older non-UEFI systems. EFI introduces a new paradigm, where you already have a separate and dedicated partition for ALL boot loaders on your system, and including a main, governing configfile (that, however, does link to just one governing GRUB menu of the controlling OS for booting). I guess there could be a hybrid case where you have an EFI system but you are using CSM to boot not by the EFI-ESP but by GRUB2 and etc ...
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    Comment


      #3
      Qqmike: Thanks for chiming in and adding that. I went looking to see if a how-to already existed and I couldn't find one. Also, glad you brought up the EFI differences. I haven't had the need to use EFI so I haven't switched over or know anything about it.

      Seems to me that EFI booting is a necessity for new Windows install booting but an unnecessary layer of complication if you're not using Windows or some other OS that requires it. What's your opinion on this?
      Last edited by oshunluvr; Feb 24, 2018, 09:26 AM.

      Please Read Me

      Comment


        #4
        Seems to me that EFI booting is a necessity for new Windows install booting but an unnecessary layer of complication if you're not using Windows or some other OS that requires it. What's your opinion on this?
        I agree about Windows: better use the EFI. And dual-booting Windows with Linux, well, that's a crap-shoot but doable and best left to people who do those things and take a special interest in Windows (not me!). With Linux, there may still be people using the old GRUB Legacy, and if so, that's OK; or simply just use GRUB2 on an MBR setup--not using EFI. If your machine came with EFI, then Rod Smith addresses all the ways to circumvent the EFI, but it may lead to too much hassle (although doing the special BIOS Boot Partition, bios-grub, is no big deal and easy enough). With just Linux installed, any way that you can get your machine to boot properly is OK with me and seems to be OK with experts I've read.

        As for the separate GRUB partition, I wrote my how-to when GRUB 2 just came on, none of us liked GRUB 2, lots of GRUB Legacy how-to writers dropped out then, and GRUB 2 was just a PITA--something we felt we had to address because it was taking over the show. My how-to was tested (by me and others--probably dibl, MoonRise, et al at the time). I probably rigged up my how-to by hook or by crook just to make it work OK. I always had a dedicated GRUB partition on my machines. But nowadays, I'm simply using the EFI-ESP setup.

        --> Your how to (above, Post #1) is probably the best for new users nowadays--and you have recently tested it (mainly wrt to menuentry syntax, construction, and maintenance). Since you are staying on top of this subject and especially since you have used it with both ext4 and btrfs, I'd recommend that people use your how-to to build their dedicated GRUB partition.
        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

        Comment


          #5
          A note on an aspect of this subject:

          Can you still use GRUB Legacy? Well, Yes.
          But note what Arch Wiki says:

          Is it necessary to upgrade from GRUB Legacy to GRUB2?

          Is upgrading necessary?

          The short answer is No. GRUB legacy will not be removed from your system and will stay fully functional.

          However, as any other packages which are not supported anymore, bugs are unlikely to be fixed. So you should consider upgrading to GRUB version 2.x, or one of the other supported Boot loaders.

          GRUB legacy does not support GPT disks, Btrfs filesystem and UEFI firmwares.
          And if you do want to keep GRUB Legacy:

          Warning: GRUB Legacy is no longer maintained upstream and is not officially supported in Arch (see the news here). Users are recommended to switch to GRUB(2) or Syslinux instead. See Upgrading to GRUB2 ...
          Note: If you have grub-legacy installed as grub-0.97 pkg in your system, it will be updated to grub-2.xx pkg (GRUB2) during pkg updates. If you want to keep using grub-legacy install grub-legacyAUR so that pkgname does not conflict. During this update only the files in /usr/lib/grub/ are updated, and grub-legacy files installed to /boot/grub and the MBR are not removed. You can boot back into grub-legacy by simply renaming /boot/grub/menu.lst.pacsave to /boot/grub/menu.lst .
          https://wiki.archlinux.org/index.php/GRUB_Legacy

          So, at the least, one could or should use GRUB2, possibly even with EFI.
          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

          Comment


            #6
            Great post!
            I've decided that when 16.04 gets to EOL I am going to adopt your approach and reinstall using it.
            "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
            – John F. Kennedy, February 26, 1962.

            Comment


              #7
              Originally posted by Qqmike View Post
              A note on an aspect of this subject:

              Can you still use GRUB Legacy? Well, Yes.
              But note what Arch Wiki says:

              Is it necessary to upgrade from GRUB Legacy to GRUB2?



              And if you do want to keep GRUB Legacy:


              https://wiki.archlinux.org/index.php/GRUB_Legacy

              So, at the least, one could or should use GRUB2, possibly even with EFI.
              For the record; I'm not using nor do I advocate grub-legacy. I am also not using EFI or MBR (msdos) partitioning.

              I wrote a how-to awhile back on using GRUB2 with GPT. It's no more difficult to set up than using EFI and easier IMO - no EFI stuff to manage. Of course, I've not bothered to learn EFI booting so my opinion is of little value in that matter.

              Please Read Me

              Comment


                #8
                nor do I advocate grub-legacy.
                Nor do I recommend it, for the record. However, some die-hards do still use it (last time I did a lit survey of GRUB booting a few years ago). It is not now supported.

                I wrote a how-to awhile back on using GRUB2 with GPT. It's no more difficult to set up than using EFI and easier IMO - no EFI stuff to manage.
                Yes, and GRUB2 + GPT is now the usual way to go, agreed, along with all that stuff in your how-to (the special GRUB partition and such).

                no EFI stuff to manage.
                Ah ... no, the other way around: the EFI manages your booting stuff!
                An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                Comment

                Working...
                X