Bug 212820

no change was made in original confs files!

no change was made in original rpm confs files!

(In reply to comment #0)
> Description of problem:
> automount failed to start!

This is not nearly enought information to work out what's wrong.

> 
> Version-Release number of selected component (if applicable):
> [root@weise ~]# rpm -qa | grep autofs
> autofs-5.0.1-0.rc2.17

Have you updated your kernel?
What is the kernel version?
Is selinux in enforcing mode?
Has autofs functioned ok in FC6 since it has been installed?
If it has previously worked have you changed your selinux
mode to enforcing recently?

> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
>   
> Actual results:
> [root@weise ~]# cat /var/log/messages | grep autofs
> Oct 29 08:05:19 weise automount[1952]: do_mount_autofs_indirect: failed to mount
> autofs path /misc
> Oct 29 08:05:19 weise automount[1952]: do_mount_autofs_indirect: failed to mount
> autofs path /net

I can't tell what the problem is from htis output.
When you post logs don't do things that could leave out
possibly relevant information as you've done here.

This problem could be related to a kernel update or
selinux but the log fragment here is incomplete so I
can't tell.

"grep automount /var/log/messages" would at least get
all the autofs messages.

Ian

Created attachment 139692 [details]
automount log messages

[root@weise jurandy]# grep automount /var/log/messages > automount.log

Ops, 

Sorry,

I upgraded (not reinstall) FC5 to FC6.

I updated kernel.586 (bug:anaconda) to kernel.686.

Kernel Version:
[root@weise ~]# uname -r
2.6.18-1.2798.fc6

I have selinux installed and running in enforcing mode.
[root@weise ~]# rpm -qa | grep selinux
selinux-policy-2.4.1-3.fc6
libselinux-devel-1.30.29-2
libselinux-1.30.29-2
libselinux-python-1.30.29-2

I attach log messages.
[root@weise jurandy]# grep automount /var/log/messages > automount.log

Thanks,

Jurandy Junior

(In reply to comment #5)
> Ops, 
> 
> Sorry,
> 
> I upgraded (not reinstall) FC5 to FC6.
> 
> I updated kernel.586 (bug:anaconda) to kernel.686.
> 
> Kernel Version:
> [root@weise ~]# uname -r
> 2.6.18-1.2798.fc6
> 
> I have selinux installed and running in enforcing mode.
> [root@weise ~]# rpm -qa | grep selinux
> selinux-policy-2.4.1-3.fc6
> libselinux-devel-1.30.29-2
> libselinux-1.30.29-2
> libselinux-python-1.30.29-2
> 
> I attach log messages.
> [root@weise jurandy]# grep automount /var/log/messages > automount.log

Oh look there's a bunch of selinux avc messages.
It looks like the filesystem security context information become
incorrect for some reason.

I think that a

restorecon -F -R -v /

might help but we really need advice from the selinux people
on this. This is potentially a big change so it may be
advisable to wait for advice from the selinux people before
continuing.

Ian

OK!

I found others selinux avc messages about gpm, hpiod and mcstrand in
/var/log/messages.

I believe this could be a selinux problem.

Let's wait selinux people.

Thanks for your attention.

Regards,

Jurandy Junior

This looks like a failed upgrade of policy.

Try 

restorecon -R -v /etc/selinux/targeted
semodule -b /usr/share/selinux/targeted/base.pp

See if this makes the problem go away.

Dan

Created attachment 139841 [details]
automount log messages after restorecon

Hi,

I tried:

restorecon -F -R -v /

Unfortunately, the error persists, see:

[root@weise ~]# cat /var/log/messages | grep automount > automount.log
I attached the file automount.log.

I tried:

restorecon -R -v /etc/selinux/targeted
semodule -b /usr/share/selinux/targeted/base.pp

The command restorecon doesn't affect the error. 
The command semodule doesn't exist. The alternatives are:

[root@weise jurandy]# semodule_deps
semodule_deps:  You must provide the base module package and at least one other
module package
usage: semodule_deps [-v -g -b] basemodpkg modpkg1 [modpkg2 ... ]

[root@weise jurandy]# semodule_expand 
semodule_expand:  You must provide the base module package and output filename
usage: semodule_expand [-V -a -c [version]] basemodpkg outputfile

[root@weise jurandy]# semodule_link 
semodule_link:  You must provide the base module package and at least one other
module package
usage: semodule_link [-Vv] [-o outfile] basemodpkg modpkg1 [modpkg2]...

[root@weise jurandy]# semodule_package 
usage: semodule_package -o <output file> -m <module> [-f <file contexts>]
Options:
  -o --outfile          Output file (required)
  -m --module           Module file (required)
  -f --fc               File contexts file
  -s --seuser           Seusers file (only valid in base)
  -u --user_extra       user_extra file (only valid in base)
  -n --nc               Netfilter contexts file

Thanks for your attention.

Regards,

Jurandy Junior

Hi,

I updated my selinux-policy.

[root@weise ~]# rpm -qa | grep selinux
selinux-policy-2.4.3-2.fc6
libselinux-devel-1.30.29-2
libselinux-1.30.29-2
libselinux-python-1.30.29-2

This resolved the selinux messages.

Now, I get the following error:

autmomount: kernel protocol version 5.00 or above required

What does this message mean? How can I resolve it?

Thanks for your attention.

Regards,

Jurandy Junior

(In reply to comment #11)
> 
> autmomount: kernel protocol version 5.00 or above required
> 
> What does this message mean? How can I resolve it?
> 

It means that the kernel module apparently doesn't support
autofs version 5. I don't usderstand why you're seeing that.

Could you run:
/sbin/lsmod | grep autofs

and post your output please.

Ian

[jurandy@weise ~]$ /sbin/lsmod | grep autofs
autofs4                25413  0 

But, see this:

[jurandy@weise ~]$ cat /etc/init.d/autofs 
#!/bin/bash
#
# $Id: rc.autofs.in,v 1.63 2006/03/30 02:09:51 raven Exp $
#
# rc file for automount using a Sun-style "master map".
#
# chkconfig: 345 28 72
# processname: /usr/sbin/automount
# config: /etc/auto.master
# description: Automounts filesystems on demand

#
# Location of the automount daemon and the init directory
#
DAEMON=/usr/sbin/automount
prog=`basename $DAEMON`
MODULE="autofs4"
initdir=/etc/init.d
confdir=/etc/sysconfig

test -e $DAEMON || exit 0

if [ -r $initdir/functions ]; then
        . $initdir/functions
fi

PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH

#
# load customized configuation settings
#
if [ -r $confdir/autofs ]; then
        . $confdir/autofs
fi

function start() {
        # Make sure autofs4 module is loaded
        if ! grep -q autofs /proc/filesystems
        then
                echo -n "Loading $MODULE: "
                # Try load the autofs4 module fail if we can't
                modprobe $MODULE >/dev/null 2>&1
                RETVAL=$?
                if [ $RETVAL -eq 1 ]
                then
                        failure "Load $MODULE"
                        echo
                        return $RETVAL
                else
                        success "Load $MODULE"
                        echo
                fi
        elif ([ -f /proc/modules ] && lsmod) | grep -q autofs[^4]
        then
                RETVAL=1
                failure "Load $MODULE"
                echo
                return $RETVAL
        fi
        echo -n $"Starting $prog: "
        $prog $OPTIONS 
        RETVAL=$?
        if [ $RETVAL -eq 0 ] ; then
                success "$prog startup"
        else
                failure "$prog startup"
        fi
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/autofs
        echo
        return $RETVAL
}

function stop() {
        echo -n $"Stopping $prog: "
        count=0
        while [ -n "`pidof $DAEMON`" -a $count -lt 15 ] ; do
                killproc $prog -TERM >& /dev/null
                RETVAL=$?
                [ $RETVAL = 0 -a -z "`pidof $DAEMON`" ] || sleep 3
                count=`expr $count + 1`
        done
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/autofs
        if [ -n "`pidof $DAEMON`" ] ; then
                failure "$prog shutdown"
        else
                success "$prog shutdown"
        fi
        echo
        return $RETVAL
}

function restart() {
        stop
        start
}

function reload() {
        if [ ! -f /var/lock/subsys/autofs ]; then
                echo $"$prog not running"
                RETVAL=1
                return $RETVAL
        fi
        pid=`pidof $DAEMON`
        if [ -z $pid ]; then
                echo $"$prog not running"
                RETVAL=1
        else
                kill -HUP $pid 2> /dev/null
                echo $"Reloading maps"
                RETVAL=0
        fi
        return $RETVAL
}

RETVAL=0

case "$1" in
        start)
                start
                ;;
        stop)
                stop
                ;;
        status)
                status $prog
                ;;
        restart)
                restart
                ;;
        reload)
                reload
                ;;
        *)
                echo $"Usage: $0 {start|stop|status|restart|reload}"
                exit 1;
                ;;
