Please keep in mind that as far you're the only one experiencing such problems and that we still do not know very much about why it takes so long to bring up your network (...have you at least already test the DHCP response as I suggested?). And that the very reason of this problem is on BOINC side being not capable to use newly available connections, hopefully _this_ will be fixed soon (6.4).

...
Aug 14 07:26:45 localhost NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Aug 14 07:26:48 localhost boinc_client: Starting Boinc-Daemon, listening on port 31416.
Aug 14 07:26:51 localhost gconfd (gdm-2139): Beenden
Aug 14 07:26:51 localhost gconfd (mex-2281): starting (version 2.22.0), pid 2281 user 'mex'
...

If you observe time stamps carefully you can see that it takes 16 seconds between starting network configuration (NetworkManager in your case) and finishing it (marked by LAN connectivity ready).

The most disturbing period of time is those 10 seconds when ethernet link is considered not ready. There are a couple of reasons for that. One is delay caused by peer device (ethernet switch / router) during which some kind of auto-negotiation can take place. This was not so uncommon years ago, but should be almost instant these days. The other possibility is that this is caused by kernel driver and/or userland software (NetworkManager) if parts of network interface (MII transciever in particular) gets reset during some stage of initialization. Some time is then needed to recover.
There are many other possibilities as to why there's a 10 second delay.

As I already wrote in my post, the root of your problems is the fact that network gets configured in background (to speed-up the booting procedure). I also described a good cure: make a sleep-loop until default route gets configured.

[mex@localhost ~]$ time /sbin/ifup eth0
Benutzer können dieses Gerät nicht steuern.

real	0m0.080s
user	0m0.012s
sys	0m0.014s
[mex@localhost ~]$ su
Passwort: 
[root@localhost mex]# time /sbin/ifup eth0

IP-Informationen werden für eth0 bestimmt...dhclient(2177) is already running - exiting. 

This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.

Please report for this software via the Red Hat Bugzilla site:
    http://bugzilla.redhat.com

exiting.
 fehlgeschlagen.

real	0m0.688s
user	0m0.041s
sys	0m0.038s
[root@localhost mex]#

PS: I am sure the problem originates from some ugly patch f9 has applied to itself during installation on my V5535 :rollingeyes:

I doubt this will be the reason as it would affect more users, not only you as it seems to be as far.

