Description of problem: up2date shows installed kernel errata as still applicable. Version-Release number of selected component (if applicable): up2date-4.0.1-1 How reproducible: Install RHBA-2003:308 on a RHEL3 box with up2date -u, run up2date -p, then run up2date Actual results: up2date -l (and gui) shows: Name Version Rel ---------------------------------------------------------- kernel 2.4.21 4.0.1.EL i686 Expected results: No errata apply Additional info: rpm -q kernel kernel-2.4.21-4.EL kernel-2.4.21-4.0.1.EL
Note: RHN website shows the errata as installed.
I wondered about this when I saw it. I couldn't remembered if we ever fixed this issue, which is related to the older kernel being installed still, so up2date thinks we still need the new one.
Same type of thing occuring, however the kernel on mine also shows obsolete. This is impacting a customer as well, and he would like to know an estimated time for this to be fixed.
I'll add a "METOO" to this bug. This little buglet breaks "up2date -u" which, er... is "unpleasant" for us customers ;-) FWIW, bug 109012 is a dupe of this as well.
*** Bug 109012 has been marked as a duplicate of this bug. ***
Just enquiring, is there an ETA for the fix? Was this fixed by the by version 4.0.1-1? Status of this bug is currently NEW.
*** Bug 110961 has been marked as a duplicate of this bug. ***
As 110961 has been marked closed and marked as a duplicate of this, I think it relevant to add my "me too" since my problem has a slightly different flavour that maybe requires a seperate bug or sheds a different light on the problem. If up2date has a valid update to an RPM that was previously installed/tracked via up2date, but the RPM available via RHN has been superceded by an even newer version that I installed manually on my servers from a different source, I get a similar error: Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: package spamassassin-2.60-1 (which is newer than spamassassin-2.44- 11.8.x) is already installed
This problem still occurs with kernel-2.4.21-4.0.2.EL update from RHN. All you have to do is install RHEL3, register with RHN, and run up2date.
I am still having this problem. I wonder if it's a bug because the release ends in EL? Is there some check that expects release numbers to be numeric? % rpm -q kernel kernel-2.4.21-4.EL kernel-2.4.21-4.0.1.EL kernel-2.4.21-4.0.2.EL % up2date -u -f Fetching package list for channel: rhel-i386-es-3... ######################################## Fetching Obsoletes list for channel: rhel-i386-es-3... Name Version Rel ---------------------------------------------------------- kernel 2.4.21 4.0.2.EL i686 Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: package kernel-2.4.21-4.0.2.EL is already installed
This is fixed by up2date-4.2.5-1 - or the new kernel numbering schmeme
Yup.. Tried the following yesterday after Update 1 came out... up2date -u up2date up2date -u yields in the new 2.4.21-9 kernel being installed and updted sans barfing.
Fixed by errata RHBA-2003:377
Sorry, this may fix the problem wrt the kernel packages but it does not fix the problem wrt other packages (spamassassin). See my comment in bug 110961 (marked as a duplicate of this). That is, I get an error running up2date -f because I have a newer version of a package installed than is available on RHN. IMHO, because the package I have installed is newer than that on RHN, up2date should just ignore the RHN package or possibly a output a warning for the paranoid - not abort in failure. Both the kernel and spamassassin are marked to be skipped unless forced (so plain up2date works) and "update -f kernel" will update the kernel. But plain "up2date -f" will not update the kernel because of the conflict with spamassassin. IMHO this is a bug because if the packages marked to be skipped is large (because I am paranoid and don't trust RHN not to break my system so have elected for critical package updates to be forced manually), updating becomes a painful exercise since I need an "force all but <package>" option for up2date to get around this buglet. Hence why up2date should simply skip such conflicts.