grub doesn't boot with efi and md raid root

Bug #1229738 reported by Dick Porter on 2013-09-24
This bug affects 20 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)

Bug Description

dick@reordberend:/tmp$ lsb_release -rd
Description: Ubuntu 12.04.3 LTS
Release: 12.04

dick@reordberend:/tmp$ apt-cache policy grub-efi-amd64
  Installed: 1.99-21ubuntu3.10
  Candidate: 1.99-21ubuntu3.10

Installed 12.04.3 LTS Server using md raid1 for root partition on x86-64 box using EFI boot.

Grub installs its EFI app correctly, and it launches at boot. However, grub can't find the root partition. Inspecting grub's config shows that it has prefix and root set to the EFI boot partition. Manually setting those to the raid1 root partition at the grub prompt and running normal allows booting to proceed correctly (ie following the instructions at works).

In EFI mode, grub seems to expect its grub.cfg and modules to be in the EFI partition. However, they are all installed in the root filesystem. The problem can be solved in the grub-install script by giving an embedded config to grub-mkimage ( grub-install already has support for this, but it fails if the root partition is raided.

Inside grub-install, if devabstraction_module is set (and with md as the root partition it will be) then config_opt_file is never set. The attached patch solves the bug for me but will doubtless require refining to be generally applicable.

Dick Porter (dick-8) wrote :

The attachment "Fix that works for me" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
tags: added: precise
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub2 (Ubuntu):
status: New → Confirmed
Martin Sucha (martin-sucha) wrote :

The patch provided by Dick Porter worked for me as well (with /boot being a separate md array than /). Thanks!

Andy Sayler (andy.sayler) wrote :

I've encountered this issue as well running 12.04.3 with a 5-device RAID 6 array using grub + EFI + Secure Boot.

I worked around it by manually creating a grub.cfg file on the EFI partition that just changes the root to the correct /boot md partition and then reloads the actual /boot/grub.cfg file.

Details here:

YannUbuntu (yannubuntu) wrote :

Dear all,
please can you tell us if you can reproduce the bug with 13.10 ?

Dick Porter (dick-8) wrote :

Sorry, the machine in question is a server that needs to remain on LTS

Frici (fricigrillbufe) wrote :

Hi, I have very a similar issue. Reproducable with 13.10 as well.

Charles Hill (cphill) wrote :

I also found this bug. I installed 12.04.3 LTS Server using md raid1 for root partition on x86-64 box using EFI boot. The Ubuntu installer (alternate_amd.iso) sets up partitions /boot/efi and / and swap.

I also found grub installs its EFI app correctly, and it launches at boot. However, grub can't find the root partition.

I found a different answer on how to patch around this from: Manually edit /boot/efi/EFI/ubuntu/grub.cfg and substitute the correct UUID for the sw raid for the bad UUID in this file. The system will now reboot, but I haven't tested booting from a HW off.

What I'm concerned about is "how does this work?" The bootloader GRUB2 is reading /boot/efi/EFI/ubuntu/grub.cfg from the /boot/efi FAT32 UEFI partition and executes a command "search_fs_uuid uuid root" which finds the uuid for the RAID1 md device. But how does GRUB2 know about sw raid devices? The / filesystem is on a RAID1. GRUB2 needs to load /boot/grub/grub.cfg and run it.

My hypothesis is GRUB2 goes to the md superblock and finds the uuids for the devices in the raid, goes to one of those, and since it is mirrored (RAID1), can fetch from /boot/grub. Is that right?

Perhaps this bug is easily fixed by the installer making the UEFI FAT32 partition be at /boot instead of /boot/efi. In that case, /boot/grub/grub.cfg will be in the UEFI partition and GRUB2 will always know how to access it even if / is RAID5.

Can anyone confirm this line of thinking?

Phillip Susi (psusi) wrote :

Grub understands linux software raid. The only thing that needs to be on the EFI system partition is the grub image itself. This seems to just be a bug in grub-mkconfig that causes it to put the wrong uuid in the cfg.

Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
Charles Hill (cphill) wrote :

That makes sense. It is consistent with all the reports I've seen describing this defect. My patched system reboots fine after HW off.

Thomas (t.c) wrote :

I also used instructions from here:

cp /usr/sbin/grub-install /usr/sbin/grub-install.backup
patch /usr/sbin/grub-install patch
umount /boot/efi
mount /dev/sda1 /boot/efi
grub-install /dev/sda1
umount /boot/efi
mount /dev/sdb1 /boot/efi
grub-install /dev/sdb1

Anatoli (anatoli) wrote :

Hi! I have the same problem: install everything and boot in EFI mode, then I see "error: efidisk read error" and I get grub> prompt. I found a fix not mentioned here: after the install, boot from a LiveCD, install boot-repair and in its options unselect "SecureBoot" option. [I don't know what's wrong with the SecureBoot, but I won't investigate it further. Also, I don't know if the new grubx64.efi file the boot-repair writes to the EFI partition boots in SecureBoot or not.] Proceed with the commands it offers (when it asks about buggy-kernel, say No) and reboot. More details here:

I confirm that the patch proposed by Dick Porter executed as Thomas C. explains also fixes my problem, though the "efidisk read error" flashes for an instant before it starts to boot.

I also tried the solution of creating a grub.cfg file in the EFI partition (proposed by Andy Sayler) and it didn't work, though Andy had a slightly different setup: /boot and / on the same RAID array. I tried some obvious tweaks but with no luck.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers