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

[Colin Watson]

Igor: Thanks for your suggested grub-installer patches.  There were a
few problems with it, mainly misunderstandings about exactly what
semantics were expected of various code paths, and the patch would have
mishandled /dev/fiob* and later devices.  I've uploaded a corrected (I
think) version to
https://launchpad.net/~cjwatson/+archive/grub/+packages for trusty.

Narinder: The use of "dummy" is correct.  The problem you were
encountering was because you dropped a grub-installer version from
precise directly into a raring installer, and as a result you reverted
the fix for bug 1054323 along the way.  Needless to say I don't
recommend this approach. :-)

Kent: The reason that regex is failing is that patching grub-installer
isn't enough; it's also necessary to patch GRUB itself to handle probing
these devices.  grub2 2.00-19ubuntu4~ppa1 in
https://launchpad.net/~cjwatson/+archive/grub/+packages should have the
necessary patch.

There is now the slightly fiddly question of how to test all this.  I'd
very much like to test this on trusty before uploading backported
patches to precise.  However, this will only work if you've resolved the
issues with newer kernels.  If not, please let me know and I'll prepare
versions for precise.  If you can manage to use trusty, then the
simplest way to test it is probably to do the following:

 * Boot the installer with the following in its preseed file:

  d-i apt-setup/local0/repository string http://ppa.launchpad.net/cjwatson/grub/ubuntu trusty main
  d-i apt-setup/local0/key string http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x6A547A8B977102C0

 * Run through the installer until after the "Loading additional
components" stage.

 * Switch to tty2 (Alt-F2), run "nano /usr/bin/grub-installer", and
manually apply the grub-installer part of the change in
https://launchpadlibrarian.net/156124415/grub-
installer_1.78ubuntu8_1.78ubuntu9~ppa1.diff.gz to that file; the change
is short enough that you can do this in place with a bit of care.  Save
(Ctrl-o) and exit (Ctrl-x).

 * Switch back to tty1 (Alt-F1) and continue installation.

-- 
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:
  Triaged
Status in “grub2” package in Ubuntu:
  Triaged

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