GRUB2

External resources

	Homepage

	Wikipedia

GRUB2 is a bootloader with support for many modern day computer systems. It is meant to replace the older GRUB bootloader (referred to as "GRUB Legacy"). GRUB2 has an entirely separate codebase from GRUB Legacy, and boasts features such as a new shell like syntax which permit advanced scripting capabilities. GRUB Legacy users are encouraged to migrate to GRUB2.

Upgrading to GRUB 2 might be necessary as it allows:

booting from UEFI platforms;
booting from GPT partitioned drives without even needing an awkward hybrid MBR, even though one can use one for compatibility/portability reasons;
booting from directly logical volume management such as LVM2 support;
booting from raid DM-RAID support for RAID [0?] 1, 4, 5, 6, 9 and 10 [or 1x?];
and booting from encrypted devices, probably LUKS, because of the inexistent documentation despite the cypher/hash modules being there: so no guidance on a howto for the moment.

For a shotgun approach, see instead GRUB2 Quick Start.

Installation

GRUB2 is currently masked in portage. An entry in package.accept_keywords is necessary to install it.

File/etc/portage/package.accept_keywords

sys-boot/grub:2

By default, GRUB2 will guess a default platform to target at build time. This may be overridden by setting the GRUB_PLATFORMS variable in make.conf.

File/etc/portage/make.conf

GRUB_PLATFORMS="emu gentoo_platforms_efi-32 gentoo_platforms_efi-64 pc"

The following platforms are supported depending on the target CPU.

	Target
Platform	i386	ia64	mips	mipsel	powerpc	spac64	x86_64
arc	No	No	No	Yes	No	No	No
coreboot	Yes	No	No	No	No	No	32-bit
efi	Yes	Yes	No	No	No	No	Yes
emu	Yes	Yes	Yes	Yes	Yes	Yes	Yes
ieee1275	Yes	No	No	No	Yes	Yes	32-bit
loongson	No	No	No	Yes	No	No	No
multiboot	Yes	No	No	No	No	No	32-bit
qemu	Yes	No	No	No	No	No	32-bit
qemu-mips	No	No	Yes	No	No	No	No
pc	Yes	No	No	No	No	No	32-bit

Install the package using the normal emerge syntax.

root # emerge --ask sys-boot/grub:2

Configuration

GRUB2 does not require you do manually maintain your boot options configuration, instead it generates the file(/boot/grub2/grub.cfg) using the command grub2-mkconfig. This utility will parse the scripts in /etc/grub.d and the settings file /etc/default/grub.

GRUB_FONT

Path to the PF2 font you want GRUB2 to use. To create a PF2 font, use the grub2-mkfont utility, example:

root #

grub2-mkfont /usr/share/fonts/droid/DroidSansMonoSlashed.ttf --size=20 --output /boot/grub2/fonts/DroidSansMonoSlashed20.pcf

and set GRUB_FONT=/boot/grub2/fonts/DroidSansMonoSlashed20.pcf

GRUB_DEFAULT

Default menu entry selected on boot. May be a numeric index, a menu title, or "saved". Defaults to first detected entry.

GRUB_TIMEOUT

Delay before booting default menu entry. Set to 0 to wait indefinitely. Default is 5 seconds.

GRUB_DISABLE_RECOVERY

If true, recovery menu entries will not be generated. On Linux, recovery entries pass "single" on the kernel command line.

GRUB_CMDLINE_LINUX

Parameters to be passed on the kernel command line for all Linux menu entries.

GRUB_CMDLINE_LINUX_DEFAULT

Parameters to be passed on the kernel command line for non-recovery Linux menu entries.

GRUB_DISABLE_LINUX_UUID

If true, ${GRUB_DEVICE} is passed in the root parameter on the kernel command line.

If false, ${GRUB_DEVICE_UUID} is passed in the root parameter on the kernel command line when an initramfs is available.

GRUB_GFXPAYLOAD_LINUX

Controls the video mode in which the Linux kernel starts. May be set to "text", "keep", or a display resolution.

