Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Multi-booting with a standalone GRUB partition

Share your HowTo, Documentation, Tips and Tricks. Not for support questions!.
Post Reply
Message
Author
User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Multi-booting with a standalone GRUB partition

#1 Post by Head_on_a_Stick »

Multi-booting various GNU/Linux distributions (and other operating systems) can be troublesome because of the varying options that need to be applied to the bootloader.

For example, Arch-based distributions on Intel x86 hardware will add two options to the initrd line (to load the CPU µcode before the initramfs) but this is not recognised by Debian's `grub-mkconfig` script and will cause any Arch-based menu entries to fail:

http://forums.debian.net/viewtopic.php?f=10&t=139060

As a solution to this issue, it is possible to install GRUB's modules and configuration file to a (very) small standalone partition and use that to load all the other distributions on the disk.

The upstream guide is here: https://www.gnu.org/software/grub/manua ... ual-config

As noted in that guide, it is important to make sure that the bootloader is disabled if any new distributions are installed, the MBR or NVRAM boot entry must always point to the standalone partition and installing another bootloader to the disk will break this.

It is also necessary to disable `os-prober` in all of the installed distributions by editing /etc/default/grub and changing the GRUB_DISABLE_OS_PROBER line to true then running `update-grub` to change the configuration.

Create the standalone partition first, it needs to be on a primary partition if an msdos ("MBR" style) partition table is used, I find that 32MiB is plenty.

Once created, format the partition, I prefer xfs:

Code: Select all

mkfs.xfs /dev/sdXY
^ Replace X & Y with the drive letter and partition number for the new partition.

For installing the bootloader itself, I prefer to use the Arch ISO image but it can be done from any GNU/Linux system that is already installed on the drive.

First, mount the partition and create a boot directory:

Code: Select all

mount /dev/sdXY /mnt
mkdir -p /mnt/boot
Then install the bootloader, this is for non-UEFI systems (Arch requires a `--target=i386-pc` flag as well):

Code: Select all

grub-install --boot-directory=/mnt/boot /dev/sdX
For UEFI systems mount the EFI system partition first:

Code: Select all

mkdir /esp # delete this afterwards
mount /dev/sdXZ /esp # replace X & Z with the drive letter and partition number
Then direct GRUB to that location (again, for Arch add `--target=x86_64-efi`):

Code: Select all

grub-install --efi-directory=/esp --boot-directory=/mnt/boot /dev/sdX
Finally we need to write the configuration file to /mnt/boot/grub/grub.cfg, here is an example for Debian, Arch & OpenBSD:

Code: Select all

menuentry 'OpenBSD' {
   search --set=root --UUID $uuid_openbsd --hint hd0,msdos1
   chainloader +1
}

menuentry 'Debian' {
   search --set=root --UUID $uuid_debian --hint hd0,msdos2
   linux /vmlinuz ro root=UUID=$uuid_debian
   initrd /initrd.img
}

menuentry 'Arch' {
   search --set=root --UUID $uuid_arch --hint hd0,msdos3
   linux /boot/vmlinuz-linux rw root=UUID=$uuid_arch
   initrd /boot/intel-ucode.img /boot/initramfs-linux.img
}
^ In this example an msdos disk is used with GRUB in it's own 32MiB partition assigned to /dev/sda4

For disks with a GUID partition table, use the hd0,gpt1 (&c) nomenclature.

Replace $uuid_{arch,debian,openbsd} with the correct UUIDs for the respective partitions.

