grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root

Bug #1236625 reported by Steve Langasek
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Fix Released
High
Unassigned

Bug Description

If /boot/grub is on an LVM disk, and the system boots with UEFI, grub-install will fail to set up /boot/efi/EFI/ubuntu/grub.cfg. Apparently I had this file already on my system (probably from a previous install attempt?) pointing at a partition I didn't even know about and didn't have mounted, which was letting my system continue to boot, but using kernels on this other partition that were no longer being updated at all Since this disk was not mounted as /boot.

$ sudo /usr/sbin/grub-probe --device-map= --target=abstraction --device /dev/mapper/ubuntu--vg-root
lvm
$

grub-install:

 607 # Device abstraction module, if any (lvm, raid).
 608 devabstraction_module="`echo "${grub_device}" | xargs "$grub_probe" --device-map="${device_map}" --target=abstraction --device`"
[...]
  641 if [ "x${devabstraction_module}" = "x" ] ; then
[...]
  682 if [ x"$uuid" != x ]; then
  683 echo "search.fs_uuid ${uuid} root $hints " >> "${grubdir}/${grub_modinfo_target_cpu}-$grub_modinfo_platform/load.cfg"
  684 search_module=search_fs_uuid
  685 else
  686 mkdir -p "${grubdir}/uuid"
  687 file="`mktemp "${grubdir}/uuid/XXXXXXXXXXXXXXXXXXXXXXXXX"`"
  688 relfile="`${grub_mkrelpath} "$file"`"
  689 echo "search.file '${relfile}' root $hints " >> "${grubdir}/${grub_modinfo_target_cpu}-$grub_modinfo_platform/load.cfg"
  690 search_module=search_fs_file
  691 fi
[...]
  704 else
  705 if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
[...]
  710 fi
[...]
  713 fi

So for plain LVM, nothing tells grub on the EFI boot partition where to find its prefix. I guess this would've resulted in an unbootable install, if I hadn't happened to have an extra /boot partition hiding around on my system already.

Related branches

Revision history for this message
Steve Langasek (vorlon) wrote :

setting 'high', based on the fact that this would leave LVM/UEFI systems unbootable after install.

Changed in grub2 (Ubuntu):
importance: Undecided → High
Steve Langasek (vorlon)
Changed in grub2 (Ubuntu):
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 2.00-19ubuntu2

---------------
grub2 (2.00-19ubuntu2) saucy; urgency=low

  [ Steve Langasek ]
  * debian/patches/ubuntu_efi_always_install_grub_cfg.patch: unconditionally
    create grub.cfg on our EFI boot partition. Closes LP: #1236625.
  * If MokManager is present on the host system, copy it onto the EFI boot
    partition for use.
 -- Colin Watson <email address hidden> Thu, 10 Oct 2013 18:23:29 +0100

Changed in grub2 (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Mike Butash (michael-butash) wrote :

I'm running into the same issue here, similiar circumstances it sounds like. I've been trying to work around what seems like an utterly broken install process (lack of mdadm, hang at trying to not activate ubuntu one), now stuck at trying to figure out what is broken about the grub install.

I'm using two redundant ssd's, mdraid, luks, and lvm in that order. I'm not sure how developers intend for a completed installation to work, but trial and error got me with what looks like this:

/dev/sda
-part1:efi (fat32)
-part2:md0 (boot0)
-part3:md1 (luks volume)
|__md0-/boot (ext2)
|__md1 - cryptsetup
 |-lv-root0 - / (ext4)
 |-lv-usr0 - /usr (ext4)
 |-lv-var0 - /var (ext4)
 |-lv-varlog0 - /var/log (ext4)
 |-lv-home0 - /home (ext4)

Rinse/repeat with /dev/sdb

It's a pain, I have to install gdisk and mdadm in the liveos, build the partitions, mdadm, cryptsetup, build pv/vg/lv's. format/mount the partitions under /target (this keeps the installer from demaning to format them stupid since I went through hassle to setup block-size, stride, and stripe-width), and *then* run the installer. At the partitioning, I simply set them to be ext4 and set the directory to boot, and choose the sda disk.

After installing, the only thing I catch is grub failing with "grub-install dummy". Looking at the df statistics, it's mounted all the partitions properly, including the efi under /boot/efi, but looks like the grub disk parsing is just broken how it's deriving the location.

This would be much easier it worked like Arch and just simply used the efi partition as /boot instead of /boot/efi.

Grub is setting at 2.00-19ubuntu2 once the installer is run, so should encompass this fix.

What exactly is ubuntu expecting since the desktop installer isn't flexible enough to do what I need it to?

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.