GRUB_DEVICE

The initial root device, i.e. the kernel's root= parameter. Set this if you want to override grub2-mkconfig's root device auto-detection; for example, GRUB_DEVICE=/dev/ram0 will force root=/dev/ram0 to be used in your kernel command line.

The directory /etc/grub.d holds the scripts grub2-mkconfig uses to generate grub.cfg. The Out-of-the-box the content of this directory should be similar the following:

user $

ls /etc/grub.d/
00_header  10_linux  20_linux_xen  30_os-prober  40_custom  41_custom README

By default GRUB2 will use all scripts when first installed. If you want to disable any of them you only need to remove the executable bit. In the following example we disable everything but 00_header and 10_linux:

root # chmod -x /etc/grub.d/{20_linux_xen,30_os-prober,40_custom,41_custom}

When configured you run grub2-mkconfig with the -o argument pointing to the output file, which should usually be /boot/grub2/grub.cfg:

root #

grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...

Found linux image: /boot/vmlinuz-3.3.0-gentoo


done

This will (re)generate GRUB2 configuration. Note that if grub2-mkconfig doesn't report anything as found then nothing was, and GRUB2 will offer no boot selections.

BIOS/MBR or BIOS/GPT

Installing in this mode is straight forward as it's just like the legacy GRUB with new GRUB2 additions. If needed, start with mounting the /boot parition:

root # mount /boot

Run the grub2-install utility to copy the relevant files to /boot/grub2. On the PC platform, this also installs a boot image to the master boot record (MBR) or a partition's boot sector. grub2-install accepts a --target option to specify which CPU/Platform to install. If unspecified, grub2-install will make a guess; on amd64/x86 it will use "i386-pc" by default:

root #

grub2-install /dev/sda
Installation finished. No error reported.

UEFI/GPT

Before setting up UEFI boot, one has to partition the boot device with a GPT compatible disk tools like GPT fdisk or gdisk, parted or gparted (a gtk gui) or other tools that I did not bother to try at this point. It's advised to have something greater than 200MB and maybe smaller than 500MB for multi boot systems. GPT fdisk is a powerful tool that can be used to setup a few advanced settings like hybrid MBR or the number of alignment sectors. The default 2048 sectors (1MiB) is a sane default which will permit to make use of sector 34-2048 to embed GRUB2 core.img for example if one forgot to leave some space for BIOS boot partition.

Let's move to installing GRUB2 and setting up an EFI boot entry. I do not have an EFI board so EFI specifc boot steps are not tested!

First, create a filesystem and a mount point for the EFI partition with something like:

root #

mkdosfs -F 32 -n efi-boot /dev/sda1

root #

mkdir /boot/efi
root #

echo 'LABEL=efi-boot /boot/efi vfat defaults 0 2' >> /etc/fstab
root #

mount /boot/efi
root #

mkdir -p /boot/efi/{EFI/BOOT,GRUB2}

Note

Note that I use /boot/efi mount point assuming there's a traditional `/boot' mount point for BIOS boot, otherwise you can make use of `/boot' without the `/efi' sub-directory. The `-F 32' switch create FAT32 filesystem and `-n efi-boot' the LABEL of the filesystem. Adapt it to your needs.

And then install GRUB2 (x86 users should replace x86_64 by i386)

root # grub2-install --target=x86_64-efi --efi-directory=/boot/efi --boot-directory=/boot/efi

Note

Automated grub2-install (the command above) is quite adept and ready, BUT it relies on access to EFI variables, which basically means two things: 1) the kernel have to support them (the easy part) AND 2) the machine have to be already booted in UEFI mode. This "chicken and egg" problem can be overcome with the help of EFI boot capable usb flashdrive. [note: Booting the system from ('classically') MBR bootable flashdrive will not make EFI variables accessible, as well as 'modprobe efivars' alone (i.e. on system not already running in UEFI mode)]

USB EFI bootable flashdrive can be created with (assuming FAT formatted drive, mounted under /media/flashdrive)
root # grub2-install --target=x86_64-efi --efi-directory=/media/flashdrive --removable --modules=part_gpt
Kernel support: (re)compile kernel with CONFIG_EFI_VARS=y OR modprobe efivars. Copy kernel on /media/flashdrive/vmlinuz for convenience.
Reboot machine from the flashdrive in UEFI mode - motherboard/notebook manual should contain instructions on how to do this.
GRUB2 command line should appear. linux /vmlinuz root=/dev/sdaX [...add necessary parameters] [press ENTER] boot [press ENTER]
Look at /sys/firmware/efi/vars to see whether the EFI variables are accessible.
run grub2-install

[note: successful run of grub2-install does not ensure that the system will actually boot with GRUB2 after restart; it (just) installs the option to select GRUB2 bootloader from EFI (vendor) interface]

or install everything manually if something goes wrong.

root # cp -a /usr/lib/grub/x86_64-efi/* /boot/efi/GRUB2/

Note

To override the default boot loader, according to UEFI 2 specifications, one has to run the following command. This is handy when one cannot add an EFI boot entry as the utility will fails if `/sys/firmware/efi/vars/' is not empty meaning that you have to boot in EFI mode to be able to have a non empty directroy.

root # cp /boot/efi/GRUB2/grub.efi /boot/EFI/BOOT/BOOTX64.EFI

Note

According to UEFI 2 specifications, the default bootloader location is `[EFI System Partition]\EFI\BOOT\BOOTx64.EFI' for 64bit systems (and `[EFI System Partition]\EFI\BOOT\BOOTIA32.EFI' for 32bit systems).

With this configuration grub.cfg must be saved in /boot/efi/grub2, instead of /boot/grub2, thus

root # grub2-mkconfig -o /boot/efi/grub2/grub.cfg

It might be necessary to build a customized core.img with a few builtin modules to be safe or to satisfy specific requirements.

root # grub2-mkimage -p /grub2 -o /boot/efi/GRUB2/grub.efi -O x86_64-efi ext2 fat lvm part_msdos part_gpt search_fs_uuid normal

Before any attempt to add a menu entry to EFI boot menu, inserting EFI module and merge the utility is necessary.

root #

modprobe efivars

root #

echo 'sys-boot/efibootmgr **' >> /etc/portage/package.accept_keywords

root # emerge --ask sys-boot/efibootmgr

And then add an boot menu entry.

root # efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "GRUB2" --loader "\\EFI\\GRUB2\\grub.efi"

Hybrid GPT/MBR

Multi booting OSs that aren't aware of GPT partitioned disk, e.g. Windows 7 or Windows XP for those who still use that thing--that's because MSDOS/Windows cannot boot from anything else than BIOS/MBR aside from MSDOS/Windows 7 and possibly 8 from EFI platforms,--require this tricky workaround. The thing to keep in mind is that playing with a hybrid MBR can be tricky so, nothing in this sub-section should be taken as solid rock working but rather simply guidances to experiment to get something working.

First off, GRUB2 should boot and should recognize a partition table be it GPT or MBR simply by loading the associated module (part_gpt or part_msdos). So it should be expected to be able to boot on BIOS/MBR or BIOS/GPT depending on GRUB2 loaded module? Nothing is further from the truth, because, the previous sections outlined the differences between installing GRUB2 on BIOS/MBR and BIOS/GPT. I don't know how grub2-install behave when trying to install in BIOS/MBR mode with an EF02 (or bios_boot in parted terms) partition because I did not simply try it.

Actually there's simple thing that would determine grub2-install to install in BIOS/MBR or BIOS/GPT: it's the presence of a EE00 (GPT protective) and being the first partition in the MBR with that. With a hybrid MBR, GRUB2 will install just fine if and only if the first partition in the MBR table is an EE00 partition. An EF02 partition should be present anywhere in the disk and not necessarily in the MBR list to leave a few room to embed core.img in the disk tough.

Note

In this case one do not have to add/list an EE00 partition in the hybrid MBR list manually, gdisk will prompt you to list one first if booting with GRUB2 before listing the provided list (up to 3 partition) by the user.

Creating a hybrid MBR is easy with gdisk: just hit `r' (recovery and transformation) in the main, then hit `h' (CHS recompute) in that menu, and then enter a series of partition (less or equal to 3) in the order you want it to be listed in the MBR, and then enter the hexadecimal partition type without the `0x' prefix or accept the default with hitting repeatedly with `Y', and enable only a single boot flag as the following example.

root #

gdisk /dev/sdg
GPT fdisk (gdisk) version 0.8.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 2

root #

gdisk /dev/sdg
...
Using GPT and creating fresh protective MBR.

Command (? for help): r
Recovery/transformation command (? for help): p
Disk /dev/sdg: 625142448 sectors, 298.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 744E8BF3-39A4-4908-8646-AC2E5661C8CF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 625142414
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       566233087   270.0 GiB   8300  Linux filesystem
   2       566233088       625142414   28.1 GiB    0700  Microsoft basic data
Recovery/transformation command (? for help): h

WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 2 1
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): N


Creating entry for GPT partition #2 (MBR partition #1)
Enter an MBR hex code (default 07): 
Set the bootable flag? (Y/N): Y

Creating entry for GPT partition #1 (MBR partition #2)
Enter an MBR hex code (default 83): 
...
Unused partition space(s) found. Use one to protect more partitions? (Y/N): N

Recovery/transformation command (? for help): o

Disk size is 625142448 sectors (298.1 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1      *      566233088    625142414   primary     0x07
   2                  2048    566233087   primary     0x83
   4                     1         2047   primary     0xEE


Recovery/transformation command (? for help): w

And then check out if the operation was successful or not by listing the devices.

Note

I answered most safe questions to `N' because without that `/fdisk -l /dev/sdg' will list the MBR partion list just fine but listing the block devices with a `ls /dev' wouldn't list the partions and more annoying: the partions wouldn't be listed in DOS/BIOS.

Note

I had to manually remove the EE00 (GPT protective) partition in the MBR list for that drive with fdisk, because fdisk listed that partition as being the third one. And I couldn't get the BIOS/DOS recognize the partition table with its presence. This is quite weird (as the previous output shows) because the MBR partition table was correctly recognized when the hybrid MBR was freshly created. I had to reload GPT partition table from a file and re-hybridize the MBR a second time after a few experiments.

And finally install GRUB as usual. Everything should be fine at this point. See troubleshooting section for possible issues not listed on the previous Notes and comments.

Chainloading

There's a truly improved chainload mode compared to GRUB LEGACY: the new iso (or loop) chainload mechanism. Actually, one could still chainload iso images with GRUB LEGACY, and I did, but there were no way to pass kernel cmdline arguments. In either case, the iso image in question should have been built with that in mind like SysRescueCd or on a lesser extend Gentoo liveCD, otherwise booting will just fail badly in the physical media check/test. Gentoo liveCD is handy because it has a minimal shell which let mount the squashed image to the right place and then hit ESC to continue the boot process. That's a handy way to install an OS with everything in RAM, especially for such light liveCD, without listening to a whining drive on each command.

ISO images

To chainload an iso with custom or defaults kernel cmdline arguments, something like the following can be easily added:

Code

menuentry "SYSRESCUECD" {
	loopback loop /sysrecuecd-x86-2.3.1.iso
	linux  (loop)/isolinux/rescue64 nomodeset vga=791 docache setkmap=fr isoloop=/sysrecuecd-x86-2.3.1.iso
	initrd (loop)/isolinux/initram.igz
}

For a permanent and automatic entry to grub.cfg, a custum file could be added to `/etc/grub.d'.

File/etc/grub.d/50_isofile

#!/bin/sh
exec tail -n +3 $0

menuentry "GRUB4DOS" {
	linux /grub4dos-0.4.4/grub.exe --config-file=/menu.lst
}

