In my setup, I have two disks that are each formatted in the following way:

2)  300MB LINUX_RAID   
3)  *     LINUX_RAID   

The boot partitions are mapped in /dev/md0, the rootfs in /dev/md1. md0 is formatted with ext2, md1 with XFS. (I understand that formatting has to be done on the md devices and not on sd - please tell me if this is wrong).

How do I setup GRUB correctly so that if one drive fails, the other will still boot? And by extension, that a replacement drive will automatically include GRUB, too? If this is even possible, of course.

4 Answers 4


If the two disks are /dev/sda and /dev/sdb, run both grub-install /dev/sda and grub-install /dev/sdb. Then both drives will be able to boot alone.

Make sure that your Grub configuration doesn't hard-code disks like (hd0), but instead searches for the boot and root filesystems' UUIDs.

I'm not aware of support in Grub to declare two disks as being in a RAID-1 array so that grub-install would automatically write to both. This means you'll need to run grub-install again if you replace one disk; it's one more thing to do in addition to adding new members to the RAID arrays.

  • 1
    "Make sure that your Grub configuration doesn't hard-code disks like (hd0), but instead searches for the boot and root filesystems' UUIDs." How? Mar 7, 2018 at 18:56
  • 1
    @lifeofguenter With search Mar 8, 2018 at 7:46
  • 1
    thanks @Gilles can you be a little more precise? (I don't need a snippet, but at least a link to a documentation I can read up on? I did notice that device.map should most probably be missing? Mar 8, 2018 at 13:33
  • 1
    gnu.org/software/grub/manual/grub/grub.html#GNU_002fLinux or look at your distribution's file Mar 8, 2018 at 21:45
  • 1
    On some systems it's grub2-install instead of grub-install.
    – ndemou
    Mar 15, 2018 at 13:06

The other answers (suggesting to use grub-install /dev/sda and grub-install /dev/sdb) work when booting using Legacy BIOS, but not when using UEFI.1 (To check whether you've booted using UEFI, check if /sys/firmware/efi exists.)

If you use UEFI, the ESP (EFI System Partition) cannot be part of the software RAID, since it's what's going to be used to boot up before the software RAID is initialised.

You'll need to have the same contents on both disks, but they will be two separate (FAT32) partitions, not part of the RAID.

Assuming your first ESP is /dev/sda1 (a FAT32 partition containing a EFI directory), your second disk (e.g. /dev/sdb) will need to have a partition in the same place and contents for redundancy.

Typically, by default, /dev/sda1 will be mounted on /boot/efi, and the other one won't be mounted (or maybe even exist, if you've just set up the RAID). Make sure you have a FAT32 partition on /dev/sdb1 matching that of /dev/sda1 and copy the content into it.

The Debian Wiki entry on UEFI suggests mounting the second one into /boot/efi2 and using an update-grub hook to copy automatically.

You'll need to create the second mounting point (mkdir /boot/efi2) and add the second ESP accordingly to /etc/fstab (a good suggestion on the Debian Wiki is to add nofail). For example:

# You can find the partitions UUIDs using blkid
UUID=7F49-3985  /boot/efi       vfat    umask=0077,errors=remount-ro,nofail      0       0
UUID=8D57-95E5  /boot/efi2      vfat    umask=0077,errors=remount-ro,nofail      0       0

Then add a hook into /etc/grub.d/90_copy_to_boot_efi2 (and make it executable). This will be run next time your run update-grub. Here is a slightly modified version of the script of the Debian Wiki:

set -e

if mountpoint -q /boot/efi && mountpoint -q /boot/efi2 ; then
        rsync -t --recursive --delete /boot/efi/ /boot/efi2/
exit 0

NOTE (if sda fails): Suppose sda fails and you need to replace the disk, remember to remove that hook, and copy the contents of /boot/efi2 into the new /boot/efi. Otherwise, you may be in a situation where /boot/efi (on the new disk) is empty and your working /boot/efi2 will be wiped (rsync --recursive --delete can be unforgiving).

1: This does not seem to be widely documented (only reference found on the Arch Linux wiki), but when you use an EFI Grub installation, the INSTALL_DEVICE parameter (e.g. /dev/sda) will be ignored. In fact, grub-install /dev/non_existent_device will not even fail:

# grub-install /dev/non_existent_device
Installing for x86_64-efi platform.
Installation finished. No error reported.
  • FYI: I have manually added the UEFI menu entry for the second HDD's ESP with this command: efibootmgr -c -d /dev/sdbX -l '\\EFI\\debian\\shimx64.efi' -L 'debian HDD2'. Note that I've called it "debian HDD2", wheras the menu label for the first HDD's ESP is still "debian". If there were two or more menu entries labeled "debian", they would be replaced by a single entry (!) by grub-install. On the other hand, it there were zero menu entries labeled "debian", grub-install would add another menu entry and put it on the top of the boot order.
    – myrdd
    Mar 15 at 17:12

I've done this on quite a few servers over the past while and found issues sometimes, usually what I do is run the following

sudo grub-install /dev/sdb
sudo update-grub /dev/sdb

The problems I've run into are usually displayed with error messages like

update-grub … update-grub failed with no such disk …

To resolve this i've run

sudo mv /boot/grub/device.map /boot/grub/device.map.old 
sudo update-grub 

and this seems to have resolved the issue - as a test in some cases I have removed /sdv/sda and just used /dev/sdb to boot from but this is not ideal and most likely not possible in most production environments!


My experience installing CentOS 5 and CentOS 6 is that during the installation phase I configured the RAID-1 at that time - the installation does give you the choice to do this. What transpired was the following: 1. Defined /dev/sda1 as 1 GB as a RAID partition 2. Defined /dev/sdb1 as 1 GB as a RAID partition 3. Created RAID device /dev/md0 made up of /dev/sda1 and /dev/sdb1 4. Created the /boot partition using /dev/md0 5. Created additional partitions using steps 1 - 3. 6. Implemented LVM on partitions created in step 5 by following instructions.

After the initial system boot, in the grub.conf I altered the entry /dev/sda1 to /dev/md0. I then copied the entry the splashimage line the has (hd0,0) and added a # at the beginning and changed (hd0,0) to (hd1,0). Looking at the above answers showing how to install grub to /dev/sdb follow them. Modify the fstab so that the boot mount point uses /dev/md0 (by doing this, when you do a yum update a there is something updated on the /boot partition it will be written to both /dev/sda1 and /dev/sdb1). If you have a /dev/sda hard drive failure, you would have to boot using the rescue and comment out the (hd0,0) line and uncomment the (hd1,0) line. Your system should be bootable

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .