Bug 137829 - (IT_53176) rpm -F on kernel-smp removes kernel packages
rpm -F on kernel-smp removes kernel packages
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On: 163282
Blocks: 156320 156322
  Show dependency treegraph
 
Reported: 2004-11-01 16:09 EST by Johnray Fuller
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2005-744
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 13:20:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Replace --freshen with popt exec that upgrades by pkg name (2.24 KB, text/plain)
2004-11-09 18:58 EST, Jeff Johnson
no flags Details
Updated freshen script allows (passing of root= flag) (1.70 KB, text/plain)
2004-11-15 17:00 EST, Johnray Fuller
no flags Details
updated freshen script. (1.93 KB, text/plain)
2005-02-08 09:23 EST, Johnray Fuller
no flags Details

  None (edit)
Description Johnray Fuller 2004-11-01 16:09:07 EST
Issue I:

Under as2.1 if you have kernel, kernel-smp, and kernel-enterprise on
the same system, you can do:

rpm -Fvh kernel-smp-<more-recent-version>

and only the smp kernel will be upgraded.

On RHEL3 (with vanilla, smp, and hugemem kernel) if you do the same,
you will get kernel and kernel-hugemem REMOVED, which is absolutely
not the behavior we want.

Issue II:

The version of rpm in our AS2.1 distros are 4.0.4-*. On rhel3 its
4.2.2-*.  This is not a major release, and as such this kind of
behavior should not be breaking.

I've checked the man pages.  There is no mention of the kernel anywhere.

I've grep'd for kernel in /usr/share/doc/rpm-4.2.2.

I've read through the release notes for RHEL3 at
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-x86/

None of these resources mentions this change in behavior.  We rely on
this behaviour.  We should not have to re-engineer our upgrade process
due to an undocumented change in the distribution that occured without
warning to us.
Comment 1 Jeff Johnson 2004-11-09 18:55:56 EST
Appended is a freshen.sh script that appears to solve the problem.
Comment 2 Jeff Johnson 2004-11-09 18:58:02 EST
Created attachment 106381 [details]
Replace --freshen with popt exec that upgrades by pkg name

This is basically the way that --freshen was implemented in rpm-3.0.4
and earlier.
Comment 4 Johnray Fuller 2004-11-12 16:19:22 EST
Is there a chance of "return of the RHEL 2.1 behavior" for -F? If not,
why?

Thanks,
J
Comment 8 Johnray Fuller 2004-11-15 17:00:11 EST
Created attachment 106756 [details]
Updated freshen script allows (passing of root= flag)

This version of the freshen script enables the passing of the root= flag in RPM
as required by the customer's installation scripts.
Comment 9 Johnray Fuller 2004-11-22 14:53:48 EST
I have the follwoing feedback about the freshen script:

"The pn-freshen script works, but before it is included into a future
rpm package, please observe the following loop (lines 47 to 69)

for fn in $*; do
   # If not a file, just pass to upgrade.
   [ ! -f $fn ] && Uargs="$Uargs $fn" && continue

   # For all occurences of identically named packages installed ...
   N="`$rpmq  -qp --qf '%{NAME}' $fn`"
   NVR="`$rpmq $rootopt -qa $N`"

   # ... special case kernel packages
   case $N in
   kernel*)
# ... if none installed, just pass the filename to -U
#[ "$NVR" = "" ] && Uargs="$Uargs $fn" && continue
       [ "$NVR" = "" ] && continue

# ... else erase the old package(s) before installing the new package.
eargs="$eargs $NVR"
iargs="$iargs $fn"
;;
   *) Uargs="$Uargs $fn";;
   esac

done


The query of the package %{NAME} and matching it against the installed
database by doing:

NVR="`$rpmq $rootopt -qa $N`"

causes an open, lookup, and close for every package, not just for
kernel packages.  This will slow down our upgrade process as the
distribution gets older and more packages have been updated.  This
needs to be sped up."
Comment 10 Johnray Fuller 2004-11-22 14:56:01 EST
Here is some additional feedback:

"1> I suspect it could be mainly alleviated by moving the assignment
of $NVR inside of the "case $N" statement's "kernel*)" condition since
it doesn't need to be assigned unless $N ~= /^kernel/. (see above)

2> The script should also probably not check for "kernel*" but be
refined to a list of provides so that "kernel-utils",
"kernel-headers", etc. don't get caught in this un-necessary extra
work.  Perhaps the cases should be "kernel" "kernel-smp"
"kernel-hugemem", or should just include logic to ensure that both
"kernel" and "kernel-<something>" are provided."

J
Comment 11 Johnray Fuller 2005-01-10 12:15:29 EST
 Feedback from customer:

Back to the original complaint:

The script provided does the following incorrectly:

1) If someone tries to install the same version, the rpmi will fail, but the
rpme will be run anyway.  an && needed to be added between the commands to fix
this.  This means that if a system has more than one kernel, it can be removed
unintentionally.  I.e. if kernel and kernel-smp is installed, if rpm -F
<same_kernel_version>.rpm is run, then since the kernel-smp has the same
provides as kernel, kernel will be removed.  
2) If it is used with the -F option, it will install non-kernel packages
indiscriminantly.
3)  If it is used with -U and a kernel package that is not installed already, it
will not install the kernel.
4) It will fail on packages like kernel-utils that have dependancies if they are
not satisfied because they match kernel*.
5) It is slow.  The rpm database should only be checked for packages that match
kernel, kernel-smp, or kernel-enterprise.  This speeds it up tremendously.

We have fixes in place here for all of these problems.  Please confirm that
whoever is folding this into the main rpm distribution knows about these and can
make sure that the same issues will not be present in any released versions of RPM.

-Peter
Comment 12 Johnray Fuller 2005-01-10 12:21:28 EST
One other important issue witht he freshen.sh that is currently implemented.
Upon successful completion, it can return 1 to $? instead of 0.

Removing the last line of the script seems to resolve this, but I am not sure if
that is the best way. Here is the line that was removed:

[ "$Uargs" != "" ] && $dbg $rpmi -U $opts $Uargs

The shell variable is used to determine successful completion of the RPM
commands, so it is important $? be 0 upon successful completion.

J
Comment 13 Johnray Fuller 2005-02-08 09:23:32 EST
Created attachment 110799 [details]
updated freshen script.
Comment 14 Johnray Fuller 2005-02-08 09:25:05 EST
Attaching a version of the script that addresses the above concerns. Can this
version replace the previou version and be included as an addon?
Comment 15 Florian La Roche 2005-03-13 16:08:50 EST
Patch seems to be in RHEL3U5, putting this into modified state.
Comment 31 Red Hat Bugzilla 2005-09-28 11:14:00 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-602.html
Comment 32 Red Hat Bugzilla 2005-10-05 13:20:45 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-744.html

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