[Bug 1237519] Re: Grub2 fails to install to non-standard device path
Colin Watson
cjwatson at canonical.com
Wed Nov 27 15:04:31 UTC 2013
I investigated this with the aid of some kindly-provided remote access
and gdb.
GRUB needs to be able to find the start sector of each partition within
a disk in order to accurately match up OS-level devices with GRUB
devices. On Linux, it uses the HDIO_GETGEO ioctl to do this; although
most of the information returned by that ioctl is obsolete, it returns
the start sector. Most Linux block device drivers implement this ioctl;
unfortunately the FusionIO block device driver does not, and therefore
GRUB has no way to safely identify /dev/fioa1.
Since this ioctl is typically rather easy to implement (you need to
implement the "getgeo" member of block_device_operations), I think this
should be fixed in the FusionIO driver. If you don't have meaningful
cylinder/head/sector-type information to fill in, you can probably fake
it up, perhaps in the same way that drivers/block/umem.c does. The
start sector is filled in from generic code in block/ioctl.c.
There is only one other way I know of to get the start sector of a
partition from userspace, and that's to read its "start" attribute from
sysfs. However, that's considerably more cumbersome to do from C code,
and I'd prefer to avoid that if at all possible. If you could add this
fairly simple interface to the FusionIO driver, it would make things
considerably easier. Alternatively, if there's some other interface you
can suggest that's generic in Linux rather than being FusionIO-specific,
I'd be happy to look into using that.
--
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
More information about the foundations-bugs
mailing list