Network too slow to set up

M

mururoa

Hi,
This is a problem I kinda had when upgrading from 7.3 to 8.0. In 7.3 I was in dhcp and I 'solved' it by setting fixed IP @.
The problem is that the network is too slow to setup and this cause an error and I'm dropped to the shell to fix. When I get the shell I just do ^D and the boot continues.
I mean that if I use some kind of network service in the boot process it wont work and so it interrupt the boot since the network is not available when the service request it.
For example ntpdate or mounting network filesystems.
I upgraded all to 8.1 release and my network driver is ale.
Doh I just thought I didnt tried to fix network speed :(
 
Grrr nothing changed :(

So my boot process is :
- start computer
- wait network mount error
- press enter to get shell and immediately ^D to continue boot

In the end the network filesystem is mounted and all is OK outside that.
The network filesystem is an USB stick connected to my router :

Code: 
//guest@ROUTEUR/nas     /shares/stick   smbfs   rw,late,-N       0       0
 
Hey great it works like that, thanks :)
... but it seems more like a workaround. What would cause the network to be so slow to be ok ? A known ale driver issue ?
Anyway I'll keep it like that. DHCP is better for my use than fixed @.
 
Running dhclient in the background is a relatively recent change. If there are non-network services starting, running dhclient in the background can speed up booting. SYNCDHCP runs it in the foreground, so the boot doesn't continue until dhclient gets a lease or gives up.
 
It's not a "workaround" it's a fix for the root cause of the issue. :)

In a "normal" boot, dhclient is run in the background so that other local daemons can load while the kernel waits for a DHCP lease. Hopefully, it gets a lease before any network services need to start.

However, if you find that your system is booting to the point where it's trying to start network services before a DHCP lease has been received, then you switch to "synchronous dhcp", which runs dhclient in the foreground and pauses the boot process until it get an IP or fails.

IOW, which you use depends on your environment.
 
@phoenix : I still consider this as a workaround since the system should start normally in fixed address mode. I mean it's a fix for the use of dhcp but I should not be forced to use dhcp, even it it's better for my usage. What if I have no dhcp server @ home ?
 
mururoa said:
@phoenix : I still consider this as a workaround since the system should start normally in fixed address mode. I mean it's a fix for the use of dhcp but I should not be forced to use dhcp, even it it's better for my usage. What if I have no dhcp server @ home ?
Click to expand...

You're not forced to use DHCP. If you set a static IP address in /etc/rc.conf, there is no dhclient , so no timing problem.
 
wblock said:
You're not forced to use DHCP. If you set a static IP address in /etc/rc.conf, there is no dhclient , so no timing problem.
Click to expand...

Read first post. I was in static IP and I had the problem. Only SYNCDHCP kinda solved my problem so far.
 
mururoa said:
Read first post. I was in static IP and I had the problem. Only SYNCDHCP kinda solved my problem so far.
Click to expand...

Your first post says you "solved it" by using a static IP. However, it gives no details, and maybe I'm reading it wrong. Please elaborate.
 
wblock said:
Your first post says you "solved it" by using a static IP. However, it gives no details, and maybe I'm reading it wrong. Please elaborate.
Click to expand...

First post says I solved dhcp problem when upgrading from 7.3 to 8.0 by using static IP and the problem comes back in 8.1 with static IP and was later 'fixed' with your help coming back to dhcp and syncdhcp.

7.3 dhcp ok
8.0 dhcp problem. Using static IP.
8.1 static IP problem. Using dhcp with syncdhcp.

I assume 8.0 dhcp problem is coming from not using syncdhcp but the question that remains is : why cant I use static IP with 8.1 ?
Of course my problem is solved with syncdhcp but I would be happy to understand the problem with static IP.
 
A better description would be "why isn't a static-IP ale0 ready in time for a smbfs mounted in mountlate?"

Maybe just a timing difference in 8.x, like ale0 taking a few seconds to initialize. One way to fix that would be to make the smbfs mount noauto, and then mount it later from a user script in /usr/local/etc/rc.d/.

A better way would be to modify /etc/rc.d/mountlate to be smarter about network file systems, like mountcritremote.
 
I'm having the same problem on my newly created FreeBSD 8.2-STABLE box - NFS exports, ntpd, etc all fail because they try to start before bge0 is fully configured. I am using a static address set in /etc/rc.conf and dhcp (thus syncdhcp) isn't an option for this server. Are there any plans to create an rc.conf setting we can use to say "wait until the network is up before calling any other network scripts"? Perhaps the defaultroute_delay flag could be changed to effect all network statup, not just dhcp?

Please?

nomad
 
Yes, it's coming in 9.0, and there are patches floating around for it on the mailing lists.

Search for Jeremy Chadwick's posts on /etc/rc.d/defaultroute on the -stable and -current mailing lists.

Basically, you give it an IP to connect to, and it will pause the boot process until that IP is reachable, meaning the network is up and configured.
 
Thank you, PR 151063 was exactly what I was looking for. I have no idea why my earlier Googling for it didn't find it, all the right keywords were there.
 
Another workaround regarding remote mounts is to use amd, if I've understood the problem correctly. This way, the system boots normally, since no remote mounts are located in /etc/fstab, and remote filesystems get mounted the first time the user wishes to access them. But *this* is indeed a workaround :-).
 
mamalos, I use amd quite heavily. The problem is this is a file server, not a client. The exports were failing because the hosts weren't known when mountd went to look (since DNS wasn't working since the network wasn't working...). The delay-until-ping solution solved this problem for me.
 
You must log in or register to reply here.
Back
Top