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

[Kent Baxley]

@Brandon,

I was able to successfully boot into 12.04.  The trick, I think, is that
you need two sets of driver disks in order to pull this off.

I tested this on a PowerEdge C8000 series server, which allowed me to
boot trouble-free into an EFI shell to load the Fusion-io.efi module.

The reason is because there are two kernels involved on this daily image
of 12.04.  The installer kernel is running 3.8.0-29 while the final
kernel that gets installed is 3.8.0-35.   Since the kernel modules are
built for a specific kernel, I'm guessing what happened to you was that
you had 3.8.0-29 drivers but didn't have any for the 3.8.0-35 kernel,
thus, when the OS tried to boot it fell down on you.

Here's what I did:

1) Because of this situation, I had to create kernel modules for both
3.8.0-29 and 3.8.0-35, create packages,  and put the respective packages
on my driver disk USB stick.

2) Once those were in place, I booted up with the kernel command line
"anna/choose_modules=driver-injection-disk-detect"

3) I verified both sets of kernel modules were installed.  The installer
picked up the fioa device and I  could install without trouble..grub
gave me no problems.

4) Once that was done, I rebooted into an EFI shell, loaded the Fusion-
IO module, then booted from grubx64.efi on the FIO device.

5) From the grub prompt I saw an "efidisk write error".  This can be
safely ignored and after a few seconds the Operating Sytem booted up
just fine from the fioa disk partitions.

So, 12.04.4's daily builds are indeed good to go from the testing I was
able to do.

I'll send along the packages I used along with the steps I used to boot
this machine up successfully.

-- 
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 “grub-installer” package in Ubuntu:
  Fix Released
Status in “grub2” package in Ubuntu:
  In Progress
Status in “grub-installer” source package in Precise:
  Fix Committed
Status in “grub2” source package in Precise:
  Fix Committed

Bug description:
  SRU justification:

  [Impact] Installation impossible on FusionIO disks; furthermore the method used to identify partitions in GRUB relies on an obsolete ioctl which doesn't properly handle large disks.
  [Test Case] We have a remotely-accessible server on which we can do straight-through installation tests on the hardware in question.
  [Regression Potential] The device handling changes are boring and straightforward.  The work to avoid the obsolete ioctl should be regression-tested on some other hardware (it doesn't matter too much which) to make sure it still works there; although I've already done this on my laptop.

  Original report follows:

  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/grub-installer/+bug/1237519/+subscriptions