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

Bug #1430015 reported by NickW
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
New
Undecided
Unassigned

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.

Steve Langasek (vorlon)
affects: grub (Ubuntu) → grub2 (Ubuntu)
Revision history for this message
NickW (e-launchpad-wu-lee-noodlefactory-co-uk) wrote :

I agree with the duplicate status for the most part, and I have managed to resolve my issues by booting via a non-LVM partition.

However, there are two additional points over and above simply that a core.img including lvm no longer fits in 64 sectors, which I think are worth emphasising.

1. The installer does not seem to anticipate this problem and so can leave the user in a sticky situation having mostly installed his OS

2. The man page and usage for grub-install lists options --core-compress and --modules. The former definitely doesn't work, and the latter doesn't appear to work as advertised.

Thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.