menuentry "SYSRESCUECD" {
	loopback loop /sysrecuecd-x86-2.3.1.iso
	linux  (loop)/isolinux/rescue64 nomodeset vga=791 docache setkmap=fr isoloop=/sysrecuecd-x86-2.3.1.iso
	initrd (loop)/isolinux/initram.igz
}

menuentry "STG3-AMD64" {
	set cmdline="dokeymap looptype=squashfs loop=/image.squashfs cdroot"
	loopback loop /stg3-amd64-<DATE>.iso
	linux  (loop)/isolinux/gentoo $cmdline root=/dev/ram0 init=/linuxrc initrd=gentoo.igz
	initrd (loop)/isolinux/gentoo.igz
}

Make the script executable:

root # chmod +x /etc/grub.d/50_isofile

And lastly regenerate your grub.cfg with grub2-mkconfig.

Another Bootloader

Chainloading other bootloader is fairly easy if there's support in GRUB2 for that specific bootloader. Otherwise, one could use a man in the middle or another bootloader in other words to do the task if necessary. In the latter case, one could use GRUB4DOS as it has functionalities similar to GRUB LEGACY. This is required when loading another bootloader like TrueCrypt become problematic in a single multiboot disk, otherwise something as simple as the following is enough to boot another disk with whatever bootloader.

Code

menuentry "WHATEVER" {
     insmod part_msdos
     insmod chain
     chainloader (hd1,1)+1
}

TrueCrypt

Well, let's make a long story short: GRUB2 cannot neither chainload a disk with TrueCrypt in the MBR neither the rescue CD image. This is perfectly possible, feasible and works just fine with GRUB LEGACY. It even works with GRUB4DOS! This could be used as workaround. See bug #385619 for more info and the above GRUB4DOS menu entry as a starting point. The infamous `invalid signature' await the more adventurous ones.

