Bug 101579 - bash %postun is trying to use bash in an erase and fails because bash is not there
bash %postun is trying to use bash in an erase and fails because bash is not ...
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
: 130460 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-04 09:19 EDT by James Olin Oden
Modified: 2007-03-27 00:08 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-02 13:28:06 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 James Olin Oden 2003-08-04 09:19:08 EDT
Description of problem:

Bash has a postuninstall script that uses bash.  Of course, in %postun
in an erase for bash, bash would not exist.  This causes the postuninstall
script to fail (as the interpreter cannot be found).

Here is a copy of the %postun scriptlet:

   if [ "$1" = 0 ]; then
       grep -v '^/bin/bash2$' < /etc/shells | \
       grep -v '^/bin/bash$' | \
       grep -v '^/bin/sh$' > /etc/shells.new
       mv /etc/shells.new /etc/shells
   fi

Which basically says if I am being run in an erase, then remove bash
from /etc/shells.  Problem is bash is required to run this script and
bash is gone at this point.  I would suggest moving this to a %preun
script, so that bash will still be to run this code.

Version-Release number of selected component (if applicable):
2.05b-20, 2.05b-20.1

How reproducible:
Always.

Steps to Reproduce:
1.  Remove bash.
    
Actual results:
It fails in %postun.

Expected results:
It should not fail.

Additional info:
I found this while testing out up2date's rollback code.  I had updated my system
using up2date (with it configured to support rollbacks so the proper repackaging
occured), and then I ran:

   up2date --undo

When I did this, as it was rolling back the updates (bash being one of them), 
bash failed in its %postun scriptlet.  Very bizare, for two reasons:

   1) I was doing a downgrade, so bash itself never really went away.
   2) The code inthe scriptlet itself really should not have tried to do 
      anything in an upgrade.

This is what lead me to look into bash's %postun, but its probably a seperate
issue.  When I get a moment I will look further.
Comment 1 Tim Waugh 2003-08-14 06:16:26 EDT
I wouldn't expect up2date to behave like that.  Surely it should do the
equivalent of -U --oldpackage?
Comment 2 James Olin Oden 2003-08-14 07:13:43 EDT
Strange behaviour of up2date had to do with my auto-rollback patch for 
rpm (http://lee.k12.nc.us/~joden/misc/patches/rpm).  Basically, when it
runs the auto-rollback transaction instance passed to scriptlets are
all wrong.  So up2date is fine.

That said the %postun sciptlet in bash needs to be a %preun scriptlet,
as what it is doing is supposed to only be done in an erase, and in
a real erase bash will not be available to run the scriptlet in %postun.

Thanks...james
Comment 3 Tim Waugh 2004-12-08 09:33:22 EST
*** Bug 130460 has been marked as a duplicate of this bug. ***
Comment 4 Bill Nottingham 2006-08-04 23:09:06 EDT
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Comment 6 Bill Nottingham 2007-01-02 13:28:06 EST
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
f you are currently still running Red Hat Linux 7.3 or 9, you are strongly
advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux
or comparable. Some information on which option may be right for you is
available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

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