...
Aug 14 07:26:24 localhost kernel: sis190 Gigabit Ethernet driver 1.2 loaded.
Aug 14 07:26:24 localhost kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 19 (level, low) -> IRQ 19
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Read MAC address from EEPROM
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Unknown PHY transceiver at address 1.
...
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Using transceiver at address 1 as default.
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: SiS 191 PCI Gigabit Ethernet adapter at f88bc000 (IRQ: 19), 00:1e:33:03:02:ae
Aug 14 07:26:24 localhost kernel: eth0: RGMII mode.
Aug 14 07:26:24 localhost kernel: eth0: Enabling Auto-negotiation.
...
Aug 14 07:26:28 localhost NetworkManager: <info>  starting...
Aug 14 07:26:28 localhost NetworkManager: <info>  eth0: Device is fully-supported using driver 'sis190'.
Aug 14 07:26:28 localhost NetworkManager: <info>  Found new Ethernet device 'eth0'.
Aug 14 07:26:28 localhost NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_00_1e_33_03_02_ae
Aug 14 07:26:28 localhost NetworkManager: <info>  wlan0: Device is fully-supported using driver 'ath5k_pci'.
Aug 14 07:26:28 localhost NetworkManager: <info>  wlan0: driver supports SSID scans (scan_capa 0x01).
Aug 14 07:26:28 localhost NetworkManager: <info>  Found new wireless (802.11) device 'wlan0'.
Aug 14 07:26:28 localhost NetworkManager: <info>  (wlan0): exported as /org/freedesktop/Hal/devices/net_00_16_44_8d_47_e7
Aug 14 07:26:28 localhost NetworkManager: <info>  Trying to start the supplicant...
Aug 14 07:26:28 localhost NetworkManager: <info>  Trying to start the system settings daemon...
Aug 14 07:26:28 localhost nm-system-settings: Loaded plugin ifcfg-fedora: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing 
list.
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... 
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora:     error: File '/etc/sysconfig/network-scripts/ifcfg-eth0' specified device 'eth0', but the de
vice's type could not be determined.
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora:     error: Ignoring loopback device config.
...
Aug 14 07:26:32 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): device state change: 1 -> 2
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): bringing up device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): preparing device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): deactivating device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): device state change: 1 -> 2
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): bringing up device.
Aug 14 07:26:32 localhost kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): preparing device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): deactivating device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): device state change: 2 -> 3
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): supplicant interface state change: 1 -> 2.
Aug 14 07:26:32 localhost nm-system-settings: Adding default connection 'Auto eth0' for /org/freedesktop/Hal/devices/net_00_1e_33_03_02_ae
...
Aug 14 07:26:42 localhost kernel: eth0: mii ext = 0000.
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): carrier now ON (device state 2)
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 2 -> 3
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) starting connection 'Auto eth0'
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 3 -> 4
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 4 -> 5
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 5 -> 7
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Beginning DHCP transaction.
Aug 14 07:26:42 localhost kernel: eth0: mii lpa = 45e1 adv = 01e1.
Aug 14 07:26:42 localhost kernel: eth0: link on 100 Mbps Full Duplex mode.
Aug 14 07:26:42 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 14 07:26:42 localhost NetworkManager: <info>  dhclient started with pid 2178
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Aug 14 07:26:42 localhost dhclient: Internet Systems Consortium DHCP Client 4.0.0
Aug 14 07:26:42 localhost dhclient: Copyright 2004-2007 Internet Systems Consortium.
Aug 14 07:26:42 localhost dhclient: All rights reserved.
Aug 14 07:26:42 localhost dhclient: For info, please visit http://www.isc.org/sw/dhcp/
Aug 14 07:26:42 localhost dhclient: 
Aug 14 07:26:42 localhost NetworkManager: <info>  DHCP: device eth0 state changed (null) -> preinit
Aug 14 07:26:42 localhost dhclient: Listening on LPF/eth0/00:1e:33:03:02:ae
Aug 14 07:26:42 localhost dhclient: Sending on   LPF/eth0/00:1e:33:03:02:ae
Aug 14 07:26:42 localhost dhclient: Sending on   Socket/fallback
Aug 14 07:26:43 localhost avahi-daemon[1955]: Registering new address record for fe80::21e:33ff:fe03:2ae on eth0.*.
Aug 14 07:26:44 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Aug 14 07:26:44 localhost dhclient: DHCPOFFER from 192.168.11.1
Aug 14 07:26:44 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Aug 14 07:26:44 localhost dhclient: DHCPACK from 192.168.11.1
Aug 14 07:26:44 localhost NetworkManager: <info>  DHCP: device eth0 state changed preinit -> bound
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) scheduled...
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) started...
Aug 14 07:26:44 localhost NetworkManager: <info>    address 192.168.11.2
Aug 14 07:26:44 localhost NetworkManager: <info>    netmask 255.255.255.0
Aug 14 07:26:44 localhost NetworkManager: <info>    gateway 192.168.11.1
Aug 14 07:26:44 localhost NetworkManager: <info>    nameserver '192.168.11.1'
Aug 14 07:26:44 localhost NetworkManager: <info>    domain name 'freiesnetz.www.funkfeuer.at'
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) complete.
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Aug 14 07:26:44 localhost avahi-daemon[1955]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.11.2.
Aug 14 07:26:44 localhost avahi-daemon[1955]: New relevant interface eth0.IPv4 for mDNS.
Aug 14 07:26:44 localhost avahi-daemon[1955]: Registering new address record for 192.168.11.2 on eth0.IPv4.
Aug 14 07:26:44 localhost dhclient: bound to 192.168.11.2 -- renewal in 71351 seconds.
Aug 14 07:26:45 localhost NetworkManager: <info>  (eth0): device state change: 7 -> 8
Aug 14 07:26:45 localhost NetworkManager: <info>  Policy set (eth0) as default device for routing and DNS.
Aug 14 07:26:45 localhost NetworkManager: <info>  Activation (eth0) successful, device activated.
Aug 14 07:26:45 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Aug 14 07:26:48 localhost boinc_client: Starting Boinc-Daemon, listening on port 31416.
Aug 14 07:26:51 localhost gconfd (gdm-2139): Beenden
Aug 14 07:26:51 localhost gconfd (mex-2281): starting (version 2.22.0), pid 2281 user 'mex'
...

