GRUB/Advanced storage

This section is based on converting a non-UEFI, MBR partition based system to boot from a GPT RAID enabled disk. It is currently incomplete, and partially edited from the previous version.

Booting from LVM logical volumes
GRUB2 supports booting from an LVM partition however the  USE flag must be set in order to activate this feature.

If GRUB2 is currently installed, re-emerge it using the  option:

Next tell GRUB2 to pre-load the  module:

Finally (re)generate a GRUB2 file using the grub2-mkconfig command.

Booting from RAID array
In this section, we assume a system has three hard drives. is the original MBR Windows Vista disk, untouched apart from installing GRUB2 onto it. and are configured identically.

and are raided together to make the  partition.

and are raided together to make the  partition.

(or ) is needed otherwise GRUB2 will not be able to read the partition table.

is required for RAID v1.1 or higher. If using RAID v0.9 or v1.0 the RAID module might not be needed ( for v0.9) because the RAID information is stored at the end of the partition. Any references to  are obsolete.

is required for ext partitions. For a other file systems substitute the appropriate module.

tells GRUB2 what root device Linux will be using.

At this point, GRUB2 is ready to hand over control to Linux. Any errors up to this point (missing modules, missing boot partition, etc.) are problems with GRUB2 not the Linux kernel. Onward from this point, it is safe to narrow errors down to Linux.

Linux is unable to assemble RAID assemblies in the kernel. It must call out to user-space tools; if the root partition is a RAID set, an initramfs must be used.

Make sure the kernel is configured correctly. Especially make sure that  variable is set (this is why genkernel must not be used - genkernel will reset the value of   and reap havoc upon the RAID set).

Compile the kernel manually by running the following commands as root:

At this point it is probably a good idea to emerge udev - and make sure all warnings are fixed!

Use genkernel utility to generate an initramfs:

The  and   lines in  should now load the Linux kernel. Add the  parameter to the Linux kernel command line in GRUB2. Without it the RAID set will not assemble and the Linux kernel will not find the root device.

The first boot option correctly assembles the root RAID set at boot time, and boots successfully. Any attempt to access the root device from user space will fail as if the RAID set does not exist. This breaks GRUB2, and making the mistake of trying to run grub2-install on top of these errors will break GRUB boot altogether. Make sure Rescue CD and a copy of the Gentoo handbook are easily available before attempting to use a RAID set on the root disk.

The second option drops into a GRUB2 shell. Running ls /dev/md* will show that initrd has found the RAID set devices, and giving it the device, eg, will boot into a fully working system with userspace access to the boot device.

Put these into a script at the first available opportunity.

Further documentation on this subject, along with booting from encrypted physical volumes, is close to null.

Any further documentation from a user that has successfully booted a system from a RAID array welcome to complete add a RAID boot section to this article.

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.

This should work with a simple software RAID setup. However, the author has 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
Tell GRUB2 to look for cryptodisks:

(Re)generate the with the grub2-mkconfig utility.