Network is unreachable in Fedora 41 container on Incus

Incus
1

Hi, I launched a Fedora 41 container on Incus and got “Network is unreachable” error when I tried to “ping 8.8.8.8”.

$ incus launch images:fedora/41/cloud f41
$ incus exec f41 -- ping 8.8.8.8
ping: connect: Network is unreachable

eth0 does not have an IP address:

 incus exec f41 -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo
       valid_lft forever preferred_lft forever
824: eth0@if825: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 10:66:6a:f6:b0:bf brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fd42:29d5:3d13:9b8d:1266:6aff:fef6:b0bf/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft forever preferred_lft forever
    inet6 fe80::1266:6aff:fef6:b0bf/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

journalctl shows a lot of “Permission denied” logs, but I don’t know whether these are OK or not.

$ incus exec f41 -- journalctl
Mar 31 12:32:50 f41 systemd-journald[138]: Journal started
Mar 31 12:32:50 f41 systemd-journald[138]: Runtime Journal (/run/log/journal/b6599d3870984156a0942fb4ad586a72) is 8M, max 1.8G, 1.8G free.
Mar 31 12:32:50 f41 systemd[1]: Starting systemd-journal-flush.service - Flush Journal to Persistent Storage...
Mar 31 12:32:50 f41 systemd-journald[138]: Time spent on flushing to /var/log/journal/b6599d3870984156a0942fb4ad586a72 is 416us for 3 entries.
Mar 31 12:32:50 f41 systemd-journald[138]: System Journal (/var/log/journal/b6599d3870984156a0942fb4ad586a72) is 1K, max 4G, 3.9G free.
Mar 31 12:32:50 f41 udevadm[144]: ac97: Failed to write 'add' to '/sys/bus/ac97/uevent': Permission denied
Mar 31 12:32:50 f41 udevadm[144]: acpi: Failed to write 'add' to '/sys/bus/acpi/uevent': Permission denied
Mar 31 12:32:50 f41 udevadm[144]: battery: Failed to write 'add' to '/sys/bus/acpi/drivers/battery/uevent': Permission denied
Mar 31 12:32:50 f41 udevadm[144]: button: Failed to write 'add' to '/sys/bus/acpi/drivers/button/uevent': Permission denied
Mar 31 12:32:50 f41 udevadm[144]: ec: Failed to write 'add' to '/sys/bus/acpi/drivers/ec/uevent': Permission denied
Mar 31 12:32:50 f41 udevadm[144]: hardware_error_device: Failed to write 'add' to '/sys/bus/acpi/drivers/hardware_error_device/uevent': Permission denied...(snip)...

I’m running the latest stable version of Incus on Ubuntu 24.04.

$ dpkg -l | grep incus
ii  incus                                          1:6.11-ubuntu24.04-202503282159                                 amd64        Incus - Container and virtualization daemon
ii  incus-base                                     1:6.11-ubuntu24.04-202503282159                                 amd64        Incus - Container and virtualization daemon (container-only)
ii  incus-client                                   1:6.11-ubuntu24.04-202503282159                                 amd64        Incus - Command line client
ii  incus-migrate                                  6.0.0-1ubuntu0.2                                                amd64        Incus physical to instance migration tool
2

On first glance, I think that this might be the same issue as Containers from Fedora images launch with no network .

Does the command below restore network functionality?

incus exec f41 -- systemctl start systemd-networkd
1 Like
3

I think I have seen this issue discussed here recently.
I cannot find the discussion at the moment.

Incus does what is needed to the container image (images:fedora/41/cloud), which means that it places the appropriate file /etc/systemd/network/10-cloud-init-eth0.network with contents:

[Match]
Name=eth0

[Network]
DHCP=yes

The problem is that when the specific runtime is starting up, it does not perform the network configuration. Therefore, it’s an issue of not performing the network configuration while the device eth0 is out there and available.

The immediate workaround for now is to do the following manually.

incus exec f41 -- systemctl start systemd-networkd

The result is as follows. (the final octet of the IP address was really 41 :slight_smile: )

$ incus list -cn4 f41
+------+--------------------+
| NAME |        IPV4        |
+------+--------------------+
| f41  | 10.10.10.41 (eth0) |
+------+--------------------+
2 Likes
4

It solved the issue.
Thank you!

5

Thank you for your detailed explanation!

I conffirmed that what you said:

$ incus launch images:fedora/41/cloud f41c2
$ incus exec f41c2 -- cat /etc/systemd/network/10-cloud-init-eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes
$ incus list -cn4 f41c2
+-------+------+
| NAME  | IPV4 |
+-------+------+
| f41c2 |      |
+-------+------+
$ incus exec f41c2 -- systemctl start systemd-networkd
$ incus list -cn4 f41c2
+-------+----------------------+
| NAME  |         IPV4         |
+-------+----------------------+
| f41c2 | 10.250.115.61 (eth0) |
+-------+----------------------+

I had created a container with fedora/41/cloud image few weeks ago and the network worked without this workaround at that time.

6

I found the systemd-networkd service is not enabled.

$ incus exec f41c2 -- systemctl is-enabled systemd-networkd
disabled
7

The tool that is used to create those container images is distrobuilder (GitHub - lxc/distrobuilder: System container image builder for LXC and Incus).

The configuration file for Fedora in distrobuilder can be found here, https://github.com/lxc/lxc-ci/tree/main/images In the configuration you can see that the tool will grab the files from the Fedora project will building the container image.

However, it may be something that changed upstream though in Fedora that has the effect of not getting the networking to run upon the start of the runtime.

I think this was discussed a few months back but my searching did not get a result. Perhaps the title of that thread is not matching my search keywords.

2 Likes