Bug 828109 - grub2, please keep backups of grub.cfg when generating a new config
grub2, please keep backups of grub.cfg when generating a new config
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-04 05:13 EDT by Jonathan
Modified: 2012-06-06 13:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-06 06:55:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan 2012-06-04 05:13:41 EDT
Description of problem:
grub2-mkconfig failed when updating grub.cfg, leacing a useless grub.cfg and this was not noticed before reboot, rendering the systems with only grub prompt. Having a backup grub.cfg ("last known working") would have saved a lot of trouble in booting the system. As it was, I had to find all UUID / luks / lvm manually.


Version-Release number of selected component (if applicable):
grub2 F17

How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:
only recent grub.cfg availavbe

Expected results:
keep grub.cfg.bak / grub.cfg.old / grub.cfg.lasb-boot as fallback option

Additional info:
Comment 1 Mads Kiilerich 2012-06-06 05:48:51 EDT
How did you run grub2-mkconfig and how did it fail?
Comment 2 Jonathan 2012-06-06 06:28:50 EDT
I didn't run grub2-mkconfig.

Without being fully certain, I think it may have been run after using yum to meddle with installed kernels.

Having just preupgraded the system from F16 to F17 and booted into F17, I used yum to remove an obsoleted F16 kernel.

I didn't notice a problem until I rebooted the system. 

Grub left me at the grub prompt and investigations of grub.cfg showed that there were no kernel parameters (like luks / UUID ...) in it.

Having a backup of previous grub.cfg could have saved a lot of time and pain getting the system running again so I could recreate grub.cfg by grub2-mkconfig.
Comment 3 Vladimir Serbinenko 2012-06-06 06:43:23 EDT
Sounds like your problem is with grubby, not grub2-mkconfig.
Comment 4 Mads Kiilerich 2012-06-06 06:55:25 EDT
grub2-mkconfig is not run when installing new kernels, so whatever the problem was it wasn't grub.

grubby can do many crazy things, but I haven't seen it mangle existing boot entries.

preupgrade to f17 has some bugs that might have created a grub.cfg without any entry for f17. Removing all f16 kernels could thus have left you without any working entries in grub.cfg. grubby will however refuse to remove the last entry because it knows that it might be needed as template.


You might have hit a bug somewhere, but we will need to know how it can be reproduced and have a copy of the invalid grub.cfg ... and how it looked before it was spoiled. I assume you can't provide that, and we thus can't do more to fix that.

You requested a specific workaround instead of a fix of the real problem. That is not how it works. Especially not when the workaround you request wouldn't have helped you anyway.
Comment 5 Jonathan 2012-06-06 12:40:44 EDT
You are right that I cannot provide more info to help find the problem as the failed grub.cfg is overwritten.

You are also right that it was probably an artefact from a failed preupgrade that might never happen again that did indeed fail to adress the F17 kernel in grub.

I am not requesting a specific workaround in my point of view, I am suggesting that a backup plan (in this case a backup of the previous functioning .cfg) could be useful in case something unforseen happens, like a bug, or something. Grub seems to be vital to a system and could have extra security. The "requested workaround" would have contained all information to get the system running again within a minute with just a change of vmlinuz and initramfs.

Of course, if you plan to write completely bug free software in the future, this is just wasted effort, but the plan to deliver free of bugs has not been on target lately, has it? 

Your arrogant attitude does not impress me much, but I'm sure you can find another audience for it who perceive you differently.
Comment 6 Vladimir Serbinenko 2012-06-06 13:29:40 EDT
While I agree that Mads reaction was a little bit precipitated, something like this has to be filed as feature request, not as a bug. Bugs are handled with different attitude and sometimes even by different people.

Note You need to log in before you can comment on or make changes to this bug.