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

[Phillip Susi]

*** This bug is a duplicate of bug 1059827 ***
    https://bugs.launchpad.net/bugs/1059827

** This bug has been marked a duplicate of bug 1059827
   Non trivial grub2 installs no longer fit in small embed areas

-- 
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/1430015

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

Status in grub2 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/grub2/+bug/1430015/+subscriptions