Red Hat Bugzilla – Bug 173969
kernel(-devel?) rpm install messes badly with grub.conf
Last modified: 2008-03-09 18:26:07 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217 Description of problem: Installation of kernel rpms does unnecessary damage to grub.conf. During install of kernel and kernel-devel it would appear that kernel rpm almost does the right thing and just inserts 4 lines into grub.conf and makes it the default boot. But subsequently (kernel-devel I think) mangles grub.conf quite badly. It takes the liberty of totally removing the original kernel entry (yikes! no fallback), removes a whole lot of comment lines (thanks, very clever!), and removes entire alternate boot entries. Moreover, unlike standard rpm procedure, it doesn't create anything like a grub.conf.rpmsave. Version-Release number of selected component (if applicable): kernel-2.6.13-1.1532_FC4 How reproducible: Always Steps to Reproduce: 1.cp /boot/grub/grub.conf /tmp 2.rpm -Fv kernel-2.6.13-1.1532_FC4.i686.rpm kernel-devel-2.6.13-1.1532_FC4.i686.rpm (...) 3.diff /boot/grub/grub.conf /tmp 4.ls /boot/grub/grub.conf.rpmsave Actual Results: 1. 2. 3. lots of horrible stuff 4. /boot/grub/grub.conf.rpmsave: No such file or directory Expected Results: 1. 2. 3. Essential changes only - new entry tacked onto end of grub.conf, and with only the "default=N" line changed. 4. grub.conf.rpmsave Additional info: Perhaps each boot configuration should be stored in separate files instead of single grub.conf, then could easily add/delete new entries and manipulate the default with symlink (or something). I detest programs which attempt to alter manually edited configs. Last bad case of this was kudzu and modules.conf - kudzu certainly managed to mangle modules.conf horribly. But it is often not so bad to tack supplementary stuff onto the end of a file (rather than insert like kernel rpm does). However the "default=N" line would be a problem unless grub would interpret "default=-1" as the last entry, in which case everything would be 100% hunky-dory all of the time. Even better, if the default wasn't -1 then that would mean that user doesn't want new kernel to boot by default. Brilliant. But, I would have thought that creating a grub.conf.rpmsave would be a rather polite thing to do regardless.
Forgot to mention, but kernel upgrade also removes previous content of /boot. That is really terrible. Wouldn't it be better to have some utility run on n'th subsequent reboot, or at some future time, asking if it is ok to remove old content of /boot. But I don't think they ever need removing because /boot will have enough room and the number of kernel upgrades will be lowish (for lifetime of "product"). And anyone who does a lot will obvious have a capability to clean out old /boot contents.
installation of the -devel packages doesn't touch grub at all. any changes to grub.conf the kernel installation process makes are done with 'grubby' provided by the mkinitrd package. you didn't include any example of what the broken grub.conf looked like, so it's tough to diagnose what went wrong here.
Don't use rpm -F or rpm -U on the kernel, use rpm -i.
(In reply to comment #3) > Don't use rpm -F or rpm -U on the kernel, use rpm -i. But even if you do that then comment lines get dropped from grub.conf. Therefore this bug is being reopened BECAUSE THE BUG HAS NOT BEEN RESOLVED.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
no info
Fedora Core 4 is no longer maintained. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.