Hi,
I have installed incus in a Fedora server using the ganto repository at Getting Started with Incus on Fedora · ganto/copr-lxc4 Wiki · GitHub. The installation and setup seems to go fine, but when I create my first container it does not get an IPv4 address:
host $ incus launch images:debian/12
Launching the instance
Instance name is: sunny-crappie
host $ incus ls
+-----------------+---------+------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-----------------+---------+------+-----------------------------------------------+-----------+-----------+
| sunny-crappie | RUNNING | | fd42:5d2e:9c0e:3868:216:3eff:fe5d:e2d7 (eth0) | CONTAINER | 0 |
+-----------------+---------+------+-----------------------------------------------+-----------+-----------+
The network seems to be ok:
host $ incus network show incusbr0
config:
ipv4.address: 10.239.48.1/24
ipv4.nat: "true"
ipv6.address: fd42:5d2e:9c0e:3868::1/64
ipv6.nat: "true"
description: ""
name: incusbr0
type: bridge
used_by:
- /1.0/instances/sunny-crappie
- /1.0/profiles/default
managed: true
status: Created
locations:
- none
host $ incus profile show default
config: {}
description: Default Incus profile
devices:
eth0:
name: eth0
network: incusbr0
type: nic
root:
path: /
pool: lvm_pool
type: disk
name: default
used_by:
- /1.0/instances/sunny-crappie
At least it is similar to how the old lxd configuration looked like.
The system logs in the guest don’t show anything strange:
sunny-crappie $ journalctl | grep eth0
Apr 18 14:36:32 sunny-crappie systemd-networkd[144]: eth0: Link UP
Apr 18 14:36:32 sunny-crappie systemd-networkd[144]: eth0: Gained carrier
Apr 18 14:36:32 sunny-crappie systemd-networkd[144]: eth0: Gained IPv6LL
Apr 18 14:36:32 sunny-crappie systemd-networkd[144]: eth0: Configuring with /etc/systemd/network/eth0.network.
And in the host the network device is there:
27: veth94968c1b@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master incusbr0 state UP group default qlen 1000
link/ether ae:f5:63:d4:b9:e7 brd ff:ff:ff:ff:ff:ff link-netnsid 3
These are the logs in the host at the time of creating the container:
host $ journalctl --follow
Apr 18 16:36:29 hostname dnsmasq[29581]: read /etc/hosts - 8 names
Apr 18 16:36:29 hostname dnsmasq-dhcp[29581]: read /var/lib/incus/networks/incusbr0/dnsmasq.hosts/sunny-crappie.eth0
Apr 18 16:36:30 hostname kernel: EXT4-fs (dm-10): mounted filesystem 6f5c0124-2708-4d1e-ba26-7a7ba97663ae r/w with ordered data mode. Quota mode: none.
Apr 18 16:36:30 hostname kernel: EXT4-fs (dm-10): unmounting filesystem 6f5c0124-2708-4d1e-ba26-7a7ba97663ae.
Apr 18 16:36:30 hostname systemd[1]: var-lib-incus-storage\x2dpools-lvm_pool-containers-sunny\x2dcrappie.mount: Deactivated successfully.
Apr 18 16:36:30 hostname systemd-homed[1285]: block device /sys/devices/virtual/block/dm-10 has been removed.
Apr 18 16:36:30 hostname systemd-homed[1285]: block device /sys/devices/virtual/block/dm-10 has been removed.
Apr 18 16:36:30 hostname kernel: EXT4-fs (dm-10): mounted filesystem 6f5c0124-2708-4d1e-ba26-7a7ba97663ae r/w with ordered data mode. Quota mode: none.
Apr 18 16:36:30 hostname systemd[1]: var-lib-incus-storage\x2dpools-lvm_pool-containers-sunny\x2dcrappie.mount: Deactivated successfully.
Apr 18 16:36:30 hostname kernel: EXT4-fs (dm-10): unmounting filesystem 6f5c0124-2708-4d1e-ba26-7a7ba97663ae.
Apr 18 16:36:30 hostname systemd-homed[1285]: block device /sys/devices/virtual/block/dm-10 has been removed.
Apr 18 16:36:30 hostname systemd-homed[1285]: block device /sys/devices/virtual/block/dm-10 has been removed.
Apr 18 16:36:30 hostname kernel: EXT4-fs (dm-10): mounted filesystem 6f5c0124-2708-4d1e-ba26-7a7ba97663ae r/w with ordered data mode. Quota mode: none.
Apr 18 16:36:30 hostname NetworkManager[1416]: <info> [1713450990.7715] manager: (vethd7bacb01): new Veth device (/org/freedesktop/NetworkManager/Devices/35)
Apr 18 16:36:30 hostname NetworkManager[1416]: <info> [1713450990.7748] manager: (veth94968c1b): new Veth device (/org/freedesktop/NetworkManager/Devices/36)
Apr 18 16:36:30 hostname kernel: incusbr0: port 3(veth94968c1b) entered blocking state
Apr 18 16:36:30 hostname kernel: incusbr0: port 3(veth94968c1b) entered disabled state
Apr 18 16:36:30 hostname kernel: veth94968c1b: entered allmulticast mode
Apr 18 16:36:30 hostname kernel: veth94968c1b: entered promiscuous mode
Apr 18 16:36:30 hostname audit: ANOM_PROMISCUOUS dev=veth94968c1b prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
Apr 18 16:36:30 hostname audit: BPF prog-id=299 op=LOAD
Apr 18 16:36:30 hostname audit: BPF prog-id=299 op=UNLOAD
Apr 18 16:36:30 hostname newuidmap[39408]: shadow: unknown configuration item 'PASS_MIN_LEN' in '/etc/login.defs'
Apr 18 16:36:30 hostname newuidmap[39408]: shadow: unknown configuration item 'PASS_CHANGE_TRIES' in '/etc/login.defs'
Apr 18 16:36:30 hostname newuidmap[39408]: shadow: unknown configuration item 'PASS_ALWAYS_WARN' in '/etc/login.defs'
Apr 18 16:36:30 hostname newuidmap[39408]: shadow: unknown configuration item 'HMAC_CRYPTO_ALGO' in '/etc/login.defs'
Apr 18 16:36:30 hostname newgidmap[39409]: shadow: unknown configuration item 'PASS_MIN_LEN' in '/etc/login.defs'
Apr 18 16:36:30 hostname newgidmap[39409]: shadow: unknown configuration item 'PASS_CHANGE_TRIES' in '/etc/login.defs'
Apr 18 16:36:30 hostname newgidmap[39409]: shadow: unknown configuration item 'PASS_ALWAYS_WARN' in '/etc/login.defs'
Apr 18 16:36:30 hostname newgidmap[39409]: shadow: unknown configuration item 'HMAC_CRYPTO_ALGO' in '/etc/login.defs'
Apr 18 16:36:30 hostname kernel: physZv7roV: renamed from vethd7bacb01
Apr 18 16:36:30 hostname kernel: eth0: renamed from physZv7roV
Apr 18 16:36:30 hostname kernel: incusbr0: port 3(veth94968c1b) entered blocking state
Apr 18 16:36:30 hostname kernel: incusbr0: port 3(veth94968c1b) entered forwarding state
Apr 18 16:36:30 hostname NetworkManager[1416]: <info> [1713450990.9271] device (veth94968c1b): carrier: link connected
I see that dnsmasq indeed does not create a lease:
host $ cat /var/lib/incus/networks/incusbr0/dnsmasq.leases
duid 00:01:00:01:2d:b3:0f:ca:c8:f7:50:12:6b:b8
The way dnsmasq is called by systemd unit incus.service seems quite similar to the one launched by lxd:
host $ systemctl status incus
...
└─29581 dnsmasq --keep-in-foreground --strict-order --bind-interfaces --except-interface=lo --pid-file= --no-ping --interface=incusbr0 --dhcp-rapid-commit --no-negcache --quiet-dhcp --quiet-dhcp6 --quiet-ra --listen-address=10.239.48.1 --dhcp-no-override --dhcp-authoritative --dhcp-leasefile=/var/lib/incus/networks/incusbr0/dnsmasq.leases --dhcp-hostsfile=/var/lib/incus/networks/incusbr0/dnsmasq.hosts --dhcp-range 10.239.48.2,10.239.48.254,1h --listen-address=fd42:5d2e:9c0e:3868::1 --enable-ra --dhcp-range ::,constructor:incusbr0,ra-stateless,ra-names -s incus --interface-name _gateway.incus,incusbr0 -S /incus/ --conf-file=/var/lib/incus/networks/incusbr0/dnsmasq.raw -u nobody -g incus
Any clue on what might be wrong?
Thank you!