Bug 753780

Summary:	Include common shells into default /etc/shells
Product:	[Fedora] Fedora	Reporter:	Stephen Haffly <hafflys>
Component:	setup	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	mike.cloaked, ovasik, pknirsch, psabata, rrakus
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-11-15 14:27:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Stephen Haffly 2011-11-14 13:35:12 UTC

Description of problem:
I upgraded from Fedora 15 to Fedora 16 using preupgrade. After it seemed to be running well, I tried to start VirtualBox. It said the kernel module was missing, so I took care of that. Afterward, it complained about lacking the extensions so I went to install that but got a message:
ExtPackInst ExtPack: enmReason=1 iStatus=127 stderr='The value for the SHELL
variable was not found the /etc/shells file
I looked at the /etc/shells file, and found that there were two entries for /bin/dash but no entry for /bin/bash. I changed the first instance to /bin/bash, and that fixed it. I entered this in bug report #706147, and was told that this should be filed against setup.

Version-Release number of selected component (if applicable):
setup-2.8.36-2.fc16.noarch

How reproducible:
Once fixed by changing one of the /bin/dash entries to /bin/bash, the problem disappears. I suppose if I were to install F16 again, the problem would crop up, but I don't wish to reinstall F15 in order to upgrade it again to verify this.

Steps to Reproduce:
1. Have working F15 setup
2. using preupgrade, upgrade to F16
3. Attempt to run VirtualBox, which ran fine before upgrading.

Actual results:
Get message about the SHELL variable not found in /etc/shells file

Expected results:
When upgrading, setup should ensure that /bin/bash is left in place in /etc/shells

Additional info: Linux xxxxxxxx.yyyyyyyy 3.1.1-1.fc16.x86_64 #1 SMP Fri Nov 11 21:47:56 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

This exists also on my netbook, also running F16 x86_64 which was upgraded via preupgrade. It has fewer entries, but also has /bin/dash twice and is missing /bin/bash. I have fixed this on it as well, so this seems to indicate that this is not a problem unique to one machine.

This is the /etc/shells file from my desktop machine. as it was before I modified it.

/sbin/nologin
/bin/dash
/bin/zsh
/bin/ksh
/bin/dash

This is the file after I modified it.

/sbin/nologin
/bin/bash
/bin/zsh
/bin/ksh
/bin/dash

Comment 1 Petr Šabata 2011-11-14 13:44:53 UTC

It seems like bash-4.2.10-5.fc16.x86_64 update removed the /bin/bash record on my system.

I agree with Ondrej's (bug 706147, comment #7) idea to include all shells in the file by default.

Comment 2 Ondrej Vasik 2011-11-14 14:19:31 UTC

Anyway - ensuring after setup update is generally not possible - I can use only lua scriptlet in setup post/postun (and with lua that could be quite hard to achieve). In addition, I can't prevent breakage/modifications by users/other packages after setup update.

Adding some(all of known) new shells probably makes sense, I'll check the other shell packages and way how they add their shell to /etc/shells file.

Comment 3 Ondrej Vasik 2011-11-14 18:26:23 UTC

Adding Bash maintainer to cc, as he probably removed the shell by accident (based on comment #1)

Comment 4 Roman Rakus 2011-11-14 18:36:47 UTC

It was bug in previous version of bash. There is newer one. However the bug is in postun scriptlet, it means, you need to upgrade twice (or upgrade and reinstall).

Comment 5 Roman Rakus 2011-11-14 18:48:45 UTC

Double /bin/dash is bug in dash package

Comment 6 Roman Rakus 2011-11-14 19:00:28 UTC

Setup package should check all installed shells and entries in /etc/shells? It's nonsense.

I would close this bug as duplicate of bug #752827.

Comment 7 Ondrej Vasik 2011-11-14 20:07:11 UTC

Thanks for information, Roman. This bugzilla was initiated by dash bugzilla #706147 and was more about including more shells into default /etc/shells (summary changed) - it probably makes sense to include all common shells there and don't touch /etc/shells from the shells packages.

Double /bin/dash and missing /bin/bash are definitely duplicates of existing bugzillas, but with this summary this bugzilla could be kept open.

Comment 8 Petr Šabata 2011-11-15 08:38:53 UTC

(In reply to comment #5)
> Double /bin/dash is bug in dash package

Could you elaborate on that?  Indeed it would be weird if some other package caused that but the only thing dash has been doing in past two Fedora releases is this:

%post
grep -qF '^/bin/dash$' /etc/shells || echo '/bin/dash' >> /etc/shells

%postun
if [ $1 -eq 0 ]; then
    sed -i '/^\/bin\/dash$/d' /etc/shells
fi


Maybe I'm just missing obvious...

Comment 9 Petr Šabata 2011-11-15 09:04:22 UTC

Ah, bug 753887 explains that.  Never mind then :)

Comment 10 Mike C 2011-11-15 14:15:22 UTC

Although this report refers to upgrade from f15 to f16 - I have a new fresh install of f16 x86_64 and up to date as of this morning.

My /etc/shells contains:
/sbin/nologin
/bin/dash
/bin/zsh

I am really surprised that there is no bash or other common shells.
In fact I checked with an f14 machine where the contents are:

/bin/sh
/bin/bash
/sbin/nologin
/bin/zsh
/bin/dash

Clearly something is missing - and maybe the error is somewhere other than the bash update?

Comment 11 Ondrej Vasik 2011-11-15 14:27:56 UTC

Well, it was really bug in bash, but bug in %postun scriptlet of old bash means you need two updates to get it fixed ... yum reinstall bash will fix your problem...

In addition, after thinking a bit more about this idea of including all common shells into /etc/shells I think it would only cause confusion ... handling it in shell packages is much better - but it has a risk of such issues like the current one with bash update...

Anyway closing this as not a bug (as I'm not going to add additional shells to default /etc/shells) ...

Comment 12 Mike C 2011-11-15 16:53:43 UTC

OK you are right - 

I did 
yum reinstall bash

Once done, then the VirtualBox extensions pack installed without issue - but knowing what was needed was important! Hence this was a useful report even if no change to any packages was needed.

Thanks

Comment 13 Ondrej Vasik 2011-11-15 17:38:28 UTC

Yes, but I changed the summary of this bugzilla to be about something else than "/bin/bash" missing ... There are already several "/bin/bash missing in /etc/shells" bugzillas, so that would be a duplicate in that case.