Bug 735259

Summary: after updating grub2, booting drops me to grub rescue prompt
Product: [Fedora] Fedora Reporter: Andre Robatino <robatino>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: allison.karlitskaya, awilliam, bruce, collura, dennis, erinn.looneytriggs, joachim.backes, kalevlember, lkundrak, mads, markmc, martin, mishu, mrunge, mszpak, pborelli, pedrosoriarodriguez, pgueckel, pjones, ricardo.arguello, rjones, satellitgo, stevenward666, tomh0665
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: grub2-1.99-6.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-07 18:15:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 713564    
Attachments:
Description Flags
grub.cfg generated by 'grub2-mkconfig -o /boot/grub2/grub.cfg' from grub2-1.99-2.fc16
none
Patch to fix upgrades from grub2 < 1.99-4 none

Description Andre Robatino 2011-09-02 03:04:17 UTC
Description of problem:
After updating to grub2-1.99-1.fc16.x86_64, and rebooting, am dropped to grub rescue prompt:

GRUB loading.
Welcome to GRUB!

error: file not found.
Entering rescue mode...
grub rescue>

I found that this version had been obsoleted by grub2-1.99-2.fc16.x86_64, so booted into rescue mode using the 16-Beta.TC1 x86_64 DVD, and updated to the new version from Koji. No change. Trying to recreate grub.cfg with "grub2-mkconfig -o /boot/grub2/grub.cfg" doesn't help.

Version-Release number of selected component (if applicable):
grub2-1.99-2.fc16.x86_64

How reproducible:
always

Comment 1 Andre Robatino 2011-09-02 03:12:50 UTC
Created attachment 521130 [details]
grub.cfg generated by 'grub2-mkconfig -o /boot/grub2/grub.cfg' from grub2-1.99-2.fc16

Comment 2 Andre Robatino 2011-09-02 04:05:42 UTC
Tried downgrading to the original version (grub2-1.99-0.2.fc16) and recreating grub.cfg again. Still no luck.

Comment 3 Andre Robatino 2011-09-02 04:54:04 UTC
Additional info: This is a VirtualBox 4.1.2 guest. I don't know if that's relevant.

Comment 4 Steve 2011-09-02 06:46:09 UTC
I can confirm this bug.

Comment 5 Iain Arnell 2011-09-02 06:51:49 UTC
Not just an issue under VirtualBox. Also occurred for me with real hardware when updating from grub2-1.99-0.2.fc16 to grub2-1.99-1.fc16. And solved for me by running "grub2-install /dev/sda" after booting rescue image, mounting filesystems, chroot, etc.

