Grub won't boot from GPT RAID (gave up waiting for root device)

Unix & Linux Asked by Ansgar on September 10, 2020

I’m having problems with booting a Debian 8 system on which I migrated the root partition from a single hard drive to a RAID1 (mdraid).

On every boot, I get the following grub error:

Gave up waiting for root device. Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/2ab18cb4-a23d-4e5c-b37d-cbd3077b878c does not exist.
Dropping to a shell!
modprobe: module ehci-orion not found in modules.dep


/dev/md0 is not started, so it can’t find the root partition:

(initramfs) ls /dev/md*
ls: /dev/md*: No such file or directory

I can, however, start the raid manually just fine:

(initramfs) mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.
(initramfs) ls /dev/md*

The system will only boot if I manually create the directory /dev/disk/by-uuid and link md0:

(initramfs) mkdir /dev/disk/by-uuid
(initramfs) ln -s /dev/md0 /dev/disk/by-uuid/2ab18cb4-a23d-4e5c-b37d-cbd3077b878c

I hope someone can help me figure out why grub doesn’t start the md device by itself. I searched the internet and tried about everything I could find but no luck. I’m really lost right now.

I want to boot via BIOS-legacy, not UEFI.

The only two connected hard drives (SSD!) are formatted with a GPT partition table and the following partitions (exactly the same):

1      1049kB  2097kB  1049kB                     bios_grub
2      2150MB  12,9GB  10,7GB  ext4               raid

(grub-pc needs the first partition to boot from GPT drives)

The Raid1 (v0.90 metadata) is formatted directly as ext4.

Through a live system chroot, I installed grub-pc to /dev/sda and /dev/sdb, changed my fstab, ran update-grub andupdate-initramfs -u -k all.


/dev/sda2: UUID="b59d3baf-346b-568d-03a2-8b26060640c5" TYPE="linux_raid_member" PARTUUID="0609ba5b-9065-41f8-80ed-6832e3236ec9"
/dev/sdb2: UUID="b59d3baf-346b-568d-03a2-8b26060640c5" TYPE="linux_raid_member" PARTUUID="24ee1040-02dd-4867-b4da-5be11d59bdcd"
/dev/md0: UUID="2ab18cb4-a23d-4e5c-b37d-cbd3077b878c" TYPE="ext4"
/dev/sda1: PARTUUID="df5161cf-b5b3-422c-9ed2-90a7750ac265"
/dev/sdb1: PARTUUID="7d20b55b-ba50-4187-b05e-ae1f18b21de3"

mdadm.conf contains (only!) the content from mdadm --detail --scan:

ARRAY /dev/md0 metadata=0.90 UUID=b59d3baf:346b568d:03a28b26:060640c5

Here is an excerpt from my /boot/grub/grub.cfg:

insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/b59d3baf346b568d03a28b26060640c5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='mduuid/b59d3baf346b568d03a28b26060640c5'  2ab18cb4-a23d-4e5c-b37d-cbd3077b878c
  search --no-floppy --fs-uuid --set=root 2ab18cb4-a23d-4e5c-b37d-cbd3077b878c
echo        'Linux 3.16.0-4-amd64 wird geladen …'
linux       /boot/vmlinuz-3.16.0-4-amd64 root=UUID=2ab18cb4-a23d-4e5c-b37d-cbd3077b878c ro  rootdelay=20
echo        'Initiale Ramdisk wird geladen …'
initrd      /boot/initrd.img-3.16.0-4-amd64

One Answer

It's not actually grub which does this, but the initramfs. On Debian, the default initramfs implementation is the one inside the initramfs-tools package. What your initramfs does exactly to be able to mount the root filesystem can depend on many factors, including things like which packages are installed (packages can add hook scripts to extend the initramfs functionality) at the time when update-initramfs was last called, and how they were configured.

Since the problem appears to be that your mdraid devices aren't being rebuilt, I suspect that your mdadm package hasn't been configured right. Try to fix that first:

sudo dpkg-reconfigure mdadm

After that, the initramfs should be updated automatically.

If that doesn't fix it, and as part of your migration to software RAID you created a new filesystem, then it may be that your fstab has the UUID of the old filesystem, which now no longer matches the new filesystem. Check this:

grep $(blkid /dev/md0) /etc/fstab

If that produces no output, then edit /etc/fstab to replace the UUID specified there for the root device with the output of blkid /dev/md0, and run update-initramfs again.

Answered by Wouter Verhelst on September 10, 2020

Add your own answers!

Ask a Question

Get help from others!

© 2024 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP