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

[Brandon Hansen]

Thank you Kent.  Unfortunately I was not able to successfully boot after 
the grub stage.  I am not sure if that is our bug or not, though.  
Following is the processed I used, but first I'll mention that I was 
unable to use the insmod method of installing our driver during Ubuntu 
install in order to have our device recognized.  It kept telling me I 
had an incorrect module format.  I made sure the kernel versions matched 
up, but was unsuccessful using this method.

Instead, I used a driver injection disk to have our device recognized 
and that worked: the os and grub both installed successfully.  Then, 
because I don't have an option rom loaded on my card, I loaded our 
driver from the uefi shell and invoked grubx64.efi from the shell off of 
our device.  This brought the grub menu up and I chose to start Ubuntu 
Server.  I then get few print messages from our device and the OS does 
not boot.

The reason I mentioned the insmod method is because I'm not sure if, 
even though the driver injection disk files worked, there was still some 
sort of conflict that I didn't see.  Do you have any thoughts on that?  
Is there a different way of testing the fixes you would like me to try?  
I apologize I am by no means a Linux expert.  Thank you for your time.

Brandon

On 12/10/2013 11:09 AM, Kent Baxley wrote:
> @Brandon,
>
> Thanks for testing that on Precise.  I also assume that you were able to
> successfully boot from that point (I think the efi module for the fio
> device has to be loaded by hand)?   I just want to confirm so that way I
> won't be testing the same thing twice.
>
> Once the grub2 fixes go out for 14.04 I'll also test it here on my
> server.  I just tested 14.04 today not realizing that any fixes have
> gone out for grub2 on Trusty yet.   I'll try again as soon as I see the
> status change.
>
> Thanks, again, for testing precise.
>


This e-mail (and any attachments) is confidential and may be privileged.  Any unauthorized use, copying, disclosure or dissemination of this communication is prohibited.  If you are not the intended recipient,  please notify the sender immediately and delete all copies of the message and its attachments.

-- 
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