Bugzilla Bug 160365

After grub got updated (to grub-0.97-r3) as part of an emerge -uv world, my
system could not boot.  It would just display "GRUB" with no prompt or menu.  I
had to recover by booting from a CD, chrooting into my system, running grub and
doing "root (hd0,0)" and "setup (hd0)".

Reproducible: Didn't try

Steps to Reproduce:
I haven't actually tried this, but it should illustrate what (I think) is going
on:

1.  "emerge grub" on a clean system
2.  install grub on the MBR
3.  "emerge grub" again
4.  "emerge grub" yet again
5.  cat /dev/zero > /boot/zero; rm /boot/zero 
6.  system will fail to boot

Actual Results:  
1.  /boot/grub/stage2 is created, among other things.

2.  The addresses of the blocks of /boot/grub/stage2 are recorded to the master
boot record.  The boot process will use /boot/grub/stage2

3.  /boot/grub/stage2 is renamed to stage2.old.  The boot process will use
/boot/grub/stage2.old (since it uses addresses, not filenames, to find stage2).

4.  /boot/grub/stage2 is renamed to stage2.old, which causes the original
stage2.old's inode to be unlinked.  The boot process will use the now freed
blocks where the original /boot/grub/stage2.old lived.  This will only work
until...

5.  ...these blocks get overwritten.

6.  Now the system can't boot.


Expected Results:  
When installing grub, stage2 (and any other files to which this applies) should
be renamed in such a way that they are never overwritten.  For example,
stage2.old.1, stage2.old.2, etc.  This would allow the system to boot using the
old grub.  The failure mode would be /boot filling up, instead of the system
becoming unbootable.

In the long term, it would make sense for there to be a config file specifying
how grub should be installed in the MBR, which could be run after grub
upgrades.

*** This bug has been marked as a duplicate of bug 98768 ***

I'm reopening this bug because the one it got duped to is, in my opinion,
unfairly resolved as wont fix, and I can't change that.  It's a fairly serious
bug, and needs looking into.

In bug 98768, putting /boot/grub under config protect was suggested.  I agree
this isn't a good idea.  However, some protection is necessary.

Either there needs to be a config file that gives enough information for the
emerge system to install grub completely, or the emerge system needs to leave
/boot/grub alone.  It's very bad to leave grub in a half-installed state that
can leave the system unbootable.

Sorry, noone has changed their mind over past 4 months.

*** This bug has been marked as a duplicate of bug 98768 ***

This is going to feel so good...

The only reason it's even remotely acceptable for the second grub update to
non-deterministically break your system is because only about five people have
ever bothered put up with the constant breakages every time you upgrade
anything for long enough to have upgraded grub twice.  But hey, if you guys
don't care, why should I?  Have fun diagnosing the failures this bug will
cause, and good luck winning back the users who give up on Gentoo because their
system broke, they don't know why, and those who do won't fix it.

Please, move your rants to the original bug, this is a dupe.