[Bug 1237519] Re: Grub2 fails to install to non-standard device path

[Kent Baxley]

The efibootmgr problems mentioned above are most likely resolved
already.  In 13.04, there was a kernel bug where the kernel would
sometimes fail to update EFI vars.  I think that's partly what we were
hitting here.  Here's the bug, and the issue has since been fixed:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173423

If I boot to the SATA drive, update the kernel to the latest 13.04 one,
add in the updated iomemory-vsl driver for that kernel and then try to
add an efi entry for the fioa device via efibootmgr, it at least
succeeds:

efibootmgr -c -w -L FusionIO -d /dev/fioa1 -p 1 -l
'EFI\ubuntu\grubx64.efi'

...but, I'm not sure if what's added is entirely correct (see attached
output from efibootmgr -v)

At this point, it is indeed now every important that we test things with
the latest releases, given the issue I just hit here.

Brandon at FusionIO is working with his build team to see what can be
done about getting a kernel module built that will work on 13.10 and
higher releases.   If we can get that, it'll hopefully help shake out
some things that may have already been addressed.

** Attachment added: "efibootmgr.txt"
   https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1237519/+attachment/3890232/+files/efibootmgr.txt

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1237519

Title:
  Grub2 fails to install to non-standard device path

Status in “grub2” package in Ubuntu:
  Incomplete

Bug description:
  Running the Ubuntu Server installer in UEFI mode fails to install the
  Grub bootloader.  Attached is the syslog output that shows grub-
  installer failed with error code 1.  I have seen this on Ubuntu 12.04,
  12.10, and 13.04.  I believe the problem is that Grub is looking for
  device paths that match something like '/dev/sdX' or '/dev/hdX' but
  the device I am installing to does not follow that convention.

  The reason I believe it is looking for specific devices paths is if,
  during installation after my device has been partitioned, I escape
  into the shell (using alt+f2) and create a hard link from my device
  name and its partitions, to a device name that matches 'sdX', then
  Grub begins to install.  For example, if my device name is /dev/fioa
  and has partitions /dev/fioa1, /dev/fioa2, and /dev/fioa3, I map those
  partitions to something like /dev/sdc, /dev/sdc1, /dev/sdc2, and
  /dev/sdc3 and continue with the installation onto /dev/sdc.  By doing
  this, Grub will begin to install on the device.

  Possibly useful background information:

  - The operating system and all files install just fine without
  problem, it is the last step of installing the bootloader that fails.

  - In order to have the device recognized during installation, I either
  need to run 'insmod' from a terminal or we have to manually modify
  initrd to include our .ko file because it is not a standard disk
  driver.  Using either method does not affect the outcome of Grub2
  failing to install.

  - Even though grub begins to install after creating the hard links
  mentioned above, it does not finish successfully due to the linked
  paths (e.g. /dev/sdc) not being in the device map.  That is a separate
  issue, but may be expected behavior and would likely need a separate
  ticket if it needed to be reported at all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1237519/+subscriptions