1

I have a problem on Ubuntu Server 18.04 running on a RPi 3B+. When booting with only the wifi connection, the system hangs for 2 mins waiting on eth0 to connect. I've added optional: true, but it is ignored.

My /etc/netplan:

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    renderer: networkd
    ethernets:
        eth0:
            dhcp4: true
            match:
                macaddress: b8:27:eb:db:7f:54
            set-name: eth0
            optional: true
    wifis:
        wlan0:
            dhcp4: true
            access-points:
                "Lagrange Point 5G":
                     password: "*****"
            nameservers:
                addresses: [10.0.1.1, 8.8.8.8]

Here is the tail end of dmesg:

[   19.540586] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   19.540603] brcmfmac: power management disabled
[   19.546500] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  145.054536] new mount options do not match the existing superblock, will be ignored
[  152.587186] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Anyone know what I'm doing wrong?

EDIT: Added requested info...

$ sudo lshw -C network
  *-network:0               
       description: Wireless interface
       physical id: 2
       logical name: wlan0
       serial: b8:27:eb:9f:ba:34
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=brcmfmac driverversion=7.45.154 firmware=01-4fbe0b04 ip=10.0.1.38 multicast=yes wireless=IEEE 802.11
  *-network:1 DISABLED
       description: Ethernet interface
       physical id: 3
       logical name: eth0
       serial: b8:27:eb:ca:ef:61
       capacity: 1Gbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=lan78xx driverversion=1.0.6 link=no multicast=yes port=MII

And confirming netplan configuration:

$ cat /etc/network/interfaces
# ifupdown has been replaced by netplan(5) on this system.  See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
#    sudo apt install ifupdown

Btw, I have confirmed the exact same behavior on two different Raspberry Pi 3B+s, just to rule out bad hardware.

Edit #2: I updated my netplan as suggested by @heynnema and ran:

$ sudo netplan --debug generate
DEBUG:command generate: running ['/lib/netplan/generate']
** (generate:2077): DEBUG: 19:40:02.567: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:2077): DEBUG: 19:40:02.567: starting new processing pass
** (generate:2077): DEBUG: 19:40:02.568: wlan0: adding wifi AP 'Lagrange Point 5G'
** (generate:2077): DEBUG: 19:40:02.568: wlan0: setting default backend to 1
** (generate:2077): DEBUG: 19:40:02.568: eth0: setting default backend to 1
** (generate:2077): DEBUG: 19:40:02.568: Generating output files..
** (generate:2077): DEBUG: 19:40:02.568: wlan0: Creating wpa_supplicant configuration file run/netplan/wpa-wlan0.conf
** (generate:2077): DEBUG: 19:40:02.569: Creating wpa_supplicant service enablement link /run/systemd/system/multi-user.target.wants/netplan-wpa@wlan0.service
** (generate:2077): DEBUG: 19:40:02.569: NetworkManager: definition wlan0 is not for us (backend 1)
** (generate:2077): DEBUG: 19:40:02.569: NetworkManager: definition eth0 is not for us (backend 1)
DevLP
  • 11
  • In the meantime you can speed up your boot by telling it not to wait for the network to come up first: https://askubuntu.com/questions/1009999/slow-boot-time-on-ubuntu-17-10-1-systemd-analyze-blame-results/1010024#1010024 – WinEunuuchs2Unix Apr 05 '19 at 02:42
  • Edit your question and show me sudo lshw -C network and cat /etc/network/interfaces. Report back to @heynnema – heynnema Apr 05 '19 at 20:45
  • @heynnema, thank you for your interest in my problem. I've added the information you requested. It might also be worth noting that this wasn't a problem when running under raspbian. I switched over to Ubuntu Server to develop for Ubuntu Core, so the startup delay is a real problem for me. The device will have to be able to come up on wired ethernet or wifi without a 2 minute delay--something is weird here. – DevLP Apr 09 '19 at 23:33

2 Answers2

1

Your MAC address is wrong for eth0.

Try this .yaml file... keep the spacing, indentation, and no tabs...

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true
      optional: true
  wifis:
    wlan0:
      dhcp4: true
      access-points:
        "Lagrange Point 5G":
          password: "*****"
      nameservers:
        addresses: [10.0.1.1, 8.8.8.8]

sudo netplan --debug generate # generate config files

sudo netplan apply # apply new configuration

reboot # reboot, and confirm proper operation

Update #1:

Ended up putting on Ubuntu Server 19.04 which provided direct support for the RPi 3B+, and editing the .yaml file to include optional: true. Now boot times are around 30 seconds!