esac

exit $?


Regards,

Jurandy Junior

(In reply to comment #13)
> [jurandy@weise ~]$ /sbin/lsmod | grep autofs
> autofs4                25413  0 
> 
> But, see this:

See what?
What are you trying to point out?

The other thing that might cause this message is selinux.

The other thing here is that you've updated the autofs
package while trying to resolve a problem. This effectively
voids all the work we've done above as I know the message
your seeing was introduced in the latest update. So now we
have to start all over again.

Ian

Ops,

Sorry,

I turned off selinux. The autofs start with sucess.

This still is a selinux problem.

Let's wait selinux people.

Thanks for your attention.

Regards,

Jurandy Junior

(In reply to comment #15)
> Ops,

Hehe ...

> 
> Sorry,
> 
> I turned off selinux. The autofs start with sucess.
> 
> This still is a selinux problem.

We seem to get selinux issues quite often.
It would be good if we could get a cookbook checklist
procedure for identifing it and get avc messages as an
output.

Ian

At this point, just submitting the AVC messages is what is needed.  This should
work out of the box.  THere might be labeling problems or other problems which
we have not encountered yet,  But without the avc messages, I can only guess

grep -i avc /var/log/audit/audit.log and/or /var/log/messages.

(In reply to comment #17)
> At this point, just submitting the AVC messages is what is needed.  This should
> work out of the box.  THere might be labeling problems or other problems which
> we have not encountered yet,  But without the avc messages, I can only guess
> 
> grep -i avc /var/log/audit/audit.log and/or /var/log/messages.

Did you not see this request, it was made about a month ago?
What is the current status of this problem?

Ian

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

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

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