This technique allows the user to freely delete any operating systems on the disk without fear of breaking the bootloader, which can be very useful, and it also mitigates against post-upgrade bootloader failure (because we won't be updating the bootloader, ever).

If the MBR or NVRAM entry gets overwritten and the custom menu stops loading then mount the partition and run the `grub-install` command again to wrest back control.

For troublesome UEFI implementations try adding the `--removable` flag to the `grub-install` command.
Last edited by Head_on_a_Stick on 2018-12-31 21:58, edited 2 times in total.
deadbang

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Multi-booting with a standalone GRUB partition

#2 Post by p.H »

May I comment on this ? I disagree on multiple points.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Multi-booting with a standalone GRUB partition

#3 Post by Head_on_a_Stick »

p.H wrote:May I comment on this ?
Please do, I was hoping for your feedback.
p.H wrote:I disagree on multiple points.
Uh-oh :(

I don't have a UEFI system atm, did I get that wrong?
deadbang

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Multi-booting with a standalone GRUB partition

#4 Post by p.H »

Head_on_a_Stick wrote:As a solution to this issue, it is possible to install GRUB's modules and configuration file to a (very) small standalone partition
A much simpler solution to this issue is to add custom entries to the "main" system's GRUB menu instead of relying on os-prober and grub-mkconfig/update-grub.
IMO, the major benefit of a standalong GRUB is that it is independent from any of the installed systems. So it won't stop working when you delete the system it belongs to.
Head_on_a_Stick wrote:it is important to make sure that the bootloader is disabled if any new distributions are installed
Or make sure the bootloader is not installed in the MBR (for BIOS boot). For EFI boot, I am afraid that no distribution allows to prevent grub-install to updating EFI boot variables (with --no-nvram).
Head_on_a_Stick wrote:Create the standalone partition first, it needs to be on a primary partition if an msdos ("MBR" style) partition table is used
It does not have to be a primary partition, it can be a logical partition. However I advise against using a logical partition because logical partition numbers can change, and GRUB's core image relies on the partition number to find the partition containing the grub/ directory.
Head_on_a_Stick wrote:format the partition, I prefer xfs
Why xfs ? I would have expected a simpler filesystem type such as ext2, commonly used for the /boot partition.
Head_on_a_Stick wrote:First, mount the partition and create a boot directory
You do not need to create a /boot directory. You can install GRUB at the root of the filesystem with --boot-directory=/mnt.
Head_on_a_Stick wrote:Each menuentry will load the configuration file from the selected system
This is actually the most important point. It assumes that all installed system generate a config file which is compatible with the standalone GRUB version. If you disable GRUB when installing a system, the config file may not even exist.

On Debian, if you select "do not install a boot loader", the installer will not install grub-* packages nor create grub.cfg. You can install grub2-common manually in order to be able to run grub-mkconfig or update-grub and create grub.cfg. But grub.cfg won't be automatically updated after a kernel change because the scripts doing this are in the grub-$arch packages which also install the GRUB boot loader, such as grub-pc (for BIOS) or grub-efi-am64 (for 64-bit UEFI).

If you want automatic grub.cfg update, you have to either extract the update scripts from a grub-$arch package by hand or install the package and make sure it does not install a boot loader. grub-pc will ask where to install the boot loader, so you can leave an empty field. But grub-efi-amd64 will not ask anything and try to install the boot loader and update EFI boot entries. There are a number of tricks to prevent the boot loader installation such as unmounting the EFI partition, or installing a grub-$arch package intended for a different target (e.g. grub-pc on a UEFI target) but these are hackish at best.
Head_on_a_Stick wrote:For disks with a GUID partition table, use the hd0,gpt1 (&c) nomenclature.
For BIOS boot, I also advise to create a 100-kB to 1-MB unformatted "BIOS boot" partition at the beginning of the disk. grub-install will use it to install GRUB BIOS' core image.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Multi-booting with a standalone GRUB partition

#5 Post by Head_on_a_Stick »

^ Thanks!
p.H wrote:
Head_on_a_Stick wrote:As a solution to this issue, it is possible to install GRUB's modules and configuration file to a (very) small standalone partition
A much simpler solution to this issue is to add custom entries to the "main" system's GRUB menu instead of relying on os-prober and grub-mkconfig/update-grub
I have noticed that many posters are confused as to which operating system is controlling the bootloader at any given time so the pertinent question then becomes to which distribution should the custom entry be added – a standalone partition solely for GRUB would make it clear where the relevant configuration file is.
p.H wrote:For EFI boot, I am afraid that no distribution allows to prevent grub-install to updating EFI boot variables (with --no-nvram).
Good point.

In that case the `grub-install` command would have to be run after any fresh UEFI installation, which is irritating.
p.H wrote:
Head_on_a_Stick wrote:format the partition, I prefer xfs
Why xfs ?
The choice of filesystem isn't really that important, just don't use FAT :)
p.H wrote:
Head_on_a_Stick wrote:First, mount the partition and create a boot directory
You do not need to create a /boot directory. You can install GRUB at the root of the filesystem with --boot-directory=/mnt.
Yes but that would be weird :)
p.H wrote:
Head_on_a_Stick wrote:Each menuentry will load the configuration file from the selected system
This is actually the most important point. It assumes that all installed system generate a config file which is compatible with the standalone GRUB version. If you disable GRUB when installing a system, the config file may not even exist.

