Related to bug #740611

It's in F16 and rawhide

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

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 :)

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).

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.

*** Bug 753618 has been marked as a duplicate of this bug. ***

*** Bug 754056 has been marked as a duplicate of this bug. ***

*** Bug 754148 has been marked as a duplicate of this bug. ***

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?

*** Bug 754108 has been marked as a duplicate of this bug. ***

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.

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.

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

*** Bug 754206 has been marked as a duplicate of this bug. ***

(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 :-).

(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

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.

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

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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.

*** Bug 755349 has been marked as a duplicate of this bug. ***

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.

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.

(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

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.

(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 ...

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

You could always release an update to "filesystem" that has a postinstall
script that fixes /etc/shells as a side effect :-).

(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.

*** Bug 783659 has been marked as a duplicate of this bug. ***

*** Bug 755966 has been marked as a duplicate of this bug. ***

*** Bug 785836 has been marked as a duplicate of this bug. ***

*** Bug 784286 has been marked as a duplicate of this bug. ***

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

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.