FEDORA-32: In LXC container, eth0 not configured on boot

Ask Fedora
1

Hello Friends:

- OS: Fedora-32 (64bit)
- LXC Guest (although I don't think this matters)

I upgraded a LXC container from Fedora-30 to Fedora-32, and after the upgrade eth0 no longer gets configured automatically. I have to login via the console and bring it up manually. This (and the below) was working fine in Fedora-30, before the upgrade. By the way, I’m using static IP addressing.

Everything looks good, but perhaps I’m missing something new in Fedora-32. Here’s my configuration:

/etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=none
GATEWAY=192.168.0.1
NETMASK=255.255.255.0
ONBOOT=yes
DNS1=8.8.8.8
TYPE=Ethernet
IPV6INIT=no
USERCTL=no
PREFIX=24
DEFROUTE=yes
NAME=eth0
NM_CONTROLLED=yes # Temporarily set to "yes" so nmcli(1) sees it.
#NM_CONTROLLED=no # This is the usual setting (as was in FC30).
IPADDR=192.168.0.200
HWADDR=22:22:22:22:22:20
PROXY_METHOD=none
BROWSER_ONLY=no
IPV4_FAILURE_FATAL=no
UUID=<long-cipher-text-string>

Status of NetworkManager:

root@# ps -ef | grep NetworkManager
root 87 1 0 19:49 ? 00:00:00 /usr/sbin/NetworkManager --no-daemon

NOTE: For debugging purposes, above I temporarily set NM_CONTROLLED to yes just to see what nmcli(1) has to say; but as with FC30, I prefer having it as no (i.e. hidden from NetworkManager).

Thus, few key nmcli settings:

root# nmcli connection show eth0 | egrep 'connection.interface-name:|connection.autoconnect:'
connection.interface-name:              eth0
connection.autoconnect:                 yes

Output of ifconfig -a (eth0 not configured):

br-97f41e8a9474: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.10.0.1  netmask 255.255.0.0  broadcast 172.10.255.255
        ether 02:42:6f:f1:6c:18  txqueuelen 0  (Ethernet)
        RX packets 38  bytes 4502 (4.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 26  bytes 3327 (3.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:4c:0c:fb:89  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2022:22ff:fe22:2220  prefixlen 64  scopeid 0x20<link>
        ether 22:22:22:22:22:20  txqueuelen 1000  (Ethernet)
        RX packets 38  bytes 4502 (4.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 26  bytes 3327 (3.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I have to perform the following to bring eth0 up:

# With NetworkManager involvement:
root# nmcli connection up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

# --OR--

# Without NetwokManager involvement:
root# ifconfig eth0 192.168.0.200
root# route add default gw 192.168.0.1

root# ifconfig -a # (eth0 is configured)
br-97f41e8a9474: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.10.0.1  netmask 255.255.0.0  broadcast 172.10.255.255
        ether 02:42:6f:f1:6c:18  txqueuelen 0  (Ethernet)
        RX packets 122  bytes 19872 (19.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 51  bytes 6092 (5.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:4c:0c:fb:89  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.200  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::2022:22ff:fe22:2220  prefixlen 64  scopeid 0x20<link>
        ether 22:22:22:22:22:20  txqueuelen 1000  (Ethernet)
        RX packets 122  bytes 19872 (19.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 51  bytes 6092 (5.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
172.10.0.0      0.0.0.0         255.255.0.0     U         0 0          0 br-97f41e8a9474
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Any ideas friends? Back in the day this use to be dead simple: One config file and done. Now after every upgrade there is drama. :neutral_face:

Thank you in advance! :blush:

2

I think eth0 could be the problem.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-Troubleshooting_Network_Device_Naming

Kernel uses the eth X naming convention at boot time when it enumerates network devices. The eth X names are inconsistent across various reboots, and thus they are unpredictable. Consequently, attempting to use udev to rename an interface to a predictable name or to reorder the unpredictable eth X names given by the kernel fails.

Using the eth X names works correctly for the following scenarios:

  • The system has only one network interface.

  • When used for virtio NICs in Red Hat Enterprise Linux 7 virtual machine guests. See the KVM Paravirtualized (virtio) Drivers and Network Configuration chapters in the Virtualization Deployment and Administration Guide

1 Like
3

systemd-networkd in LXC containers worked pretty well for me.
It’s a single simple config just as you want:
https://wiki.archlinux.org/index.php/systemd-networkd#Configuration_examples
You can even remove NM entirely from the containers.

4

Hi @ilikelinux @vgaetera

Thank you for your replies. Let me study and try them and I’ll report back. =:)

1 Like