heynnema
  • 70,711
  • You're right. I removed the match clause, as you show above, and now it's picking up and using the proper MAC address. Unfortunately nothing else changed. I still have the exact same delay as shown in the question. For what it's worth, I thought you had it. I guess the match clause can be used as a way to override the MAC address. – DevLP Apr 10 '19 at 07:03
  • @DevLP did you use my .yaml script EXACTLY as shown, or did you just edit your original .yaml? See the minor update to my answer for the proper netpan commands... and do them all... edit your question and show me the output of those commands. – heynnema Apr 10 '19 at 13:03
  • @DevLP FYI... the match statement is for using the MAC address of a specific card to select it... whereas if you had multiple ethernet cards, you could make different scripts based on their MAC addresses. It's just a subset of eth0. It's not used to change MAC addresses. – heynnema Apr 10 '19 at 16:00
  • Other than my using four spaces instead of your two spaces and putting in the actual wifi password, the files are EXACTLY the same. I understand the sensitivity of python and yaml to tabs, etc. I don't really want to regenerate the file, but if you really feel that will make a difference I will. – DevLP Apr 11 '19 at 23:55
  • @DevLP I actually took out 3 lines, and reformatted, otherwise, they're similar (not EXACTLY) :-) Please do copy/paste my .yaml, do the generate/apply/reboot, and lets see if it makes any difference, ok? If it doesn't change anything, I'll suggest another minor edit. Report back. – heynnema Apr 12 '19 at 00:02
  • @DevLP Show me grep -i net.ifnames /etc/default/grub. – heynnema Apr 12 '19 at 00:22
  • Okay, I copied and pasted your netplan above, editing only the password, and generate gave an error: $ sudo netplan --debug generate DEBUG:command generate: running ['/lib/netplan/generate'] ** (generate:2105): DEBUG: 06:45:16.076: Processing input file /etc/netplan/50-cloud-init.yaml.. ** (generate:2105): DEBUG: 06:45:16.077: starting new processing pass Error in network definition /etc/netplan/50-cloud-init.yaml line 13 column 6: unknown key wlan0 – DevLP Apr 12 '19 at 06:54
  • Your requested grep gives: $ sudo grep -i net.ifnames /etc/default/grub grep: /etc/default/grub: No such file or directory – DevLP Apr 12 '19 at 07:02
  • @DevLP Embarrassed. I had the indentation on the wifis section wrong. Sorry 'bout that. Try it again please. With the grep command, I was looking for where the network names had been changed, from the unfriendly "ie: enp0s1" and "ie: wlp0s1" to eth0 and wlan0... and normally it's in the /etc/default/grub file. Do you remember changing a flag for network names? It would be a mod to the kernel boot line. – heynnema Apr 12 '19 at 10:05
  • @DevLP status please – heynnema Apr 14 '19 at 16:32
  • I'm sorry about the delay, but it's early Monday morning here in Oz and I'm back at it. You bring up a point that caught my curiosity as well. While I was happy to see the familiar eth0, etc., I didn't do anything to get them--I just downloaded the latest Ubuntu Server 18.04 for RPi. I'll rerun the config and post an update. – DevLP Apr 14 '19 at 19:36
  • See edit the question. I looks like using netplan has some issues at least on the RPi. Should I go back to ifupdown? I would like to stay standard Ubuntu if possible, but... – DevLP Apr 14 '19 at 19:49
  • @DevLP I assume that you did the sudo netplan apply and reboot, yes? Still doesn't work? Yes, you can certainly try ifupdown... but I won't be much help there, sorry. – heynnema Apr 14 '19 at 19:51
  • @DevLP just curious, what version of netplan do you have installed? dpkg -l netplan* – heynnema Apr 14 '19 at 19:59
  • Yeah, it still has the 2 min delay. If I go back to ifupdown, I might as well just go back to Raspbian. I had such high hopes for Ubuntu, but it doesn't seem it's support for the RPi is quite there yet. What are your thoughts? – DevLP Apr 14 '19 at 20:00
  • @DevLP see my netplan comment. – heynnema Apr 14 '19 at 20:01
  • Ah! It's netplan.io 0.40.1~18.04.4. – DevLP Apr 14 '19 at 20:02
  • @DevLP as a shot, you might try 18.10. – heynnema Apr 14 '19 at 20:03
  • Hum... That might be out of the frying pan and into the fire... – DevLP Apr 14 '19 at 20:04
  • @DevLP nothing to lose... and 19.04 is just a couple of days away... any of which might support your hardware better... – heynnema Apr 14 '19 at 20:28
  • Thanks, heynnema for your efforts on this. I went back to Raspbian as it just works. – DevLP Apr 15 '19 at 20:03
  • +1 because OP should have had you "tweak" your answer and accept it for all your hard work :) – WinEunuuchs2Unix Jul 30 '19 at 23:23
  • @WinEunuuchs2Unix thanks! I'm glad you saw all the work I put into this one. – heynnema Jul 30 '19 at 23:51
  • @DevLP I don't know if you'll ever signon again but if you do, consider accepting heynnema's answer with slight revision. Then he will get 15 rep points and you will get 2 points. Thanks ! – WinEunuuchs2Unix Jul 31 '19 at 01:04
0

Okay, I just couldn't leave this one alone... in for a penny, etc. I took @heynnema's advice and tried Ubuntu Server 19.04 and it worked beautifully. So, the answer is to go get it and forget 18.04 if you're on a Raspberry Pi 3B+ with this problem.

I did not try Ubuntu Server 18.10 as 19.04 had a statement claiming full support for the Raspberry Pi.

EDIT: I left the mac address match that Ubuntu 19 setup had added. Also, the "optional: true" is required. It boots now in 30s!

DevLP
  • 11