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:
How did you run grub2-mkconfig and how did it fail?
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.
Sounds like your problem is with grubby, not grub2-mkconfig.
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.
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.
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.