Simply put, one should stick to GRUB LEGACY or to another bootloader or else... use GRUB4DOS as workaround for this. GRUB4DOS has a very similar GRUB LEGACY interface and menu.lst entry which can be used to chainload TrueCrypt bootloader or rescue CD to boot from an encrypted partition. An executable with grldr in the `/' root of the booting device is required, plus a menu.lst. See below for a menu entry example. Chainloading TrueCrypt bootloader in another disk is straightforward like any other bootloader.

Code

title Windows7-TrueCrypt-BIOS/MBR
find --set-root /truecrypt_rescue_image.iso
map --mem /truecrypt_rescue_image.iso (hd32)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd32)
chainloader (hd32)

Note

The remapping may not be necessary for you if you have a single boot disk system. The mapping are necessary before chainlading TrueCrypt bootloader in that case because the boot disk (here hd1) should appear as the primary boot device (hd0) otherwise TrueCrypt would just fail to boot because... it did not find the right disk.

Another workaround cited on the bug is to boot from TrueCrypt as the main boot loader and then hit ESC[ape] to chainload the following partition if any or the following disk.

MSDOS/Windows

If MSDOS/Windows is in another disk with its bootloader in the MBR, then one can boot with a simple menu entry as the previous example in Chainloading other bootloader section.

Things could become more complicated if MSDOS/Windows is in another partition of the disk and the partition is encrypted with TrueCrypt for example, or simply if a hybrid MBR is involved.

The simplest way to dual boot MSDOS/Windows is using BIOS/MBR combination. Simply backup the whole MBR to be safe or simply the bootloader before installing MSDOS/Windows as that thing will overwrite the bootloader for sure. And then simple menu entry could added to grub.cfg.

Code

menuentry "Windows 7 BIOS/MBR" {
     insmod part_msdos
     insmod ntldr
     insmod ntfs
     ntldr (hd0,msdos1)/bootmgr
}

Or the following for MSDOS/Windows XP

Code

menuentry "Windows XP BIOS/MBR" {
     insmod part_msdos
     insmod ntldr
     insmod ntfs
     ntldr (hd0,msdos1)/ntldr
}

An entry with GPT/hybrid MBR doesn't not to the list to the previous usual BIOS/MBR examples. Booting multiple MSDOS/Windows could be achieved with remapping and/hiding partion with partool.

Code

menuentry "Windows 7 BIOS/MBR" {
     insmod part_msdos
     insmod chain
     parttool hd1,msdos1 hidden+ boot-
     parttool hd1,msdos2 hidden- boot+
     chainloader (hd1,msdos2)+1
}

Note

Remapping the disk with parttoll in that manner is only required if multiple MSDOS/Windows systems are installed on the same boot device. Oterwise, remapping the devices to set the primary boot disk to another disk could be achieved with something as the following example.

Code

menuentry "Windows 7 BIOS/MBR" {
     insmod part_msdos
     insmod chain
     drivemap hd0 hd1
     chainloader (hd1,msdos2)+1
}

An UEFI dual boot could be achieved with the following, if, for example, the default bootloader was overwritten with GRUB2 or simply that bootmgr doesn't do the trick for different reasons.

Code

menuentry "Windows 7 UEFI/GPT" {
    insmod part_gpt
    insmod search_fs_uuid
    insmod chain
    search --fs-uuid --no-floppy --set{{=}}root 28cf-35de
    chainloader ($root)/EFI/MICROSOFT/BOOT/bootmgfw.efi
}

Extended features

Enabling resume swap for suspend

Open up /etc/default/grub with root privileges and add

Code

GRUB_CMDLINE_LINUX="resume=/dev/sdXY"

Where XY is the swap partition location, which can be found by

root # fdisk -l

It looks like you are using UUID instead and that's fine. /etc/default/grub only affects the current operating system so don't worry about every linux OS using grub to start using that swap. After finishing your edits, run

root # grub2-mkconfig -o /boot/grub2/grub.cfg

(substitute grub.cfg with whatever file grub reads at boot, e.g. it may be named /boot/grub/grub.efi) to update your grub startup information with what you changed in /etc/default/grub.

Chroot

If you have a separate /boot partition and plan to install GRUB2, be sure to mount only the target root partition before chrooting, but not the `/boot' partition as well. Mount /boot once inside the chroot environment. This is required because grub2-mkconfig will not detect /boot as a separate partition and will assume /boot and root are on the same partition if /boot was mounted before chrooting.

Booting from LVM Logical Volumes

GRUB2 supports booting from an LVM partition. However, one must set the device-mapper USE flag in order to activate this feature:

File/etc/portage/package.use

sys-boot/grub:2 device-mapper

Reemerge if needed. Next tell GRUB2 to preload its "lvm" module,

root # echo "GRUB_PRELOAD_MODULES=lvm" >> /etc/default/grub

And (re)generate grub.cfg with grub2-mkconfig.

Booting from RAID Array

The documentation on this subject, along with booting from encrypted physical volumes, is close to null. As I do not boot from a RAID array, anyone who managed to boot from a complex RAID array is welcomed to complete this section.

Note

Booting from RAID is only relevant for BIOS [boot]. EFI users shall roll out their custom initramfs or use an initramfs package available out there. Depending on your setup, you may use a BIOS/MBR or BIOS/GPT combination. Here is an example to a BIOS/GPT setup with `/boot' and `root' [`/'] on RAID-1 [1] and Xen on RAID-5.

Note

Do not forget to run `grub2-mkdevicemap' after creating your array(s) and re-ordering manually the generated file might be necessary to get your first array as `(md0)' instead of `(hd0)' and so forth. And that... with fixing the `(md<N>)' UUID which may be wrong: just compare the UUID obtained with `grub-probe -d --target=fs_uuid /dev/md<N>' and `mdadm -D /dev/md<N>' to be sure that your array, or boot array, has the right UUID. If not, manually fix it.

root #

