Red Hat Bugzilla – Bug 239013
xen rpms don't cleanup everything when removed
Last modified: 2007-11-30 17:12:03 EST
Description of problem: I installed fedora core 6 and included the virtualization package group at install time. After experimenting a bit, I decided I didn't need xen, so I used yumex to remove all the xen related packages. Following that, any new kernel updates no longer properly updated my /boot/grub/grub.conf file. Eventually discovered that /etc/sysconfig/kernel still had a line that said DEFAULTKERNEL=kernel-xen. Seems like that should have been cleaned up by the rpms when I removed kernel-xen and friends. Version-Release number of selected component (if applicable): several updates spanned the time where this happened before I found the problem, so hard to say exactly which version I had when I removed xen. How reproducible: Two different machines have demonstrated the same kernel update problem after removing xen. Steps to Reproduce: 1. see description Actual results: Expected results: Additional info:
None of the Xen packages ever touch the /etc/sysconfig/kernel file. This setting is defined by Anaconda itself during the initial install process. Xen RPMs should not try to second guess what to put it that file when being removed.
#1, Why didn't you reassign this bug to Anaconda instead of closing this? I am reopening and reassigning to Anaconda.
anaconda isn't involved at all with the removal of the packages. /etc/sysconfig/kernel is originally created there, sure, but it's not like we can go back and change it.
Seems to me if you wanted to make the process less confusing, instead of having anaconda create the sysconfig file, you'd add a xen-sysconfig-kernel.noarch.rpm to the distribution, and teach it to create the file, and when uninstalled change the name of the default kernel in the file. Then anaconda would have less work to do since it wouldn't even have to think, it would just install the rpm, and removing all the xen rpms would actually fix the problem. I have no idea what bug category to file this suggestion under however :-).