[Bug 1430015] [NEW] Fresh Trusty install to pre-partitioned disk results in broken grub install

[NickW]

Public bug reported:

I just attempted to repair my grub install on a i386 PC recently
upgraded to Ubuntu Trusty Tahr.  Specifically, this is a fresh install
to one of the partitions, but the existing partition table was kept as-
is.  This means there are 64 blocks before the first partition, which is
how Ubuntu used to like things.

However, the installation's grub package didn't install correctly, and
subsequent attempts to repair it haven't been successful. I know that
grub *can* boot the OS I just installed because it had been nominally
working prior to my more recent attempts, my reason for attempting to
"fix" it by tinkering with grub-install was that I could not get the OS
to be the default menu item.

However, Grub now consistently refuses to (re)install itself to the boot
sector, failing after running grub-install /dev/sdb like this (as in the
pastebin output from boot repair tool below):

 grub-install: warning: your core.img is unusually large.  It won't fit in the 
 embedding area. 
 error: embedding is not possible, but this is required for RAID and 
 LVM install.

There should be a mine of information about my system here, courtesy of boot repair:
   http://paste.ubuntu.com/10570478/

>From what I can tell in further experiments, there grub installation is
not quite working as advertised, for instance if I try to pass the
option --core-compress=xz, it fails with the error "Option should have
been recognised!?".  Checking the source code of 2.02~beta2-9ubuntu1
downloaded from launchpad, it doesn't look to me like anything actually
handles this option.  Nor can I change the list of modules included in
the install with the --modules option.  So my attempts to reduce the
size of the core.img file isn't successful.

Using the --force option, as hinted (IIRC) here, doesn't seem to work
(and my error mentions nothing about blocklists).

  http://forums.fedoraforum.org/archive/index.php/t-274701.html

Using the --verbose option and manually editing and running the commands
it outputs does succeed in installing grub, but my know-how is limited
and I managed to make my machine unbootable like this.  Hence the use of
boot repair.

I'm currently out of ideas on how to fix this without what I anticipate
to be a somewhat painful partition reorganisation.  This also looks like
a situation ubuntu's installer would do better to handle more
gracefully.  Hence I'm filing this in the hope that I can help to find a
solution.

** Affects: grub (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub in Ubuntu.
https://bugs.launchpad.net/bugs/1430015

Title:
  Fresh Trusty install to pre-partitioned disk results in broken grub
  install

Status in grub package in Ubuntu:
  New

Bug description:
  I just attempted to repair my grub install on a i386 PC recently
  upgraded to Ubuntu Trusty Tahr.  Specifically, this is a fresh install
  to one of the partitions, but the existing partition table was kept
  as-is.  This means there are 64 blocks before the first partition,
  which is how Ubuntu used to like things.

  However, the installation's grub package didn't install correctly, and
  subsequent attempts to repair it haven't been successful. I know that
  grub *can* boot the OS I just installed because it had been nominally
  working prior to my more recent attempts, my reason for attempting to
  "fix" it by tinkering with grub-install was that I could not get the
  OS to be the default menu item.

  However, Grub now consistently refuses to (re)install itself to the
  boot sector, failing after running grub-install /dev/sdb like this (as
  in the pastebin output from boot repair tool below):

   grub-install: warning: your core.img is unusually large.  It won't fit in the 
   embedding area. 
   error: embedding is not possible, but this is required for RAID and 
   LVM install.

  There should be a mine of information about my system here, courtesy of boot repair:
     http://paste.ubuntu.com/10570478/

  From what I can tell in further experiments, there grub installation
  is not quite working as advertised, for instance if I try to pass the
  option --core-compress=xz, it fails with the error "Option should have
  been recognised!?".  Checking the source code of 2.02~beta2-9ubuntu1
  downloaded from launchpad, it doesn't look to me like anything
  actually handles this option.  Nor can I change the list of modules
  included in the install with the --modules option.  So my attempts to
  reduce the size of the core.img file isn't successful.

  Using the --force option, as hinted (IIRC) here, doesn't seem to work
  (and my error mentions nothing about blocklists).

    http://forums.fedoraforum.org/archive/index.php/t-274701.html

  Using the --verbose option and manually editing and running the
  commands it outputs does succeed in installing grub, but my know-how
  is limited and I managed to make my machine unbootable like this.
  Hence the use of boot repair.

  I'm currently out of ideas on how to fix this without what I
  anticipate to be a somewhat painful partition reorganisation.  This
  also looks like a situation ubuntu's installer would do better to
  handle more gracefully.  Hence I'm filing this in the hope that I can
  help to find a solution.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/1430015/+subscriptions