0

Problem: 5 minute delay on startup

Device: UP board (small x86 board), running 18.04, with a Panda PAU05 wireless USB adapter, connected via HDMI to a monitor

Network configuration: using netplan and systemd-networkd. NetworkManager is not installed.

When the Ethernet is connected, the device boots up quickly. I can unplug the Ethernet and rely on wifi. SSH works, etc.

When the Ethernet is not connected, there's a 5 minute delay. The console says A start job is running for Raise network interfaces (Xmin Ys / 5min 2s) and slowly counts up to 5min 2s. I can ping the device, but ssh is refused: ssh: connect to host rodeobot.local port 22: Connection refused. After 5 minutes the boot completes fine.

I tinkered with my netplan to make both ethernet and wifi interfaces optional, but this doesn't help. I also tried removing the ethernet interface, but that didn't help. Here's the /etc/netplan/config.yaml I'm running now:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      optional: true  # Don't wait for Ethernet
      dhcp4: true
  wifis:
    wlx9cefd5fcb328:
      optional: true  # Don't wait for Wifi
      dhcp4: true
      access-points:
        "xxx":
          password: "yyy"

Edit: I see several similar questions, but I don't see an answer that uses netplan. Is this a bug / missing feature in netplan?

Edit: fixed indentation and commenting in config.yaml. (I copied and pasted, then edited the ssid and pw.)

Edit: here's the result of sudo netplan --debug generate:

** (generate:965): DEBUG: 18:35:38.361: Processing input file /etc/netplan/config.yaml..
** (generate:965): DEBUG: 18:35:38.362: starting new processing pass
** (generate:965): DEBUG: 18:35:38.362: wlx9cefd5fcb328: adding wifi AP 'Beckett'
** (generate:965): DEBUG: 18:35:38.362: wlx9cefd5fcb328: setting default backend to 1
** (generate:965): DEBUG: 18:35:38.362: Configuration is valid
** (generate:965): DEBUG: 18:35:38.362: enp1s0: setting default backend to 1
** (generate:965): DEBUG: 18:35:38.362: Configuration is valid
** (generate:965): DEBUG: 18:35:38.363: Generating output files..
** (generate:965): DEBUG: 18:35:38.363: NetworkManager: definition enp1s0 is not for us (backend 1)
** (generate:965): DEBUG: 18:35:38.363: wlx9cefd5fcb328: Creating wpa_supplicant configuration file run/netplan/wpa-wlx9cefd5fcb328.conf
** (generate:965): DEBUG: 18:35:38.363: Creating wpa_supplicant service enablement link /run/systemd/system/systemd-networkd.service.wants/netplan-wpa@wlx9cefd5fcb328.service
** (generate:965): DEBUG: 18:35:38.364: NetworkManager: definition wlx9cefd5fcb328 is not for us (backend 1)

Thanks.

  • You've commented out "ethernets", and your indentation is incorrect. See my answer. – heynnema Jun 2 at 21:22
  • Check that your /usr/share directory is present owned by root, with 755 permissions. I just saw a virtually identical error when a simlink for /usr/share was bad. – ubfan1 Jun 2 at 21:52
  • Thanks @heynnema. That was a copy/paste error. I verified that I'm running your correct version, and updated the question. – Clyde McQueen Jun 3 at 1:34
  • Thanks @ubfan1, I just checked, and /usr/share is owned by root, and has 755 permissions. – Clyde McQueen Jun 3 at 1:35
  • Does your wifi interface wlx9cefd5fcb328 have a route to the Internet, or is it local only? – slangasek Jun 3 at 22:35
0
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      optional: true  # Don't wait for Ethernet
      dhcp4: true
  wifis:
    wlx9cefd5fcb328:
      optional: true  # Don't wait for Wifi
      dhcp4: true
      access-points:
        "xxx":
          password: "yyy"

sudo netplan --debug generate # generate config files

sudo netplan apply # apply new configuration

reboot # verify proper operation

  • Still no luck. I added the results of sudo netplan --debug generate in case that helps. – Clyde McQueen Jun 3 at 1:38
  • @ClydeMcQueen Temporarily comment out all of the wifis stanza, leave just the ethernets, netplan generate/apply, and retest. If that doesn't work, temporarily remove dhcp4, set a static address and gateway, and retest. Report back. – heynnema Jun 3 at 2:54
  • Thanks for all of your help. My solution was to edit /etc/network/interfaces by hand, replacing auto enp1s0 with allow-hotplug enp1s0. I am surprised that sudo netplan apply didn't edit that file. I'm somewhat worried that my networking install is a bit broken. But now my boot times are quick w/ or w/o Ethernet plugged in. – Clyde McQueen Jun 4 at 3:16
0

It turns out that enp1s0 wasn't managed by systemd-networkd, and therefore netplan had no effect. I discovered this by looking at the logs:

journalctl | grep enp1s0 | grep "managed by us"

I found a number of entries that looked like this:

systemd-networkd: enp1s0: Link is not managed by us

The fix was to remove the ifupdown package. For good measure (and to make sure I didn't forget!) I moved the /etc/network directory:

sudo apt remove ifupdown
sudo mv /etc/network /etc/network_old_ifupdown
sudo reboot now

While looking at the logs I also fixed a problem with resolv.conf -- I had a bad symlink. There's a good explanation here: New alert keeps showing up: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001

Thanks to folks that helped!

  • This is not the right fix for this problem. – heynnema Jun 8 at 19:09
  • I'm not sure what you mean. It fixed it for me. – Clyde McQueen Jun 10 at 0:50
  • That's because you were mixing Network-Manager and netplan commands. Your specific problem was with /etc/network/interfaces, and by renaming /etc/network, you just got that file out of the way. You should have just left /etc/network/interfaces as you found it originally, and not uninstalled portions of the OS to "fix" a different part of the system. You've handicapped your OS. – heynnema Jun 10 at 1:06
  • Yes, this device had a tortured history: a clean 16.04 desktop install, then I attempted to remove all vestiges of the GUI when it became a headless device. I should have wiped it and installed 16.04 server. In fact, there's still time to wipe it an install 18.04 server, which might fix a few other things. Thanks again. – Clyde McQueen Jun 10 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.