This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 752827 - postun scriptlet deletes /etc/shells lines even in upgrade
postun scriptlet deletes /etc/shells lines even in upgrade
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
: 753618 754056 754108 754148 754206 755349 755966 783659 784286 785836 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-10 09:30 EST by Roman Rakus
Modified: 2014-01-12 19:13 EST (History)
25 users (show)

See Also:
Fixed In Version: bash-4.2.10-5.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:21:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Roman Rakus 2011-11-10 09:30:54 EST
Valdis Kletnieks 2011-11-09 16:36:57 EST

After upgrading to the latest bash rpm in rawhide yesterday, my /etc/shells
ended up with just this in it, looks like the RPM script is eating it:

/sbin/nologin
/bin/tcsh
/bin/csh

Seems to be a problem with both F16 and Rawhide bash RPMs.

# cat /etc/shells
/sbin/nologin
/bin/tcsh
/bin/csh
/bin/bash
# rpm -Uvh --force ./bash-4.2.10-4.fc16.x86_64.rpm 
warning: ./bash-4.2.10-4.fc16.x86_64.rpm: Header V3 RSA/SHA256 Signature, key
ID a82ba4b7: NOKEY
Preparing...                ########################################### [100%]
   1:bash                   ########################################### [100%]
# cat /etc/shells
/sbin/nologin
/bin/tcsh
/bin/csh
# echo /bin/bash >> /etc/shells
# rpm -Uvh bash-4.2.10-6.fc17.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:bash                   ########################################### [100%]
# cat /etc/shells
/sbin/nologin
/bin/tcsh
/bin/csh
# echo /bin/bash >> /etc/shells
Comment 1 Roman Rakus 2011-11-10 09:31:28 EST
Related to bug #740611
Comment 2 Roman Rakus 2011-11-10 10:38:07 EST
It's in F16 and rawhide
Comment 3 Fedora Update System 2011-11-10 10:57:05 EST
bash-4.2.10-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/bash-4.2.10-5.fc16
Comment 4 Roman Rakus 2011-11-10 10:59:17 EST
But the funny things come in; when you upgrade previous bash-4.2.10-4.fc16 it will erase the lines in /etc/shells. So probably people should upgrade twice :)
Comment 5 Fedora Update System 2011-11-10 20:23:39 EST
Package bash-4.2.10-5.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing bash-4.2.10-5.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15725
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2011-11-13 00:31:45 EST
bash-4.2.10-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Ondrej Vasik 2011-11-15 01:23:01 EST
*** Bug 753618 has been marked as a duplicate of this bug. ***
Comment 8 Ondrej Vasik 2011-11-15 04:51:25 EST
*** Bug 754056 has been marked as a duplicate of this bug. ***
Comment 9 Roman Rakus 2011-11-15 09:38:12 EST
*** Bug 754148 has been marked as a duplicate of this bug. ***
Comment 10 Lars E. Pettersson 2011-11-15 14:31:36 EST
Still there...

$ rpm -q bash
bash-4.2.10-5.fc16.x86_64
$ cat /etc/shells
/sbin/nologin
/bin/tcsh
/bin/csh
/bin/dash
/bin/dash
$ 

Hm, /bin/dash two times? A typo somewhere, perhaps?
Comment 11 Tom Horsley 2011-11-15 15:04:52 EST
*** Bug 754108 has been marked as a duplicate of this bug. ***
Comment 12 David Zeuthen 2011-11-16 10:34:52 EST
Just for the record, this affects pkexec(1):

 [davidz@lucifer ~]$ pkexec bash
 The value for the SHELL variable was not found the /etc/shells file

 This incident has been reported.

 [davidz@lucifer ~]$ echo $SHELL
 /bin/bash

 [davidz@lucifer ~]$ cat /etc/shells 
 /sbin/nologin
 /bin/dash

and thus parts of the desktop relying on pkexec(1) to work.

