Bug 108480 - up2date shows installed kernel errata as still applicable
up2date shows installed kernel errata as still applicable
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
: 109012 110961 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-29 17:50 EST by Matt Jamison
Modified: 2007-11-30 17:06 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-19 12:46:42 EST
Type: ---
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 Josef Komenda 2003-10-29 17:50:31 EST
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
Comment 1 Josef Komenda 2003-10-29 17:51:30 EST
Note: RHN website shows the errata as installed. 
Comment 2 Jay Turner 2003-10-30 08:51:35 EST
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.
Comment 3 Jp Robinson 2003-10-31 12:07:18 EST
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.
Comment 7 nathan r. hruby 2003-12-02 15:22:08 EST
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.
Comment 8 Adrian Likins 2003-12-18 13:47:30 EST
*** Bug 109012 has been marked as a duplicate of this bug. ***
Comment 9 greyhair 2003-12-31 05:46:53 EST
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.
Comment 11 Bill Nottingham 2004-01-07 13:55:39 EST
*** Bug 110961 has been marked as a duplicate of this bug. ***
Comment 12 Alex Schuilenburg 2004-01-07 14:06:53 EST
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
Comment 13 Glen A. Foster 2004-01-14 20:59:38 EST
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.
Comment 14 Peter Collinson 2004-01-16 10:19:22 EST
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
Comment 15 Peter Collinson 2004-01-17 06:11:05 EST
This is fixed by up2date-4.2.5-1 - or the new kernel numbering schmeme
Comment 16 nathan r. hruby 2004-01-17 08:56:42 EST
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.
Comment 17 Mike McLean 2004-01-19 12:46:42 EST
Fixed by errata RHBA-2003:377
Comment 18 Alex Schuilenburg 2004-01-19 21:12:33 EST
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.

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