Bug 160365 – emerge grub can render a system unbootable

• Product: Gentoo Linux
• Status: VERIFIED DUPLICATE

[Description Tom Felker 2007-01-06 07:03:32 UTC]

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.

[Comment 1 Jakub Moc (RETIRED) 2007-01-06 09:11:34 UTC]

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

[Comment 2 Tom Felker 2007-02-15 02:37:39 UTC]

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.

[Comment 3 Jakub Moc (RETIRED) 2007-02-15 07:26:43 UTC]

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

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

[Comment 4 Tom Felker 2007-02-15 08:57:38 UTC]

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.

[Comment 5 Jakub Moc (RETIRED) 2007-02-15 09:01:07 UTC]

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