This after updating to bash-4.2.10-5.fc16.x86_64. Therefore, reopening.
Comment 13 Roman Rakus 2011-11-16 10:38:21 EST
You have to reinstall bash once again. The bug was in previous postun scriptlet and this scriptlet is run even when upgrading to newer version.
Comment 14 Adam Williamson 2011-11-17 15:30:45 EST
It might help to wait a few days so everyone gets -5 and then release a -6 - AIUI, that should cause the issue to clear up, right?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 Adam Williamson 2011-11-17 15:37:56 EST
*** Bug 754206 has been marked as a duplicate of this bug. ***
Comment 16 Tom Horsley 2011-11-17 15:51:51 EST
(In reply to comment #13)
> You have to reinstall bash once again. The bug was in previous postun scriptlet
> and this scriptlet is run even when upgrading to newer version.

For folks who find this bug, it might be nice to mention that the command
you'd actually use (as root) to reinstall bash is:

yum reinstall bash

(I spent a log time poking around before discovering it :-).
Comment 17 Roman Rakus 2011-11-17 15:55:18 EST
(In reply to comment #14)
> It might help to wait a few days so everyone gets -5 and then release a -6 -
> AIUI, that should cause the issue to clear up, right?
It make sense. 
> 
> 
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers
Comment 18 Adam Williamson 2011-11-17 16:44:25 EST
So, thinking further: assuming the bad postun was in bash 4.2.10-4, and that's the build that's in F16 install images, *anyone* who installs F16 without the update repos is going to hit this bug on their first update, right? And it won't be fixed until they update bash again?

In that case we might want to try to find a way to fix it a bit harder, because 'any fresh install of F16 gets somewhat broken on the first update' is not a great state of affairs.
Comment 19 Adam Williamson 2011-11-17 20:50:08 EST
Roman: I believe this could be fixed with the use of 'triggerpostun' - indeed, that's more or less what it exists for. RPM documentation says "There is one other type of trigger available -- triggerpostun. These are triggers that are run after their target package has been removed; they will never be run when the package containing the trigger is removed. While this type of trigger is almost never useful, they allow a package to fix errors introduced by the postun of another package (or by an earlier version of that package)."

I think you could set a triggerpostun to fire when upgrading from any broken version of bash, to fix up /etc/shells .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 20 Adam Williamson 2011-11-17 20:50:51 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Roman Rakus 2011-11-17 21:06:01 EST
Adam: Thanks for investigation. I've never heard about triggers. I will take a look and use it. Seems it will fix this bug finally.
Comment 22 Ondrej Vasik 2011-11-21 00:09:58 EST
*** Bug 755349 has been marked as a duplicate of this bug. ***
Comment 23 Roman Rakus 2011-11-24 13:39:56 EST
Looks like trigger will not work. In %triggerpostun the file /etc/shells is empty and after update process /etc/shells doesn't contain /bin/bash and /bin/sh. It's strange that /etc/shells is empty in %triggerpostun. Maybe missing file:close() in postun scriptlet.
Comment 24 wgpalumbo 2011-12-27 12:47:44 EST
hello ... this is my first post and I do not know if this is the right place ... but I did what I recommended in / etc / shells, my vsftpd is uptaded .. and I still got the error 530 login incorrect, please, any idea how to fix it.
( I'm really thinking of going back to version fedora 15 )
Thanks.
Comment 25 Roman Rakus 2012-01-02 10:02:51 EST
(In reply to comment #24)
> hello ... this is my first post and I do not know if this is the right place
> ... but I did what I recommended in / etc / shells, my vsftpd is uptaded .. and
> I still got the error 530 login incorrect, please, any idea how to fix it.
> ( I'm really thinking of going back to version fedora 15 )
> Thanks.

Update to latest bash and reinstall it;
yum update bash
yum reinstall bash
Comment 26 D. Hugh Redelmeier 2012-01-02 15:33:09 EST
This bug is quite annoying because the normal fix (just run update) leaves your system broken.

What is each normal user to do?  Google when the puzzling symptoms occur (in my case: newly added users could only use dash (something they'd never hear of)?  What a tax on Fedora users.

I would think that the expedient fix would be to code a kludge into the bash installation script (scriptlet?) to take explicit action for this problem.  I understand it is a hack, but otherwise each Fedora installer must waste half an hour discovering the problem.  And I expect each such installer, when they discover that this was a known problem, will be quite annoyed at Fedora for knowingling wasting their time.  I know that I am.
Comment 27 wgpalumbo 2012-01-03 07:20:59 EST
(In reply to comment #26)
> This bug is quite annoying because the normal fix (just run update) leaves your
> system broken.
> 
> What is each normal user to do?  Google when the puzzling symptoms occur (in my
> case: newly added users could only use dash (something they'd never hear of)? 
> What a tax on Fedora users.
> 
> I would think that the expedient fix would be to code a kludge into the bash
> installation script (scriptlet?) to take explicit action for this problem.  I
> understand it is a hack, but otherwise each Fedora installer must waste half an
> hour discovering the problem.  And I expect each such installer, when they
> discover that this was a known problem, will be quite annoyed at Fedora for
> knowingling wasting their time.  I know that I am.

I agree with you fully ...
Comment 28 Adam Williamson 2012-01-03 18:53:08 EST
well, I figured it ought to be fixable via the use of triggerpostun, but roman says he couldn't make that work. I'm not sure what he's trying now.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 29 Tom Horsley 2012-01-03 20:30:16 EST
You could always release an update to "filesystem" that has a postinstall
script that fixes /etc/shells as a side effect :-).
Comment 30 Roman Rakus 2012-01-04 11:14:19 EST
(In reply to comment #28)
> well, I figured it ought to be fixable via the use of triggerpostun, but roman
> says he couldn't make that work. I'm not sure what he's trying now.
> 
> 
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers

There is missing close (in bash-4.2.10-4) in lua scriptlet, so the rpm has still open /etc/shells file and the file appears as empty (0 size). Only after end of rpm the file is closed (flushed), so I'm not able to modify it in the same rpm update.

(In reply to comment #29)
> You could always release an update to "filesystem" that has a postinstall
> script that fixes /etc/shells as a side effect :-).

This will not work in all situations.
Comment 31 Ondrej Vasik 2012-01-21 16:16:59 EST
*** Bug 783659 has been marked as a duplicate of this bug. ***
Comment 32 Nils Philippsen 2012-02-14 10:31:35 EST
*** Bug 755966 has been marked as a duplicate of this bug. ***
Comment 33 Roman Rakus 2012-02-29 09:28:31 EST
*** Bug 785836 has been marked as a duplicate of this bug. ***
Comment 34 Roman Rakus 2012-02-29 09:28:38 EST
*** Bug 784286 has been marked as a duplicate of this bug. ***
Comment 35 Fedora End Of Life 2013-01-16 19:20:32 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 36 Fedora End Of Life 2013-02-13 21:21:45 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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