Core 18: NetworkManager definitions do not support name globbbing

device
1

I’m trying to install core18 with kernel 5.4. Everything boots fine, but when I get into the initial configuration screen and try to set up my networking, I am presented with this error:

Network configuration failed: 'ERROR: all-en: NetworkManager
        definitions do not support name globbing\n'

What does this mean? How do I fix it? I am not passing any network configuration through hooks or anything, what’s the deal?

2

I found something odd: In my /etc/netplan, there is a netplan called 99-device-config.yaml which contains the following:

# This is the initial network config.
# It can be overwritten by cloud-init or console-conf.
network:
    version: 2
    ethernets:
        all-en:
            match:
                name: "en*"
            dhcp4: true
        all-eth:
            match:
                name: "eth*"
            dhcp4: true

I think I found my globbing. Why this is “default” escapes me.

3

well, typically network-manager is not installed on Ubuntu Core and for user-less and headless images it makes sense to simply have the wired network device default to do dhcp … (i also doubt console-conf can actually deal with network-manager at all, if you ship NM you should also ship a configuration snap that uses dbus or nmcli to set the network-manager configuration)

4

Thanks for the advice! I’ll try rolling an image without NM and see how that works. Forgive my ignorance, but without NM, what software(s) do the network configuration/control?

5

that is systemd-networkd … note that netplan is indeed able to manage network-manager … but i dont think console-conf is able to recognize that NM is in use/installed …

6

Gotcha. I’ll keep that in mind.

I tried removing NetworkManager from my image, but now, I’m getting a seemingly random assortment of IPv4 and IPv6 addresses across some of my interfaces. When I was messing with this yesterday, eth0 had about 4 IPv6 addresses assigned to it, and I don’t know why. What could be causing that behavior?

8

I’ve had a similar issue and it due to a script requesting a new DHCP lease

9

Oh? Please share more details! I (kinda) solved this, but I don’t know if my solution is all that great. I just mess with the netplan in a configure hook.

10

I had a test in a script that did dhclient -r every day, which it then got assigned a new address every time and didn’t drop old ones (or renewed the original one for that matter). I didn’t have netplan running.

1 Like