Bug 375721

Created attachment 254371 [details]
Image showing the failure message during boot

Note the dbus error during this boot sequence.

Created attachment 254391 [details]
wpa_supplicant log file showing dbus problems

Looking at the screen image during boot from #1 is it possible that there is a
space missing in the sequence -Dwextdbus... i.e. is it
that in a config file (but where?) it should instead be -Dwext dbus.... ?

I'm seeing similar issues with wpa_supplicant on F8:

[root@defiant wpa_supplicant]# service wpa_supplicant start
wpa_supplicant wird gestartet: /etc/wpa_supplicant/wpa_supplicant.conf, ,
dbus_bus_request_name[dbus]: Resource temporarily unavailable
Failed to initialize wpa_supplicant

/etc/wpa_supplicant/wpa_supplicant.conf contains:
 
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

The odd thing is that once I am logged in (as a user) I can open a terminal
window and become root - at that point service wpa_supplicant start does work -
and I can then do dhclient eth1 and it gives a nice stable wireless connection.
So this is different from your situation where you can't start the supplicant
from the command line. However you are also seeing a dbus problem so I guess it
is related but it would be nice to know exactly where the problem lies.

I can confirm this bug. The dbus interface starts after network and
wpa_supplicant. I guess the wpa_supplicant needs dbus in case to register itself
for the network interface.

A manual restart is necessary atm. In my case  I need to restart the service
network, too to get my wireless connection work.

(In reply to comment #4)
> I'm seeing similar issues with wpa_supplicant on F8:
> 
> [root@defiant wpa_supplicant]# service wpa_supplicant start
> wpa_supplicant wird gestartet: /etc/wpa_supplicant/wpa_supplicant.conf, ,
> dbus_bus_request_name[dbus]: Resource temporarily unavailable
> Failed to initialize wpa_supplicant
> 
> /etc/wpa_supplicant/wpa_supplicant.conf contains:
>  
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> 
> 
i have the same problem.. no manual restart of the service is possible :( :( 

I had a thought that I will test when I get home this evening (my laptop is not
with me at the moment).

In the file /etc/init.d/wpa_supplicant

Note the lines:

start() {
        echo -n $"Starting $prog: $conf, $INTERFACES, $DRIVERS"
        daemon $prog -c $conf $INTERFACES $DRIVERS -B -u -f
        retval=$?
        echo
        [ $retval -eq 0 ] && touch $lockfile
        return $retval
}

It looks to me that the daemon line has an error in it. So instead of 
        daemon $prog -c $conf $INTERFACES $DRIVERS -B -u -f
it should be
        daemon $prog -c$conf $INTERFACES $DRIVERS -B -u -f

i.e. remove the space between -c and $conf since the manual startup would call
for a command line (from man wpa_supplicant) that would read:

wpa_supplicant -c/etc/wpa_supplicant.conf -iwlan0 -d

In this example there is also no space between the -c and /etc/wpa.....

I will test this later today and report back If it works.  I also notice that
this error seems to be present in f7 since I have checked the machine I am
currently running with f7 and this script also has this problem.

If so then it is presumably an easy fix to put into an update for wpa_supplicant?

i have tested it a minute ago...unfortunately, no success... :(

OK - I will test this on my machine later today. I wonder if the underlying
problem is something to do with a script error, or if it is due to a startup
timing error - I will look into the startup sequence when I get some time - I
note that in the initscripts wpa_supplicant starts at S88 - I wonder if this
might need changing?

Is there anything it depends on which is started after that?

One difference between your situation and mine is that I can do a manual start
of the daemon after logging in whereas it seems you can't - so perhaps in my
case this fix may work - frustrating that I am away from the machine with f8 today!

*** This bug has been marked as a duplicate of 244029 ***

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