preupgrade grub2 failed: now can't boot

[Greg Woods]

On Wed, 2012-02-08 at 13:36 -0500, sean darcy wrote:

> Almost all (all?) users of preupgrade are using grub1.
> 
> As I understand it, most (all?) grub1 systems have the first partition 
> starting at 63.
> 
> Any system with a first partition starting at 63 will be bricked if it 
> runs preupgrade to F16.

This last part seems not to be true. Someone else pointed out that there
is a way to force grub2 to install on a disk with only 63 free blocks at
the beginning, as that was the case with my desktop that I upgraded
F14->F15->F16. It initially booted into F16 just fine. The problem was
that I could then not modify the grub configuration; whenever I tried, I
got the "embedding area is too small" error. Even something as simple as
increasing the grub timeout was not possible.

I expect the way to "force" it to install in a 63 block embedding area
will be kludgy in some way and sooner or later it will bite you in the
ass, so I think eventually you will want to repartition the disk so that
it has a 2048 block embedding area.

My experience with doing that was variable. When I tried this on my
wife's desktop, where the first partition was root, I was able to dump
and restore and complete the upgrade, but I ended up with a system that
I could not update. I got a lot of bizarre errors from "yum update"
saying "you should report these errors". But I'm using at least one
third-party repo (rpmfusion) so I expect my system is considered
"tainted" for this. 

On my Dell laptop, where the first partition is a small partition that
just has some Dell utilities for Windoze on it, it was easy to dump,
repartition, and restore, and everything worked after that.

Except for one more problem. I have always created /var as a separate
partition, so if something goes bonkers logging (which I have seen more
than once), it won't fill up the root partition. That's what /var is
for, right? And yet, upgrading from F15 to F16 always fails if /var is a
separate partition; you get an error about not being able to find the
RPM database. In every case, I had to put the /var files back onto the
root partition to get the upgrade to work.

All in all, the upgrade to F16 was by far the most difficult Fedora
upgrade I have ever done.

--Greg