[Solved] Re: Delay at boot - network
Hi Brian, as promised, I want to report my last experiences. The problem with the delay on both of my notebooks is solved. Due to your help, I could figured out, that the process network-manager caused the delay. This happened, because the purge of the package was not completed, so that binary files and some config files stayed on the system. New installation and then deinstallation with purge did the trick. A similar problem was with my EEEPC. In this case, the package ntpdate searched for an IP 192.168.178.1 (which is my fritzbox), and did not find it. Of course it cannot find it, because I am behind another router, with the IP range 192.168.1.*. However, in none of the configuration files of ntpdate the IP 192.168.178.1 appeared! As ntpdate is not necessary and is fully successed through the package ntp, I deinstalled and purged ntpdate and everything was working again. Thank you for pointing me to the systemctrl commands, so I could see, learn and solve the problem. Best Hans
Re: Delay at boot - network
> > I have to onspect this, too. Please do nothing at the moment, I have to > check several things, and then I will send message again. > > Thanks for the hints, I will come back. > > Best > > Hans I am answering myself. I found a lot of files belonging to package "network- manager", which I had installed some weeks ago. It is not explainable, why so much is left from the package, after deinstallation. Strangely I had to install the package, then deinstall the package, to get rid of the crap. Although I am always using the "purge" directive with aptitude, there were about 7 files left, even in /etc, /usr/lib and /usr/bin. Weired Looks like either the package has changed during the last weeks or something in the database of dpkg was not ok. Hans
Re: Delay at boot - network
Hi Brian, > systemd is waiting for some script to complete. It doesn't just carry on > immediately in case something gets broken. > > Boot with 'systemd.log_level=debug' and examine 'journalctl --alb' closely. I did, as you told, and strangely, at the moment this behaviour disappered. However, it may be related to a new behaviour: After booting the system up, wlan is not available. I have to do: rmmod ath5k modprobe ath5k then start wicd and connection works. This is part of the output of the journal, maybe it helps. .. .. Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/21 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=28 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 kernel: ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Mai 25 20:10:02 protheus2 kernel: ath5k: phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70) Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/83 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=30 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/83 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=29 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/45 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=31 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/45 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=30 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/92 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=32 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/92 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=31 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/55 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=33 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/55 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=32 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=JobNew cookie=34 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=JobNew cookie=33 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/16 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=35 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/16 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=34 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/57 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=36 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/57 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=35 reply_cookie=0 error=n/a . . . Mai 25 20:10:02 protheus2 systemd[1]: dev-sda5.device: Merged into installed job dev-sda5.device/start as 93 Mai 25 20:10:02 protheus2 systemd[1]: laptop-mode.service: Enqueued job laptop-mode.service/start as 183 Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=method_return sender=n/a destination=n/a object=n/a interface=n/a member=n/a cookie=46 reply_cookie=1 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/93 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=47 reply_cookie=0 error=n/a Mai 25 20:10:02 protheus2 systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/job/93
Re: Delay at boot - network
On Wed 25 May 2016 at 12:20:52 +0200, Hans wrote: > > When you get this delay, what's in the scrolling messages in the last > > few lines > > before the delay itself? > The last message is: > started konsole fonts and Not likely to be the problem. > Then: > (1 of 1) A start job is running for LSB: Raise network interfaces. (1min 30s > / > 5min 30s) Some script in /etc/init.d which uses the network could be cause. > > Are they (on your various machines) always the same sorts of lines? > Yes, different times are shown, but in the same manner. > > I googled a bit, and it might be related to systemd. Other people got the > same > problem, with different delay times (up to 15 minutes). That happened mostly > after an upgrade. systemd is waiting for some script to complete. It doesn't just carry on immediately in case something gets broken. Boot with 'systemd.log_level=debug' and examine 'journalctl --alb' closely. > Note: I am using /etc/network/interfaces and network-manager is not installed. > As others mentioned, I commented "allow hotplug" line out, with no success. > > This behaviour seem to be a well known problem, buit it looks like there is > no > general solution. > > I have erverything static! Here is my complete /etc/network/interfaces: [...snip...] The idea to boot with only eth0 in the interfaces file is a good one.
Re: Delay at boot - network
On Wed, 25 May 2016, Hans wrote: Date: Wed, 25 May 2016 06:20:52 From: Hans <hans.ullr...@loop.de> To: debian-user@lists.debian.org Cc: Jeremy Nicoll <jn.ml.dbn...@letterboxes.org> Subject: Re: Delay at boot - network Resent-Date: Wed, 25 May 2016 10:21:30 + (UTC) Resent-From: debian-user@lists.debian.org When you get this delay, what's in the scrolling messages in the last few lines before the delay itself? The last message is: started konsole fonts and Then: (1 of 1) A start job is running for LSB: Raise network interfaces. (1min 30s / 5min 30s) Are they (on your various machines) always the same sorts of lines? Yes, different times are shown, but in the same manner. I googled a bit, and it might be related to systemd. Other people got the same problem, with different delay times (up to 15 minutes). That happened mostly after an upgrade. Note: I am using /etc/network/interfaces and network-manager is not installed. As others mentioned, I commented "allow hotplug" line out, with no success. This behaviour seem to be a well known problem, buit it looks like there is no general solution. I have erverything static! Here is my complete /etc/network/interfaces: snip - auto lo wlan0 eth0 usb0 iface lo inet loopback address 127.0.0.1 netmask 255.0.0.0 iface eth0 inet static address 192.168.2.12 netmask 255.255.255.0 broadcast 192.168.2.255 gateway 192.168.2.1 Accesspoint # # iface eth1 inet static # wireless_mode Master # wireless_essid any # wireless_keymode open # wireless_channel 3 # address 192.168.5.1 # netmask 255.255.255.0 # broadcast 192.168.5.255 # gateway 192.168.5.1 at home ## iface wlan0 inet static address 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 wpa-driver wext wpa-scan-ap 1 wpa-key-mgt WPA-PSK wpa-ssid anonymized wpa-psk anonymized dns-nameservers 208.67.222.222 208.67.220.220 # iface wlan0 inet static # address 192.168.1.102 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.2 # wireless_mode managed # wireless_essid stargazer # wireless_key 3A1B3C3EF9 # wireless_keymode open # dns-nameservers 208.67.222.222 208.67.220.220 Experimental # iface wlan1 inet static # address 10.5.5.1 # netmask 255.255.255.0 # network 10.5.0.0 # broadcast 10.5.5.255 # gateway 192.168.1.1 # iface wlan1 inet dhcp # wireless_mode ad-hoc # wireless_keymode open # wireless_key off # wireless_ap 10.2.46.1 on the road ## # iface wlan0 inet dhcp # wireless_mode managed # wireless_essid any # wireless_key off # wireless_ap auto # wireless_keymode open # iface wlan0 inet static # address 192.168.1.30 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.1 # wireless_mode managed # wireless_essid any # wireless_key off # wireless_ap auto # wireless_keymode open mit WPA ## # iface wlan0 inet dhcp # pre-up /sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf # Work network configuration # iface eth0 inet static # address 192.168.1.102 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.1 mapping hotplug script grep map usb0 iface usb0 inet static address 192.168.129.1 network 192.168.129.0 netmask 255.255.255.0 broadcast 192.168.129.255 -- snap -- Most entries are commented out. And as you see, everything is static, NO dhcp. This configuration is now unchanged for many years. Looks for me like a timeout problem somewhere. Hope this helps. Best Hans I have this error too and I'm trying to bring up networking from command line interface as well. One package I forgot to install which may be causing my error is crda and I'll also have to configure that package for in my case the United States. It may be a missing crda package is doing this unless debian installer installs and/or correctly configures crda for users using wifi connections automatically. Hope this helps. --
Re: Delay at boot - network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 25, 2016 at 12:20:52PM +0200, Hans wrote: > > When you get this delay, what's in the scrolling messages in the last > > few lines > > before the delay itself? > The last message is: > started konsole fonts and > > Then: > (1 of 1) A start job is running for LSB: Raise network interfaces. (1min 30s > / > 5min 30s) > > > > Are they (on your various machines) always the same sorts of lines? > Yes, different times are shown, but in the same manner. > > I googled a bit, and it might be related to systemd. Other people got the > same > problem, with different delay times (up to 15 minutes). That happened mostly > after an upgrade. > > Note: I am using /etc/network/interfaces and network-manager is not installed. > As others mentioned, I commented "allow hotplug" line out, with no success. > > This behaviour seem to be a well known problem, buit it looks like there is > no > general solution. > > I have erverything static! Here is my complete /etc/network/interfaces: Sorry I can't help you much with systemd. My knowledge level there is insignificant. But there are folks around here who should be better at this. There's a tool around systemd which helps you debug what's happening when and how long it takes. That might offer you some clues. The other thing I'd try is selectively enabling the interfaces in /etc/nework/interfaces and seeing how that impacts behaviour (e.g. all disabled, only eth0, only usb0, and so on). Sorry for being so unspecific. Regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAldFspYACgkQBcgs9XrR2kZJ5wCfaAS3GQv89cTFTwmgNjvxh999 MG8An23eIhx+WyaPxB+jH0sjLm2otxNg =JPuB -END PGP SIGNATURE-
Re: Delay at boot - network
> When you get this delay, what's in the scrolling messages in the last > few lines > before the delay itself? The last message is: started konsole fonts and Then: (1 of 1) A start job is running for LSB: Raise network interfaces. (1min 30s / 5min 30s) > > Are they (on your various machines) always the same sorts of lines? Yes, different times are shown, but in the same manner. I googled a bit, and it might be related to systemd. Other people got the same problem, with different delay times (up to 15 minutes). That happened mostly after an upgrade. Note: I am using /etc/network/interfaces and network-manager is not installed. As others mentioned, I commented "allow hotplug" line out, with no success. This behaviour seem to be a well known problem, buit it looks like there is no general solution. I have erverything static! Here is my complete /etc/network/interfaces: snip - auto lo wlan0 eth0 usb0 iface lo inet loopback address 127.0.0.1 netmask 255.0.0.0 iface eth0 inet static address 192.168.2.12 netmask 255.255.255.0 broadcast 192.168.2.255 gateway 192.168.2.1 Accesspoint # # iface eth1 inet static # wireless_mode Master # wireless_essid any # wireless_keymode open # wireless_channel 3 # address 192.168.5.1 # netmask 255.255.255.0 # broadcast 192.168.5.255 # gateway 192.168.5.1 at home ## iface wlan0 inet static address 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 wpa-driver wext wpa-scan-ap 1 wpa-key-mgt WPA-PSK wpa-ssid anonymized wpa-psk anonymized dns-nameservers 208.67.222.222 208.67.220.220 # iface wlan0 inet static # address 192.168.1.102 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.2 # wireless_mode managed # wireless_essid stargazer # wireless_key 3A1B3C3EF9 # wireless_keymode open # dns-nameservers 208.67.222.222 208.67.220.220 Experimental # iface wlan1 inet static # address 10.5.5.1 # netmask 255.255.255.0 # network 10.5.0.0 # broadcast 10.5.5.255 # gateway 192.168.1.1 # iface wlan1 inet dhcp # wireless_mode ad-hoc # wireless_keymode open # wireless_key off # wireless_ap 10.2.46.1 on the road ## # iface wlan0 inet dhcp # wireless_mode managed # wireless_essid any # wireless_key off # wireless_ap auto # wireless_keymode open # iface wlan0 inet static # address 192.168.1.30 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.1 # wireless_mode managed # wireless_essid any # wireless_key off # wireless_ap auto # wireless_keymode open mit WPA ## # iface wlan0 inet dhcp # pre-up /sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf # Work network configuration # iface eth0 inet static # address 192.168.1.102 # netmask 255.255.255.0 # broadcast 192.168.1.255 # gateway 192.168.1.1 mapping hotplug script grep map usb0 iface usb0 inet static address 192.168.129.1 network 192.168.129.0 netmask 255.255.255.0 broadcast 192.168.129.255 -- snap -- Most entries are commented out. And as you see, everything is static, NO dhcp. This configuration is now unchanged for many years. Looks for me like a timeout problem somewhere. Hope this helps. Best Hans
Re: Delay at boot - network
On Mon, 23 May 2016, at 08:49, Hans wrote: > > I see. Sorry I'm a bit pressed now. Look through those two bug reports > > and let us know wheter anything sounds familiar: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218 > > Yes, both bugreports describe, what I also discovered. However, my > environment > does not use NFS (like one uses), and I have not to wait at shutdown, as > the > other one describes. But the behaviour at boot is the same, as in these > bugreports is described. When you get this delay, what's in the scrolling messages in the last few lines before the delay itself? Are they (on your various machines) always the same sorts of lines? -- Jeremy Nicoll - my opinions are my own.
Re: Delay at boot - network
> I see. Sorry I'm a bit pressed now. Look through those two bug reports > and let us know wheter anything sounds familiar: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218 Yes, both bugreports describe, what I also discovered. However, my environment does not use NFS (like one uses), and I have not to wait at shutdown, as the other one describes. But the behaviour at boot is the same, as in these bugreports is described. > > Are you running SysV init or systemd? > My environment: I am running debian/testing with systemd. The partitions /home, /usr and /var are seperated and they are encrypted with luks. All partitions mount at boot well. I am running this profile now for many years. The behaviour did NOT appear with the change from SysV to systemd, but a long long time later. It definetely appeared with a kernel upgrade. Sadly I cannot tell, which kernel version did this change. As I recognized this as a feature not a bug, I did not file a bugreport at that time, sorry for that. Maybe you should know, that it also appears on all hardware (I have an EEEPC, some Desktop PC's and an Acer Aspire 7520 notebook). Please feel free to ask for more information. > regards > -- tomás Best Hans
Re: Delay at boot - network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, May 23, 2016 at 09:13:52AM +0200, Hans wrote: > Hi Tomas, > > > Hmm, the DNS is also preconfigured. I see a counter at boot, which counts > > > up to 1min 30 sec, then continues booting. > > > > That sounds strange. Can you describe that? > > Well, you see all the messages at boot. Then, when it comes to the network, > the scrolling of the messages stop and there is a line like this (Note the > text is not original!!!: > > network startimg anbd so on snd so on (30sec/5min) > > You see the counter of the "30sec" count up to 1min30, then the boot process > is continuing. > > Does this help? Maybe someone else can describe better, someone with better > background know-hnow and maybe English natively speaking. I see. Sorry I'm a bit pressed now. Look through those two bug reports and let us know wheter anything sounds familiar: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218 Are you running SysV init or systemd? regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAldCsN4ACgkQBcgs9XrR2kblGgCePX/So9IA6B8uPuaYLTL0IHFD +c8Amwal6IG0XXi1wVsiuLQDsCvLFpy6 =rjyC -END PGP SIGNATURE-
Re: Delay at boot - network
Hi Tomas, > > Hmm, the DNS is also preconfigured. I see a counter at boot, which counts > > up to 1min 30 sec, then continues booting. > > That sounds strange. Can you describe that? Well, you see all the messages at boot. Then, when it comes to the network, the scrolling of the messages stop and there is a line like this (Note the text is not original!!!: network startimg anbd so on snd so on (30sec/5min) You see the counter of the "30sec" count up to 1min30, then the boot process is continuing. Does this help? Maybe someone else can describe better, someone with better background know-hnow and maybe English natively speaking. > -- tomás Hans
Re: Delay at boot - network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, May 22, 2016 at 10:33:47PM +0200, Hans wrote: > Hi Tomas, > > Sorry I can't be more specific, but 1.5 minutes looks a bit like a name > > resolution timeout. > > > Hmm, the DNS is also preconfigured. I see a counter at boot, which counts up > to > 1min 30 sec, then continues booting. That sounds strange. Can you describe that? >If necessary, I can create a video within > virtualbox, but this should be an exception, shouldn`t it? No, sorry. I only "do" text. > I believe, the delay might be caused by a mega check (maybe testing a lot of > networkcards or firmwares, whatever), but that is just an idea. > > regards Hm. Doesn't ring a bell with me. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAldCqzwACgkQBcgs9XrR2kZHMACfanGNaUlT/mg9ElmY7j8pdPeG 6ncAn29Q5s1/29ntz3jbkMdryI3UP8Qf =7BAN -END PGP SIGNATURE-
Re: Delay at boot - network
Hi Tomas, > Sorry I can't be more specific, but 1.5 minutes looks a bit like a name > resolution timeout. > Hmm, the DNS is also preconfigured. I see a counter at boot, which counts up to 1min 30 sec, then continues booting. If necessary, I can create a video within virtualbox, but this should be an exception, shouldn`t it? I believe, the delay might be caused by a mega check (maybe testing a lot of networkcards or firmwares, whatever), but that is just an idea. > regards > -- tomás Best Hans
Re: Delay at boot - network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, May 22, 2016 at 10:04:53PM +0200, Hans wrote: > Hello list, > > I do not want to mourn, just searching for an info. > > Can someone tell me, what has changed in the kernel (I believe, it is since > kernel 3.4, but do not know exactly), that the boot progress hangs about 1 - > 1,5 minutes, when the network is started? Sorry I can't be more specific, but 1.5 minutes looks a bit like a name resolution timeout. regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAldCFcYACgkQBcgs9XrR2kYofACfWASHjAMqshBgQmGDqWjO+VWb klwAn32+MBej2KjTjHctpMe55OCKulF1 =U6LZ -END PGP SIGNATURE-