Comment 6 Steve 2011-09-02 07:44:04 UTC
(In reply to comment #5)
> Not just an issue under VirtualBox. Also occurred for me with real hardware
> when updating from grub2-1.99-0.2.fc16 to grub2-1.99-1.fc16. And solved for me
> by running "grub2-install /dev/sda" after booting rescue image, mounting
> filesystems, chroot, etc.

Yes, this works!

Comment 7 Andre Robatino 2011-09-02 07:56:55 UTC
"grub2-install /dev/sda" works for me as well.

Comment 8 Andre Robatino 2011-09-02 09:06:10 UTC
*** Bug 735301 has been marked as a duplicate of this bug. ***

Comment 9 Tom H 2011-09-02 09:42:20 UTC
(The attachment refers to "grub2-1.99-2.fc16" but the latest version is grub2-1.99-1.fc16)

I encountered the same problem.

Even though a "set" listed prefix and root using (hdX,Y) rather than the (hdX,gptY) with which "ls" listed the partitions, I could run "ls (hd0,2)/boot/grub2/".

"/boot/grub2/" was empty except for "grub.cfg", "device.map.anacbak", and "locale/".

"grub2-install /dev/sda /dev/sdb" while booted from Anaconda's rescue mode repopulated "/boot/grub2/".

I pointed out on the "test" list that there's a part of the preuninstall scriplet that deletes all ".mod", ".img" and ".lst" files from "/boot/grub2/" that might somehow be responsible for the more or less empty "/boot/grub2" and the "file not found" message.

Comment 10 Andre Robatino 2011-09-02 09:59:47 UTC
(In reply to comment #9)
> (The attachment refers to "grub2-1.99-2.fc16" but the latest version is
> grub2-1.99-1.fc16)

https://admin.fedoraproject.org/updates/grub2-1.99-1.fc16 (latest in updates-testing), obsoleted by

https://admin.fedoraproject.org/updates/grub2-1.99-2.fc16

The changelog in grub2-1.99-2.fc16 shows

* Thu Sep 01 2011 Peter Jones <pjones> - 1.99-2
- Require os-prober (#678456) (patch from Elad Alfassa)
- Require which (#734959) (patch from Elad Alfassa)

* Thu Sep 01 2011 Peter Jones <pjones> - 1.99-1
- Update to grub-1.99 final.
- Fix crt1.o require on x86-64 (fix from Mads Kiilerich)
- Various CFLAGS fixes (from Mads Kiilerich)
  - -fexceptions and -m64
- Temporarily ignore translations (from Mads Kiilerich)

Comment 11 Andre Robatino 2011-09-02 11:04:12 UTC
I noticed that the path for grub2-install and related commands changed from /usr/sbin in 1.99-0.2.fc16 to /sbin in 1.99-1.fc16 and 1.99-2.fc16. Maybe something still refers to the old location so grub2-install is not found?

Comment 12 Mads Kiilerich 2011-09-02 14:18:24 UTC
There are two issues:

First, when the new grub2 is installed it runs:
    # Determine the partition with /boot
    BOOT_PARTITION=$(df -h /boot |(read; awk '{print $1; exit}'))
    # Generate core.img, but don't let it be installed in boot sector
    grub2-install --grub-setup=/bin/true $BOOT_PARTITION
That generates new /boot/grub2/*.mod files, but they are not compatible with the old grub2 boot sector and will thus fail with 
    error: symbol not found: 'grub_divmod64_full'.
The assumption that modules should be updated without updating the boot sector is wrong.
(See also https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/768716 ... but Fedora is not Debuntu and packages shouldn't do sysadmin stuff.)

Second, when the old grub2 is removed it runs:
    # XXX Ugly
    rm -f /boot/grub2/*.mod
and it will remove the modules that just has been created (and which clobbered the modules that corresponds to the old installed boot sector).


I guess the solution is:
1: not run any grub install commands at package install. 
2: move the ugly clean-up to "$1" = 0 so it no longer is run un package uninstallation. That should however be done as a fix in the old package we are removing. We have lost.

A workaround could perhaps be to take a backup of the old modules in %post and restore it again in %posttrans after the old %postun has run?

Comment 13 Peter Jones 2011-09-02 14:38:22 UTC
I guess the solution is:
1: not run any grub install commands at package install. 

We already don't, and haven't in a while.

2: move the ugly clean-up to "$1" = 0 so it no longer is run un package
uninstallation. That should however be done as a fix in the old package we are
removing. We have lost.

Yeah, this is the answer.  Thankfully this will only effect alpha testers; everybody else should get a newer package on installation. So with that in mind, I think we can note this and how to fix it in "common bugs" and not do the workaround in the package.

Comment 14 Mads Kiilerich 2011-09-02 15:10:11 UTC
(In reply to comment #13)
>> I guess the solution is:
>> 1: not run any grub install commands at package install. 
> 
> We already don't, and haven't in a while.

We agreed on irc that -2 still do that - but that wasn't the intention and it will be fixed soon (in -3?).

Comment 15 Fedora Update System 2011-09-02 16:33:00 UTC
grub2-1.99-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub2-1.99-4.fc16

Comment 16 Tom H 2011-09-02 17:04:48 UTC
I installed grub2-1.99-4 from koji and checked "/boot/grub2/" before rebooting to ensure that it was OK and it wasn't (in spite of the script cleanup, so my previous pointing at a possible culprit was wrong):

[root@localhost ~]# ls /boot/grub2/
device.map.anacbak  grub.cfg  grubenv  locale

[root@localhost ~]# yum history info 15
Transaction ID : 15
Begin time     : Fri Sep  2 12:47:52 2011
Begin rpmdb    : 412:6bb56d75e3c1b98083805efe746075886a08fe11
End time       :            12:47:59 2011 (7 seconds)
End rpmdb      : 415:f510d2196aa3acf91c898eca101105e81fa586d7
User           : root <root>
Return-Code    : Success
Command Line   : localinstall grub2-1.99-4.fc16.i686.rpm
Transaction performed with:
    Installed     rpm-4.9.1.1-2.fc16.i686 @fedora
    Installed     yum-3.4.3-4.fc16.noarch @anaconda-0
Packages Altered:
    Updated     grub2-1:1.99-1.fc16.i686      @?updates-testing
    Update            1:1.99-4.fc16.i686      @/grub2-1.99-4.fc16.i686
    Dep-Install lvm2-2.02.86-5.fc16.i686      @fedora
    Dep-Install lvm2-libs-2.02.86-5.fc16.i686 @fedora
    Dep-Install os-prober-1.48-1.fc16.i686    @fedora

[root@localhost ~]# yum info grub2
Name        : grub2
Arch        : i686
Epoch       : 1
Version     : 1.99
Release     : 4.fc16
Size        : 4.8 M
Repo        : installed
From repo   : /grub2-1.99-4.fc16.i686

[root@localhost ~]# rpm -q --scripts grub2
postinstall scriptlet (using /bin/sh):
if [ "$1" = 1 ]; then
/sbin/install-info --info-dir=/usr/share/info /usr/share/info/grub2.info.gz || :
/sbin/install-info --info-dir=/usr/share/info /usr/share/info/grub2-dev.info.gz || :
fi
preuninstall scriptlet (using /bin/sh):
if [ "$1" = 0 ]; then
/sbin/install-info --delete --info-dir=/usr/share/info /usr/share/info/grub2.info.gz || :
/sbin/install-info --delete --info-dir=/usr/share/info /usr/share/info/grub2-dev.info.gz || :
fi

Comment 17 Adam Williamson 2011-09-02 18:16:25 UTC
Discussed at 2011-09-02 blocker review meeting. Accepted as a blocker under criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" - it's a slight stretch, but if we don't take -4 into Beta, grub2 is effectively a 'time bomb': the first post-install update will break the system and there'll be nothing we can do about it. So in effect we would install a system which cannot be safely updated.

Comment 18 STEVEN WARD 2011-09-02 19:16:39 UTC
Hi all,
      I'm suffering from the grub2 bug as well.
I have used my Fedora 16 Alpha DVD into rescue mode,and then chrooted with "chroot /mnt/sysimge" I then ran "grub2-install /dev/sda"

The first re-boot worked after I did that,but with the second re-boot,I get this error message now:

"error: ELF header smaller than expected.

Any ideas on how to resolve this one? 

Regards,
        STEVE555

Comment 19 Peter Jones 2011-09-02 21:59:17 UTC
(In reply to comment #16)
> I installed grub2-1.99-4 from koji and checked "/boot/grub2/" before rebooting
> to ensure that it was OK and it wasn't (in spite of the script cleanup, so my
> previous pointing at a possible culprit was wrong):

This test plan won't work as such - -4 will prevent the problem from
happening in the future, but when you install -4, -3's %preun is running,
and that will cause the behavior you're seeing. In the future when there's
a -5, you shouldn't see the issue, because -4's %preun doesn't have the
problematic bits.

You should be able to test by following these steps (assuming x86_64):

1) install grub-1.99-4.fc16.x86_64.rpm
2) run grub2-install
3) validate that the files in /boot/grub2 are there and boot correctly
4) "rpm -Uvh --force grub-1.99-4.fc16.x86_64.rpm"
5) Inspect /boot/grub2/ to verify that it has the correct files.
6) reboot to make sure everything worked.

Comment 20 Tom H 2011-09-03 02:26:03 UTC
(In reply to comment #19)

Thanks. I realized after my previous comment (#16) that given that the 1.99-1 scripts had the "rm /boot/grub2/..." lines and that the 1.99-4 didn't have "grub2-install ...", the result that I got was normal.

I then did something silly. I ran "yum erase grub2" and "yum localinstall grub2-1.99-4.fc16.i686.rpm" without running "grub-install ..." first, so I started and ended up without a full "/boot/grub2/".

So I ran "grub2-install" and re-ran "erase&&localinstall" and everything was fine. 

I've now also run your "rpm -Uvh" from #19. All OK.

But I have a question:

Since "grub2-install" isn't run when grub2's upgraded, doesn't it mean that boot.img in the MBR, core.img in the bootbios partition, and the modules in "/boot/grub2/" aren't upgraded?

I can see from #12 that running "grub2-install --grub-setup=/bin/true" can lead to problems but shouldn't that mean that a full "grub2-install" should run when grub2's upgraded rather than no "grub2-install" at all? Otherwise the only files that upgraded are in "/etc/grub.d/", "/usr/lib/grub/", "/usr/lib/grub2/i386-pc/", and the "grub2-*" executables in "/sbin/" and "/usr/bin/".

I understand that you might not want to write to the MBR and the bootbios partition every time that grub2's upgraded but it seems weird that, if there are any new or updated modules, they'd be stored in "/usr/lib/grub2/i386-pc/" and not used.

Comment 21 Andre Robatino 2011-09-03 04:11:57 UTC
Would it be possible to have https://admin.fedoraproject.org/updates/grub2-1.99-1.fc16 removed from updates-testing? It currently has -1 karma (mine) and needs -3 to be unpushed. The other update ( https://admin.fedoraproject.org/updates/grub2-1.99-2.fc16 ) already has -3 which should be enough to get it unpushed, but given how buggy Bodhi is it's possible it might end up being pushed to updates-testing anyway.

Comment 22 Kalev Lember 2011-09-03 18:03:13 UTC
(In reply to comment #19)
> This test plan won't work as such - -4 will prevent the problem from
> happening in the future, but when you install -4 /.../

Peter, I believe it would be possible to fix it so that upgrades from
grub2 < 1.99-4 also work. If we don't fix it, then everybody who installs the Alpha release will get an unbootable system after the first upgrade.

Working on a patch now.

Comment 23 Kalev Lember 2011-09-03 19:09:50 UTC
Created attachment 521340 [details]
Patch to fix upgrades from grub2 < 1.99-4

This patch tries to work around the damage caused on upgrades, by first
backuping the files in %triggerun and later restoring them in %triggerpostun after the old packages's %preun has been run.

Comment 24 Kalev Lember 2011-09-03 19:44:37 UTC
*** Bug 735430 has been marked as a duplicate of this bug. ***

Comment 25 Artem S. Tashkinov 2011-09-03 20:04:42 UTC
My opinion on this issue:

Grub2 installation/update/removal shouldn't mess with the system in any way (because it's just not possible to understand how a user installed his bootloader - he might not have grub2 actually installed at all, or grub2 is installed manually using some weird configuration), that's it and during one Fedora release cycle, grub2 shouldn't be ever updated in a major way (which requires a rebuild of all grub2 modules).

Kernel version is already locked, I guess grub2 version should also be locked the same way.

Comment 26 Allison Karlitskaya 2011-09-03 20:36:04 UTC
I just hit this issue.  Here's how I repaired my affected system.  YMMV.

Boot up the live CD, open a terminal and become root.

 - mkdir /target
 - mount /dev/sda4 /target         # where /dev/sda4 is your root FS
 - cd /target
 - mount /dev/sda2 boot            # where /dev/sda2 is your /boot
 - mount -o bind /dev dev
 - mount -o bind /proc proc
 - mount -o bind /sys sys
 - chroot .
 - grub2-install /dev/sda          # your boot drive
 - exit
 - umount dev
 - umount proc
 - umount sys
 - umount boot
 - cd /
 - umount /target
 - reboot -f

Comment 27 Pedro 2011-09-04 15:31:28 UTC
I also experienced the problem described in this bug report.
The fix described in comment #26 worked for me, to get back a working system.

Comment 28 Kalev Lember 2011-09-04 23:04:44 UTC
pjones,

I am still thinking that we should work around the destructive %postun that the
older grub2 builds have. Could you please review my patch? Just looking for
your blessing, I can handle doing the builds.

Sorry for pushing like this, I am just worried that the longer we wait, the
more users are going to be hit by the bug. The current build in updates-testing
will render every freshly installed Alpha release unbootable on upgrade and I
would like to fix that.

In the mean time, if anyone wants to give a try to a test build that has my fix
applied, I'd be very grateful:
http://kalev.fedorapeople.org/grub2/

Comment 29 Andre Robatino 2011-09-04 23:25:22 UTC
(In reply to comment #28)

> In the mean time, if anyone wants to give a try to a test build that has my fix
> applied, I'd be very grateful:
> http://kalev.fedorapeople.org/grub2/

Works for me by downgrading to  grub2-1.99-1.fc16.x86_64 and then updating to grub2-1.99-4.fc16.kalev0.x86_64.

Comment 30 Tom H 2011-09-05 00:15:54 UTC
(In reply to comment #29)

> Works for me by downgrading to grub2-1.99-1.fc16.x86_64
> and then updating to grub2-1.99-4.fc16.kalev0.x86_64.

Same for me.

Comment 31 Jens Petersen 2011-09-05 04:24:58 UTC
If someone can give https://admin.fedoraproject.org/updates/grub2-1.99-4.fc16
one more karma it should get pushed into f16 stable at least and
prevent more people from hitting this nasty bug.

Comment 32 Joachim Backes 2011-09-05 05:14:15 UTC
I'm sorry, but does not work for me: Updating to  grub2-1.99-4.fc16.x86_64 and rebooting stops with the error: "file not found", and /boot/grub2 is almost empty.

Running grub2-install then solves this problem.

Comment 33 Andre Robatino 2011-09-05 05:22:27 UTC
(In reply to comment #32)
> I'm sorry, but does not work for me: Updating to  grub2-1.99-4.fc16.x86_64 and
> rebooting stops with the error: "file not found", and /boot/grub2 is almost
> empty.
> 
> Running grub2-install then solves this problem.

That's exactly what's expected to happen. See comment 19 for the proper testing procedure. (You can also use "yum reinstall grub-1.99-4.fc16.x86_64.rpm" to avoid rpm -Uvh --force.)

Comment 34 Joachim Backes 2011-09-05 06:28:59 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > I'm sorry, but does not work for me: Updating to  grub2-1.99-4.fc16.x86_64 and
> > rebooting stops with the error: "file not found", and /boot/grub2 is almost
> > empty.
> > 
> > Running grub2-install then solves this problem.
> 
> That's exactly what's expected to happen. See comment 19 for the proper testing
> procedure. (You can also use "yum reinstall grub-1.99-4.fc16.x86_64.rpm" to
> avoid rpm -Uvh --force.)

Following successfully all steps described in comment #19. I will raise the karma.

Comment 35 Kalev Lember 2011-09-05 14:54:12 UTC
Peter Jones,

You don't appear to be around and we need to get a fix out that properly
upgrades the version of grub2 that was shipped with Alpha. I'm going to 
just apply my patch; it has already been confirmed by two independent 
testers above. Please review it afterwards and modify to your needs.

This way, we can avoid breaking any more Alpha installations.

P.S. Don't get it the wrong way, it's a long weekend in the US and it's
perfectly understandable that you aren't working. Not trying to step on 
your toes, however, I believe it's provenpackagers' duty to help when we 
have issues like this that need to be addressed quickly and the primary 
packager isn't available.

Comment 36 Fedora Update System 2011-09-05 15:06:18 UTC
grub2-1.99-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub2-1.99-5.fc16

Comment 37 Mark McLoughlin 2011-09-05 15:39:47 UTC
The trigger appears to work for me too - updating from -1 to -5 left my system bootable

Comment 38 Marcin Zajaczkowski 2011-09-05 20:29:16 UTC
(In reply to comment #18)
> "error: ELF header smaller than expected.

I have the same problem even after grub2-isntall. The reason in my case was (not really sure why) empty grub.cfg (content was only in grub.cfg.rpmsave). grub2-mkconfig -o /boot/grub2/grub.cfg helped (copy .rpmsave file to original location should be also ok).

Comment 39 Erinn Looney-Triggs 2011-09-06 16:39:39 UTC
Hmm doesn't work for me. Did the steps outlined in 19, albeit with the -5 update, /boot/grub2 seems ok, well at least it has a fair number of files in it. Reboot, and I just get GRUB. 

My install is a bit different though, grub is not installed in the MBR but instead in /dev/sda3, so a grub2-install --force /dev/sda3 is necessary to install it. This all stems from trusted booting, a TPM, yadda yadda.

So has anyone tried installing in a partition instead of the MBR? Is it working for you? Any further advice?

-Erinn

Comment 40 Mads Kiilerich 2011-09-06 20:25:06 UTC
(In reply to comment #39)
> My install is a bit different though, grub is not installed in the MBR but
> instead in /dev/sda3, so a grub2-install --force /dev/sda3 is necessary to
> install it. This all stems from trusted booting, a TPM, yadda yadda.

Installing to partitions instead of MBR is not supported by grub2. Grub rejected to do it and you had to use the "just do what I say even though the tool knows that it doesn't work" switch.

The lack of partition install could be considered a regression and fatal failure and the end of the world, but that is a separate issue that should be discussed elsewhere. It certainly deserves a release note with big letters and a good explanation.

Comment 41 Erinn Looney-Triggs 2011-09-06 20:54:44 UTC
It may be a regression, fatal failure and/or the end of the world. However the fact of the matter is that having it on a partition worked until this update, and now it no longer works. If Fedora decides to support the use of grub in partitions, and by the way anaconda went initially they may even if grub2 does not support it, than this update breaking that may be a problem.

So though they may be separate issues they are interdependent to my mind.

Comment 42 Erinn Looney-Triggs 2011-09-06 21:36:42 UTC
Yeah and after checking it looks like --force is what anaconda is going to do: http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=9474d2c386aab25ede85a56a368e457c39e490ee 

So if this update doesn't work with grub2 written to a partition than it is a problem. Or, and as is usually the case, it could just be my system having issues. So again anyone out there installing grub2 to a partition, that has run into this issue, or not run into this issue?

-Erinn

Comment 43 Fedora Update System 2011-09-07 03:30:46 UTC
grub2-1.99-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 44 Andre Robatino 2011-09-07 03:37:30 UTC
Despite what Bodhi thinks, I see 0.2.fc16 in the stable repo, and nothing in updates-testing. So someone will probably need to manually get -5 into the stable repo. Reopening this until it's actually pushed.

Comment 45 Fedora Update System 2011-09-07 03:39:44 UTC
grub2-1.99-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 46 Andre Robatino 2011-09-07 03:53:12 UTC
Sorry, still don't see it.

http://download.fedora.redhat.com/pub/fedora/linux/development/16/source/SRPMS/

shows grub2-1.99-0.2.fc16, and

http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/16/SRPMS/

shows nothing. Used Shift-Reload to be sure.

Comment 47 Jens Petersen 2011-09-07 06:15:38 UTC
I think it is cool to have the triggers in place for testers now,
at least until Beta - but I am not sure we should ship them in F16 Final.

Comment 48 Andre Robatino 2011-09-07 09:00:05 UTC
Changing Status to RELEASE_PENDING (see comments in https://admin.fedoraproject.org/updates/grub2-1.99-5.fc16 ).

Comment 49 Richard W.M. Jones 2011-09-07 09:37:09 UTC
For reference, I was able to rescue my VM using virt-rescue.

I booted the rescue shell:

  # virt-rescue Nova

and in the rescue shell, mounted everything up:

  > mount /dev/vg_nova/lv_root /sysroot
  > mount /dev/vda2 /sysroot/boot
  > mount -o bind /dev /sysroot/dev
  > chroot /sysroot

then I ran grub2-install:

  > grub2-install /dev/vda
  Installation finished. No error reported.

then I exited virt-rescue and booted the VM
and thankfully it came up normally.

Comment 50 Andre Robatino 2011-09-07 18:15:56 UTC
Closing as it's finally in the repo now - see

http://download.fedora.redhat.com/pub/fedora/linux/development/16/

Comment 51 Adam Williamson 2011-09-07 23:33:48 UTC
andre: please leave the bodhi statuses as they are. there's a delay between it being 'pushed stable' and making it out to mirrors, as there has to be a tree compose and then a mirroring period, but it's still correct to close it at the time the update is pushed stable.

Comment 52 Andre Robatino 2011-09-07 23:42:45 UTC
The delay was caused by a Bodhi bug which lmacken had to work around manually. Also, my links above are to the master mirrors:

http://fedoraproject.org/wiki/Master_Mirror_Infrastructure_SOP

Comment 53 Fedora Update System 2011-09-14 20:28:43 UTC
grub2-1.99-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub2-1.99-6.fc16

Comment 54 Fedora Update System 2011-09-30 18:48:51 UTC
grub2-1.99-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.