Really long boot after debian update

[atunguyd]

Hi wonder if someone here can possibly help me dubug this issue.

I have a home built NAS that up untill recently had been running wheezy with no graphical interface (console only as it is headless and boots off a SD card).
I decided that it is time to upgrade and I did a system upgrade to Jessie with no problems.
I then upgraded to Stretch and while it is running I am plagued by a really long (5 minute) boot time.

On boot I am seeing that the job that is taking long to start is networking.services and after booting and running a systemctl status networking.service i get the following:

Code: Select all

* networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-10-08 13:06:20 SAST; 13s ago
     Docs: man:interfaces(5)
  Process: 3911 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 3907 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (code=exited, status=1/FAILURE)
 Main PID: 3911 (code=exited, status=1/FAILURE)

Oct 08 13:06:20 debian systemd[1]: Starting Raise network interfaces...
Oct 08 13:06:20 debian ifup[3911]: ifup: unknown interface eth0
Oct 08 13:06:20 debian systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Oct 08 13:06:20 debian systemd[1]: Failed to start Raise network interfaces.
Oct 08 13:06:20 debian systemd[1]: networking.service: Unit entered failed state.
Oct 08 13:06:20 debian systemd[1]: networking.service: Failed with result 'exit-code'.
root@debian:~# systemctl start  networking.service
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.

And systemd-analyze blame has a line " 5min 96ms networking.service".

So it is definitely the network cards (board has 4 of them but I am only using one) that is causing the issue.
The outcome from journalctl -xe is linked here http://www.tunguydesmarais.com/journalctl.txt
Looking at it it is clear that the system is going into a roudn about loop of DHCP requesting and offering.
Since the netowrk is up after startup (as I am SSHing into the box) but networking.service is in a failed state I am assuming that there is some legacy networkign mechanism from wheezy or jessie that is fighting with networking.services but here my knowledge get limited.

Is anyone able to help step me through debugging this?
The contents of /etc/network/interfaces is:

Code: Select all

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

Removing the eth0 lines resolves the issue and notworking.service now runs but I have not network at all.

Also worth noting that there is no /dev/eth0 device in the system so I am not sure how it is working

I

[LE_746F6D617A7A69]

The interface name eth0 is no longer used (by default). To list available interfaces use:

Code: Select all

$>ip link

[sunrat]

Possibly the name of your network interface is different now. Check with

Code: Select all

ip link

[atunguyd]

I think I found it - looking here:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=873978
The source if the error was that if sendmail is not installed then the network service goes into this loop declining assigned IP addresses.
I was using exim 4 but an upgrade to buster seems to have removed exim4 and installed sendmail and the problem is gone (either patched in a new version of networkservice or because I switched to sendmail).
Now I just need to get sendmail to send me logs via email, I had switched to exim as it is much simpler to setup.

[LE_746F6D617A7A69]

The bug #873978 has nothing to do with the Your logs, and it has been fixed 3 years ago.
The error message is clear: "ifup: unknown interface eth0", and this has nothing to do with that bug.

The source if the error was that if sendmail is not installed then the network service goes into this loop declining assigned IP addresses.

Do You have any DHCP errors logged?

[atunguyd]

IF you look at that bug it exhibited teh same symptoms as the log file that I listed an massive dump of DHCP retries with DHCP declines (despinte the DHCP actually not declining it).

And the person who logged that bug found that the error lied in the line:
/sbin/dhclient-script: 28: . :Can't open /usr/share/sendmail/dynamic
I had the same error in my log.

Anyway it is now resolved and things are working, perhaps the upgrade to buster gave me the fix or perhaps the script could now open /usr/share/sendmail/dynamic, whichever it is I am sorted thanks.

[LE_746F6D617A7A69]

I had the same error in my log.

You didn't showed that log entry.

Anyway it is now resolved and things are working

Uhm, and the error message regarding non-existing interface eth0 have disappeared because You have cleaned-up the config files left by sendmail? Nice job ...

[atunguyd]

I had the same error in my log.

You didn't showed that log entry.

Actually I did show that log -it was in my original post as a link to a log file simply because it was too big to copy and paste into the post.

Anyway it is now resolved and things are working

Uhm, and the error message regarding non-existing interface eth0 have disappeared because You have cleaned-up the config files left by sendmail? Nice job ...

I really cant explain it because the network cards were always being referred to as eth0, eth1, eth2 and eth3 and a call to "ip link" showed all 4 just for some reason networking.service was throwing that error (after five minutes of sitting there like it was hung".

Anyway as I said it is resolved, dont know how but it is - unfortunately though if someone else runs into similar this thread probably wont help them.