[mex@localhost ~]$ time ifup eth0
bash: ifup: command not found

real	0m0.001s
user	0m0.001s
sys	0m0.001s
[mex@localhost ~]$ su
Passwort: 
[root@localhost mex]# time ifup eth0
bash: ifup: command not found

real	0m0.002s
user	0m0.000s
sys	0m0.001s
[root@localhost mex]# time

real	0m0.000s
user	0m0.000s
sys	0m0.000s
[root@localhost mex]# help time
time: time [-p] PIPELINE
    Execute PIPELINE and print a summary of the real time, user CPU time,
    and system CPU time spent executing PIPELINE when it terminates.
    The return status is the return status of PIPELINE.  The `-p' option
    prints the timing summary in a slightly different format.  This uses
    the value of the TIMEFORMAT variable as the output format.
times: times
    Print the accumulated user and system times for processes run from
    the shell.
[root@localhost mex]#

Anyway its really strange to me that your network takes so long to come up. Did you measure how long does it take indeed (the best way is probably to boot up without networking and then type "time ifup eth0" -- assuming you're using the eth0 interface of course)?

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

This is ugly as normally desktops don't run DNS server.

I'm unsure whether this facility indicates running a named (e.g. bind).
In the LSB specification one can read:

$network: basic networking support is available. Example: a server program could listen on a socket.

$named: IP name-to-address translation, using the interfaces described in this specification, are available to the level the system normally provides them. Example: if a DNS query daemon normally provides this facility, then that daemon has been started.

Hence $named indicates rather resolution-ready system than running named daemon, doesn't it?

...
case "$1" in
  start)
        cd $BOINCDIR

        if [ ! -d projects ] ; then
          echo -n "The BOINC client requires initialization (no projects attached)."
          echo_warning
          echo 
        fi

	echo -n "Starting BOINC client as a daemon:"
	( daemon --check $BOINCEXE --user $BOINCUSER +19 "$BOINCEXE $BOINCOPTS" >>$LOGFILE 2>>$ERRORLOG & );
	sleep 1; PID=`pidof -s -x -o $$ -o $PPID -o %PPID $BOINCEXE`;
	if [ $PID ]; then
	  touch $LOCKFILE && echo_success || echo_failure
	fi
	echo ;;
#   echo "Starting BOINC client as a daemon in 15 seconds ..."
# ( sleep 15; echo; echo -n "Starting BOINC client as a daemon:"
# ( daemon --check $BOINCEXE --user $BOINCUSER +19 "$BOINCEXE $BOINCOPTS" >>$LOGFILE 2>>$ERRORLOG & );
#   sleep 1; PID=`pidof -s -x -o $$ -o $PPID -o %PPID $BOINCEXE`;
#   if [ $PID ]; then touch $LOCKFILE && echo_success || echo_failure fi; echo ) & ;;
  stop)
...

Fre 08 Aug 2008 13:55:03 CEST||Starting BOINC client version 5.10.45 for i686-pc-linux-gnu
Fre 08 Aug 2008 13:55:03 CEST||log flags: task, file_xfer, sched_ops
Fre 08 Aug 2008 13:55:03 CEST||Libraries: libcurl/7.18.2 NSS/3.12.0.3 zlib/1.2.3 libidn/0.6.14
Fre 08 Aug 2008 13:55:03 CEST||Executing as a daemon
Fre 08 Aug 2008 13:55:03 CEST||Data directory: /var/lib/boinc
Fre 08 Aug 2008 13:55:03 CEST||Processor: 1 GenuineIntel Intel(R) Celeron(R) CPU          540  @ 1.86GHz [Family 6 Model 22 Stepping 1]
Fre 08 Aug 2008 13:55:03 CEST||Processor features: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc up arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
Fre 08 Aug 2008 13:55:03 CEST||OS: Linux: 2.6.25.11-97.fc9.i686
Fre 08 Aug 2008 13:55:03 CEST||Memory: 2.71 GB physical, 3.99 GB virtual
Fre 08 Aug 2008 13:55:03 CEST||Disk: 62.98 GB total, 55.57 GB free
Fre 08 Aug 2008 13:55:03 CEST||Local time is UTC +2 hours
Fre 08 Aug 2008 13:55:03 CEST|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1482516; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|SHA-1 Collision Search Graz|URL: http://boinc.iaik.tugraz.at/sha1_coll_search/; Computer ID: 31994; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|Rectilinear Crossing Numbers|URL: http://dist.ist.tugraz.at/cape5/; Computer ID: 39216; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|lhcathome|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 9703324; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|orbit@home|URL: http://orbit.psi.edu/oah/; Computer ID: 8705; location: (none); project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|SETI@home Beta Test|URL: http://setiweb.ssl.berkeley.edu/beta/; Computer ID: 29977; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 4482760; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST||General prefs: from orbit@home (last modified 27-Jun-2008 14:48:32)
Fre 08 Aug 2008 13:55:03 CEST||Host location: none
Fre 08 Aug 2008 13:55:03 CEST||General prefs: using your defaults
Fre 08 Aug 2008 13:55:03 CEST||Reading preferences override file
Fre 08 Aug 2008 13:55:03 CEST||Preferences limit memory usage when active to 1388.09MB
Fre 08 Aug 2008 13:55:03 CEST||Preferences limit memory usage when idle to 2498.56MB
Fre 08 Aug 2008 13:55:03 CEST||Preferences limit disk usage to 1.86GB
Fre 08 Aug 2008 13:55:08 CEST|Einstein@Home|Restarting task h1_0236.80_S5R4__39_S5R4a_1 using einstein_S5R4 version 602
Fre 08 Aug 2008 13:55:08 CEST|lhcathome|Sending scheduler request: To fetch work.  Requesting 1056 seconds of work, reporting 0 completed tasks
Fre 08 Aug 2008 13:55:14 CEST|lhcathome|Scheduler request failed: Couldn't resolve host name
Fre 08 Aug 2008 13:56:15 CEST|lhcathome|Sending scheduler request: To fetch work.  Requesting 1056 seconds of work, reporting 0 completed tasks
Fre 08 Aug 2008 13:56:17 CEST||Project communication failed: attempting access to reference site
Fre 08 Aug 2008 13:56:18 CEST||Access to reference site failed - check network connection or proxy configuration.
Fre 08 Aug 2008 13:56:20 CEST|lhcathome|Scheduler request failed: Couldn't resolve host name

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

I'm pretty curious whether this could solve your problem (without needing any further delays etc.)

Anyway its really strange to me that your network takes so long to come up. Did you measure how long does it take indeed (the best way is probably to boot up without networking and then type "time ifup eth0" -- assuming you're using the eth0 interface of course)?

Well, I can't see why you're so concerned over a 15 second delay. I mean really, if you reboot once a day then in 1 year you'll lose a total of 1.5 hours. If you schedule things properly you could find something productive to too in that 15 seconds, for example, tidy up your desk, get a coffee, loosen your collar, pet the dog, take a Valium, put on some music you find relaxing, practice not rolling your eyes, whatever.

However, if you are absolutely certain your life is going to hell because you've lost 15 seconds then spend 20 minutes (that's a compelling economy) reading this thread where we've been discussing how to start the client (installed via Berkeley installer) after a delay.

...
if [ -x /home/poorboy/BOINC/boinc ]
then
echo "Starting BOINC in 10 seconds ..."
( cd /home/poorboy/BOINC; sleep 10; sudo -u poorboy ./boinc --daemon --allow_remote_gui_rpc ) &
fi
...

[root@localhost mex]# /sbin/service boinc-client restart
Stopping BOINC client daemon:                              [  OK  ]
Starting BOINC client as a daemon in 11 seconds ...
[root@localhost mex]# 
Starting BOINC client as a daemon:                         [  OK  ]

... Then build Sugar (the desktop environment the XO uses) and the activities that go along with it. I'd like to use their Logo activity with one of my classes. But since it took me a week to actually get BOINC (manager + core client) to build, I don't think Sugar is a weekend project...

...You can introduce a delay by editing /etc/init.d/boinc-client and putting a line "sleep x", where x = the seconds to delay, just before the "echo -n Starting BOINC client as daemon". A 1 or 3 minute delay there might fix the problem...

Once again: the client indeed NEEDS to be modified. It's a known issue that it cannot use newly available connections after its start. I've just got a message from Frank S. Thomas (who is the maintainer of the debian packages of boinc) that this should be fixed by the asynchronous GUI RPC in BOINC 6.4.
(the most troubles regarding this come from laptop users migrating all the time between various wireless connections while not restarting their machines often but using suspend to ram/disk instead of it)

So not the client needs to be modified, only the RPM for f9 needs to be modified in a way that makes sure that boinc is started as a demon AFTER the access to the www has been initialized ... or the wiki needs a new instruction how to start the client during startup as a demon if the user has the same problems with a delay of the initialisation of the network.

As a workaround for now I'll modify the init script to wait for the network or named facility -- this should solve the issue in your case but it cannot solve the problem generally.

I'll release new package together with new BOINC 6...hopefully soon, I'm just waiting for the 6.2.15 bugfix release.

/etc/rc starts all services including boinc-client. Open it in an editor and add the red lines

# Now run the START scripts.
for i in /etc/rc$runlevel.d/S* ; do

# Check if the subsystem is already up.
subsys=${i#/etc/rc$runlevel.d/S??}
[ -f /var/lock/subsys/$subsys ] && continue
[ -f /var/lock/subsys/$subsys.init ] && continue
if strstr $i "boinc-client"; then
echo "sleep 15 for boinc-client"
sleep 15
fi
check_runlevel "$i" || continue

Before the above mod, the rc script just runs each service's start script. The mod simply makes rc look at the name of each start script and if the name contains the string 'boinc-client' then rc sleeps for 15 seconds before it runs the script. Thus you should get the delay only at boot time, not whenever boinc-client starts.

I agree with Milos that hacking startup scripts is not the best fix so I submitted Trac ticket 707

 <start_delay>
    Specify a number of seconds to delay running applications after client startup. New in 6.1.6

I re-wrote the wiki article to reflect the fact that it's not necessary to add your username to the boinc group just to have the manager connect to the client without giving the password. I doubt adding your username to the boinc group could cause any problem (it never caused a problem for me) but if you do reinstall then perhaps try not adding username to the boinc group.

HOW do I tell the client to sleep 20 (or less) seconds before starting BOINC client as daemon ?

What do I have to add to which init script ?
...

See here in this same thread.

A bit easier would be to simply sleep 20 seconds immediately before starting boinc CC as daemon.

I found only one supporting Linux/PowerPC64 (not counting the proprietary? Yoyo or PS3grid which support the PS3 with Cell platforms).
Seems that I will have to contact http://boinc.berkeley.edu/alpha/, join SETI alpha or will have to compile my own client for my PS3 :(

You've the client, but you don't have any PPC work units, if I'm right (Kathryn, Eric?) -- so this is solved for me:)

Regarding the other problem (not being able to connect to the network), I'm pretty sure that this is just because networking is not up when the boinc daemon is started. Please type "chkconfig --list" and post the output.

[mex@localhost ~]$ su
Passwort: 
[root@localhost mex]# /sbin/service boinc-client restart
Stopping BOINC client daemon:                              [  OK  ]
Starting BOINC client as a daemon:                         [  OK  ]
[root@localhost mex]# chkconfig --list
bash: chkconfig: command not found
[root@localhost mex]# /sbin/chkconfig --list
NetworkManager 	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
acpid          	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
anacron        	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
atd            	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
auditd         	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
avahi-daemon   	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
backuppc       	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
bluetooth      	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
boinc-client   	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
btseed         	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
bttrack        	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
capi           	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
cpuspeed       	0:Aus	1:Ein	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
crond          	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
cups           	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
dund           	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
firstboot      	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
fuse           	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
gpm            	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Aus	6:Aus
haldaemon      	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
hddtemp        	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
httpd          	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
ip6tables      	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
iptables       	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
irda           	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
irqbalance     	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
isdn           	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
kerneloops     	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
lm_sensors     	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
mdmonitor      	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
messagebus     	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
microcode_ctl  	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
multipathd     	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
netconsole     	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
netfs          	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
netplugd       	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
network        	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
nfs            	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
nfslock        	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
nscd           	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
ntpd           	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
ntpdate        	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
pand           	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
pcscd          	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
psacct         	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
rdisc          	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
restorecond    	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
rpcbind        	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
rpcgssd        	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
rpcidmapd      	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
rpcsvcgssd     	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
rsyslog        	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
saslauthd      	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
sendmail       	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
setroubleshoot 	0:Aus	1:Aus	2:Aus	3:Ein	4:Ein	5:Ein	6:Aus
smartd         	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
smolt          	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
snmpd          	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
snmptrapd      	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
sshd           	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
udev-post      	0:Aus	1:Ein	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
winbind        	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
wine           	0:Aus	1:Aus	2:Ein	3:Ein	4:Ein	5:Ein	6:Aus
wpa_supplicant 	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
ypbind         	0:Aus	1:Aus	2:Aus	3:Aus	4:Aus	5:Aus	6:Aus
[root@localhost mex]#

See this project list. There might be one with an app for your PS3. The platforms are auto updated regularly by a script that querys all the listed projects for platforms they support.

Riesel Sieve

* URL: http://boinc.rieselsieve.com/
* Institution: Riesel Sieve community
* Official launch: 28-10-2007
* Platforms: Linux/x86, Linux/PowerPC64, windows_amd64, Windows, Windows/x86_64, Linux/x86_64
* Description: Find prime numbers of the form k*2n-1

I assume it is a timing problem at my notebook, where my SiS LAN isn't ready at the time init is starting the boinc-client during booting :rolleyes:

Perhaps. You could test that theory by doing:

1) /sbin/chkconfig boinc-client off - do not start the daemon at boot
2) reboot, login as mex
3) /sbin/service boinc-client start - start the daemon

Maybe try a fresh install of F9 and BOINC? When I installed F9 I used all the defaults except for time zone and hostname. For hostname, rather than the default "automatically via DHCP" option I selected "manual" and entered a hostname. I don't see how that could affect BOINC's ability to connect to the Internet but perhaps it does.
...
If it's the SiS chipset then it should not connect for the root user too. Why a connect problem just for a normal user? I mean either way (no matter who is logged in), root owns the binary that requests/uses the connection and the running process belongs to the user named boinc not the user that logs in. How and why does it decide to connect when root logs in but not when normal user logs in?

... time to install BOINC on my PS3 to look if I have the same problem there.

I installed Fedora 9 and BOINC 5.10.45 via RPM. BOINC is able to access the Internet when I am logged in as normal user (not root), even with SELinux set to enforcing.

Are you starting the client during boot ?

Yes, it runs as a daemon (starts at boot time before any user logs in).