On Debian, if you select "do not install a boot loader", the installer will not install grub-* packages nor create grub.cfg. You can install grub2-common manually in order to be able to run grub-mkconfig or update-grub and create grub.cfg. But grub.cfg won't be automatically updated after a kernel change because the scripts doing this are in the grub-$arch packages which also install the GRUB boot loader, such as grub-pc (for BIOS) or grub-efi-am64 (for 64-bit UEFI).

If you want automatic grub.cfg update, you have to either extract the update scripts from a grub-$arch package by hand or install the package and make sure it does not install a boot loader. grub-pc will ask where to install the boot loader, so you can leave an empty field. But grub-efi-amd64 will not ask anything and try to install the boot loader and update EFI boot entries. There are a number of tricks to prevent the boot loader installation such as unmounting the EFI partition, or installing a grub-$arch package intended for a different target (e.g. grub-pc on a UEFI target) but these are hackish at best.
I didn't think about that at all, thank you very much for bringing it up.

I've changed the OP to point the Debian entry to the kernel & initrd symlinks in the root partition instead, they should continue working even after kernel upgrades.

Looks like my guide is a bit crap now but nevermind...
p.H wrote:
Head_on_a_Stick wrote:For disks with a GUID partition table, use the hd0,gpt1 (&c) nomenclature.
For BIOS boot, I also advise to create a 100-kB to 1-MB unformatted "BIOS boot" partition at the beginning of the disk. grub-install will use it to install GRUB BIOS' core image.
Yes, I suppose, GUID partition tables are great if the non-UEFI firmware supports them.
deadbang

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Multi-booting with a standalone GRUB partition

#6 Post by p.H »

Head_on_a_Stick wrote:The choice of filesystem isn't really that important, just don't use FAT
Why not FAT ? It is simple and supported by GRUB. I think I have installed a standalone GRUB on a FAT-formatted USB pendrive.
Head_on_a_Stick wrote:
You do not need to create a /boot directory. You can install GRUB at the root of the filesystem with --boot-directory=/mnt.
Yes but that would be weird
Why ? This is the same as on a separate /boot partition. Think of your GRUB partition as a standalone boot partition.
Head_on_a_Stick wrote:I've changed the OP to point the Debian entry to the kernel & initrd symlinks in the root partition instead, they should continue working even after kernel upgrades.
Actually I'd rather tweak the installed systems to automatically generate their own grub.cfg, because each system knows best how to create its own menu entries, set proper kernel parameters (root, resume, splash...) and so on. It is not that hard. Also, writing menu entries may not be straightforward in some situations, for example if the system uses LVM, RAID or LUKS.

Even in simple cases, menu entries generated by grub-mkconfig contain insmod commands to load support modules for the partition table and filesystem type. I am not sure it is really required, but better be on the safe side.
Head_on_a_Stick wrote:Yes, I suppose, GUID partition tables are great if the non-UEFI firmware supports them.
Except the need to set the boot flag in the protective MBR with some BIOS firmwares, I never had any trouble booting a GPT disk in BIOS mode.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Multi-booting with a standalone GRUB partition

#7 Post by Head_on_a_Stick »

p.H wrote:Why not FAT ?
Because it's prehistoric and prone to rot.

Anyway these are all just details, feel free to adapt the guide to your own particular needs ;)
deadbang

Post Reply