** Description changed: + 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1237519 Title: Grub2 fails to install to non-standard device path To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1237519/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
