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

[Brandon Hansen]

I've been looking at the HDIO_GETGEO ioctl a bit, and it may be worth a
discussion with those who have more information as to its usefulness.
Particularly, the notes about the IOCTL say:

"Not particularly useful with modern disk drives, whose geometry
is a polite fiction anyway.  Modern drives are addressed
purely by sector number nowadays (lba addressing), and the
drive geometry is an abstraction which is actually subject
to change.  Currently (as of Nov 2004), the geometry values
are the "bios" values -- presumably the values the drive had
when Linux first booted.

In addition, the cylinders field of the hd_geometry is an
unsigned short, meaning that on most architectures, this
ioctl will not return a meaningful value on drives with more
than 65535 tracks.

The start field is unsigned long, meaning that it will not
contain a meaningful value for disks over 219 Gb in size."

It is this last paragraph about the start sector value that is most
concerning to me since it is the start sector value that is needed for
this ticket.  From what I could gather, it appears that people lean
toward Phillip Susi's suggestion of going the sysfs route.

I did come across the mention of another IOCTL called
BLKPG_GET_PARTITION, but I couldn't find any good documentation on it to
assess its usefulness for our purposes.  Does anyone have any input on
this ioctl or know where I can find good documentation?

Finally, it is worth mentioning that RHEL works with our devices and
installs grub without any problems.  From what I understand, they use
Grub 0.97 (probably patched many times) and the grub error from this
ticket does not happen with them.  There is the potential that one of
these patches uses the sysfs method that is needed here.  If anyone has
some experience in RHEL, they may be able to offer some input here, but
this may be a worthy avenue to explore.

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

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