for i in 1 3 4do UUID=$(mdadm -D /dev/md$i | grep UUID | awk '{ print $3 }')
UUID=${UUID//:}; uuid=${UUID:0:8}
for j in 9 13 15; do uuid+=-${UUID:$j:4}; done
uuid+=-${UUID:21:12}
echo -n "(md$i)    /dev/disk/by-id/md-uuid-$uuid"  >> /boot/grub2/device.map
unset UUID uuid; done

And then re-generate GRUB2 configuration file. Checkout out the generated cfg file to see if everything is fine at this point.

Note

It seems you should again correct the <uuid> value of the grub.cfg file because it should be wrong again. sigh. You should checkout the `search ...' line for that and correct the uuid with what you have in `/boot/grub2/device.map' and in the right format with that: some in the line of `12345678-1234-1234-1234-123456789abc' instead of the `12345678:12345678:12345678:12345678' format.

Booting from a RAID array is very similar to booting from a LVM Logical Volume aside from RAID specific terminology and syntax of raid partitioned volume.

Code

...
     insmod raid
#    and load the related `mdraid' module `mdraid09' for raid arrays with version 0.9 metadata, and `mdraid1x' for arrays with version 1.x metadata.
     insmod mdraid09
     set root=(md0p1)
#    or the following for an unpartitioned raid array
     set root=(md0)
...

Note

RAID user might merge the live ebuild to get the latest bit of fixes and updates.

Note

There's a nVidia (dm_nv) specific module for RAID 3/5, so something like `insmod dm_nv' is necessary for related hardware.

I can guess tat this should work with a simple software RAID setup. However, I have no idea or what command, if any exit at the moment of writing, to use to assemble an array such as `mdadm --assemble --scan /dev/md0' that an initramfs could take care of.

Booting from LUKS Physical Volume

Code

...
insmod gzio
	insmod part_gpt
	insmod cryptodisk
	insmod luks
	insmod gcry_twofish
	insmod gcry_sha256
        cryptomount -u <uuid>
	insmod lvm
	insmod ext2
	set root='lvm/<VG>-<LV>'
...

Note

To be done when information will be available. That menu entry was generated with sys-boot/grub-2.00 things changed with the beta releases. cryptomount can be use like `cryptomount hd0,gpt1' for example as well. This should be able to decrypt the cyphertext. I have a LVM stack on top of LUKS which could be a supplementary difficulty. I could not finish mount cyphertext(s) and finish my test with qemu-kvm. Other contributor(s) without a supplementary LVM stack are encouraged to complete this section.

Booting from newtwork (PXE)

Using framebuffer display

To have GRUB use a framebuffer graphical display, emerge GRUB with the truetype USE flag enabled. This will install a default font as well as a font conversion utility.

Then, you can configure /etc/default/grub.conf. For example:

File/etc/default/grub.confFramebuffer related settings

…
# Set resolution and color depth
GRUB_GFXMODE=1366x768x32
 
# Keep resolution when loading the kernel
GRUB_GFXPAYLOAD_LINUX=keep
 
# Set a background image
GRUB_BACKGROUND="/boot/grub2/bg.png"
 
# Use a custom font, converted using grub2-mkfont(1)
GRUB_FONT="/boot/grub2/fonts/roboto.pf2"
…

To find out what modes your graphics card supports, use the following commands on the GRUB shell:

(grub)

insmod all_video
(grub)

videoinfo

Troubleshooting

First off, checkout if you have an EFI02 (GPT disk) or bios_grub ([G]parted) for BIOS/GPT installation or enough gap before the first partion of the disk or the boot partition for BIOS/MBR installation before firing up `grub2-install' command. This will spare you some time.

Secondly, checkout if `/boot/grub2/grub.cfg' was correctly generated with `grub2-mkconfig' or generate one yourself with at least a `menuentry'. Refers to previous section for more information. And avoid writing `Boots up to prompt' section in the wiki because of failing to do that simple check before rebooting!

GPT hybrid MBR workaround

GRUB2 require an EE00 partition type first in the MBR partition list entry, but that may pose a problem to boot other OSs in the same disk especially MSDOS/Windows, to recognize a GPT partitioned disk with or without hybrid MBR. A workaround would be simply removing any protective EE00 partition, with fdisk for example but not gdisk! (it won't work with gdisk as the fake partition is just there to protect GPT main table), and boot in BIOS/MBR mode. Just remember to not use other disk tools but gdisk (it should work with [g]parted) to resize after that, else, use gdisk to add protective EE00 partitions to protect at least GPT main and backup partition before using any non GPT aware tools if necessary.

There's another issue, MSDOS/Windows may not find any suitable partition to boot from if there's a EE00 partition protecting GPT main partition table (sector 1-2047). This is happened to me and I had to remove the protective EE00 protective partition before getting a valid MBR partition list in [MS]DOS tools (to format a partition for example, the tools recognized a GPT partitioned disk at least). And then use gdisk to recompute the CHS value for hybrid MBR (in the recovery and transformation menu, or in the expert main menu).

Installation errors

Attempting to install GRUB to a disk or a partition

If you're getting this error:

Code

Attempting to install GRUB to a partition disk or to a partition.  This is a BAD idea.
Embedding is not possible.  GRUB can only be installed in this setup by using blocklists. 
However, blocklists are UNRELIABLE and their use is discouraged.

this could mean that:

1st: A `/boot' partition is not mounted, simply run as root `mount /boot'.
2nd: If you're trying to install GRUB2 in traditional BIOS/GPT setup, this could mean more likely that there isn't any EF02 or bios_boot to embed core.img. A little partition of a few hundreds kilo bytes may be enough, although it's : good to align it's partition to something like 2048 sectors to avoid performance penalty, so a 1MiB partition should do.

If you're trying to install GRUB2 in a partition e.g. `/dev/sda5' in BIOS/MBR setup (who did try it to BIOS/GPT?), simply add `--force' cmdline switch to get going. You should be fine with either enough gap before the first sector of the first partition or else use chattr command (as described in BIOS/MBR installation) to get going or else... destroy your partition boundary and possibly your LUKS or LVM2 header if any.

If grub2-install does not print any errors message or if the message is about scanning disk files and you have several platforms enabled in `/etc/portage/make.conf' and nothing is installed in the disk. Then, you should edit `/sbin/grub2-install' `platform=qemu' to `platform=pc', for example, or the appropriate platform in that case. This happened to me, and I had to look arround to found out, at last, that the platform shall be rightly set when installing grub:2.

Note

This is true for sys-boot/grub-1.99x only... for sys-boot/grub-2.x one should edit `/etc/grub.d/00_header', transform="s,grub,grub2-qemu," to transform="s,grub,grub2," for example, to install rightly with grub2-$platform-install.

No post-MBR gap

root #

grub2-bios-setup ..
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding won't be possible!
grub2-bios-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
            However, blocklists are UNRELIABLE and its use is discouraged.
grub2-bios-setup: error: If you really want blocklists, use --force.

This error means, that grub could not find the usual gap between the MBR and first partition of a disk. It is possible that the disk does not have this gap. Some tools format disks (e.g. LiveUSB disk installer) so that the first partition starts at sector 1 instead of 2048. Repartitioning the disk can fix this. Some visualization-based blockdevices can also cause problems. See http://bbs.archlinux.org/viewtopic.php?pid=581760#p581760

External resources

GRUB2

Contents

Installation

Configuration

BIOS/MBR or BIOS/GPT

UEFI/GPT

Hybrid GPT/MBR

Chainloading

ISO images

Another Bootloader

TrueCrypt

MSDOS/Windows

Extended features

Enabling resume swap for suspend

Chroot

Booting from LVM Logical Volumes

Booting from RAID Array

Booting from LUKS Physical Volume

Booting from newtwork (PXE)

Using framebuffer display

Troubleshooting

GPT hybrid MBR workaround

Installation errors

Attempting to install GRUB to a disk or a partition

No post-MBR gap

External resources

Personal tools

Namespaces

Variants

Views

Actions

Search

Navigation

Toolbox

Categories