Incus service doesn't start after 6.19 update on Arch Linux (panic: runtime error)

Incus
1

Hello,

Apologies if I am missing something obvious, but I think the latest update to 6.19 broke something on Arch Linux. I can’t start the systemd incus.service anymore.

It looks similar to this report for Debian.

Here the output of # journalctl -b -u incus.service:

Dec 03 09:30:28 balzac systemd[1]: Starting Incus Container Hypervisor…
Dec 03 09:30:28 balzac incusd[5269]: time=“2025-12-03T09:30:28+01:00” level=warning msg=“AppArmor support has been disabled because of lack of kernel support”
Dec 03 09:30:28 balzac incusd[5269]: time=“2025-12-03T09:30:28+01:00” level=warning msg=" - AppArmor support has been disabled, Disabled because of lack of kernel support"
Dec 03 09:30:29 balzac dnsmasq[5357]: started, version 2.91 cachesize 150
Dec 03 09:30:29 balzac dnsmasq[5357]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC loop-detect inotify dumpfile
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: DHCP, IP range 10.212.77.2 – 10.212.77.254, lease time 1h
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: DHCPv6 stateless on incusbr0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: DHCPv4-derived IPv6 names on incusbr0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: router advertisement on incusbr0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: DHCPv6 stateless on fd42:92f7:fe8e:700b::, constructed for incusbr0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: DHCPv4-derived IPv6 names on fd42:92f7:fe8e:700b::, constructed for incusbr0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: router advertisement on fd42:92f7:fe8e:700b::, constructed for incusbr0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: IPv6 router advertisement enabled
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: DHCP, sockets bound exclusively to interface incusbr0
Dec 03 09:30:29 balzac dnsmasq[5357]: using only locally-known addresses for incus
Dec 03 09:30:29 balzac dnsmasq[5357]: reading /etc/resolv.conf
Dec 03 09:30:29 balzac dnsmasq[5357]: using nameserver 127.0.0.53#53
Dec 03 09:30:29 balzac dnsmasq[5357]: using only locally-known addresses for incus
Dec 03 09:30:29 balzac dnsmasq[5357]: read /etc/hosts - 23 names
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: read /var/lib/incus/networks/incusbr0/dnsmasq.hosts/bob.eth0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: read /var/lib/incus/networks/incusbr0/dnsmasq.hosts/fen.eth0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: read /var/lib/incus/networks/incusbr0/dnsmasq.hosts/gemini.eth0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: read /var/lib/incus/networks/incusbr0/dnsmasq.hosts/lua55.eth0
Dec 03 09:30:29 balzac dnsmasq-dhcp[5357]: read /var/lib/incus/networks/incusbr0/dnsmasq.hosts/ubub.eth0
Dec 03 09:30:30 balzac incusd[5269]: panic: runtime error: invalid memory address or nil pointer dereference
Dec 03 09:30:30 balzac incusd[5269]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x55a413564d47]
Dec 03 09:30:30 balzac incusd[5269]: goroutine 538 [running]:
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/shared/archive.Unpack({0xc000962480, 0x5d}, {0xc00081e600, 0x73}, 0x0, 0xc1cec540, 0x0)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/shared/archive/archive.go:191 +0xe7
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/internal/server/storage.ImageUnpack({0xc0009623c0, 0x56}, {{0xc0012096c0, 0x40}, {0xc000ec1da0, 0x7}, 0xc0007233b0, {0x55a413e9e67f, 0x6}, {0x55a413eb2377, …}, …}, …)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/storage/utils.go:610 +0x565
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/internal/server/storage.(*backend).EnsureImage.(*backend).imageFiller.func6({{0xc0012096c0, 0x40}, {0xc000ec1da0, 0x7}, 0xc0007233b0, {0x55a413e9e67f, 0x6}, {0x55a413eb2377, 0xa}, 0xc000723380, …}, …)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/storage/backend.go:1724 +0x205
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/internal/server/storage/drivers.genericRunFiller({0x55a414911ea8, 0xc0005cf0e0}, {{0xc0012096c0, 0x40}, {0xc000ec1da0, 0x7}, 0xc0007233b0, {0x55a413e9e67f, 0x6}, {0x55a413eb2377, …}, …}, …)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/storage/drivers/generic_vfs.go:1213 +0x2d8
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/internal/server/storage/drivers.(*btrfs).CreateVolume(0xc0005cf0e0, {{0xc0012096c0, 0x40}, {0xc000ec1da0, 0x7}, 0xc0007233b0, {0x55a413e9e67f, 0x6}, {0x55a413eb2377, 0xa}, …}, …)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/storage/drivers/driver_btrfs_volumes.go:93 +0x54d
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/internal/server/storage.(*backend).EnsureImage(0xc000e3e780, {0xc0012096c0, 0x40}, 0x0)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/storage/backend.go:3621 +0x19ef
Dec 03 09:30:30 balzac incusd[5269]: main.imageCreateInPool(0x55a41462a620?, 0xc001076120, {0xc0010d01c0?, 0xc0009e4028?})
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/cmd/incusd/images.go:985 +0x55
Dec 03 09:30:30 balzac incusd[5269]: main.ImageDownload({0x55a4148e7050, 0xc0009a4410}, 0x0, 0xc000686700, 0x0, 0xc0000517e0)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/cmd/incusd/daemon_images.go:299 +0x175a
Dec 03 09:30:30 balzac incusd[5269]: main.autoUpdateImage({0x55a4148e7050, 0xc0009a4410}, 0xc000686700, 0x0, 0xd2, 0xc000038fc0, {0xc0007f03d3, 0x7}, 0x0?)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/cmd/incusd/images.go:2337 +0x98d
Dec 03 09:30:30 balzac incusd[5269]: main.autoUpdateImages({0x55a4148e7050, 0xc0009a4410}, 0xc000686700)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/cmd/incusd/images.go:1979 +0x8b4
Dec 03 09:30:30 balzac incusd[5269]: main.autoUpdateImagesTask.func1.1(0xc0005951a0?)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/cmd/incusd/images.go:1845 +0x1f
Dec 03 09:30:30 balzac incusd[5269]: github.com/lxc/incus/v6/internal/server/operations.(*Operation).Start.func1(0xc000beeb40)
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/operations/operations.go:306 +0x26
Dec 03 09:30:30 balzac incusd[5269]: created by github.com/lxc/incus/v6/internal/server/operations.(*Operation).Start in goroutine 128
Dec 03 09:30:30 balzac incusd[5269]: /build/incus/src/incus-6.19/internal/server/operations/operations.go:305 +0x106
Dec 03 09:30:30 balzac systemd[1]: incus.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

2

I just saw that there is a new version in testing: 6.19.1. The version crashing is 6.19.0. I understand the fix is in the last version. I am going to test it now.

3

I can’t reproduce. In my test machine, 6.19.0 is working. I will wait for 6.19.1 now as I can’t put testing on my main machine. I will update in due course.

4

It was the same issue I had on Debian 13 Trixie. Funny enough I read the issues with 6.19.0 and forgot that I didn’t update my host to 6.19.1 (that is done now). So, I would expect it’s the same case for you :blush:

Ref. my reported issue on Github 6.19 panic error related to image update · Issue #2725 · lxc/incus

5

Noted. Thanks!

6

Thank you for this post…

for what it is worth…I can confirm this issue is happening…both on 6.12.60-1-lts and the latest kernel…

I just rolled back incus sudo pacman -U /var/cache/pacman/pkg/incus-6.18.0-3-x86_64.pkg.tar.zst and things are working again.

What is really strange (I am sure I am missing something) is that when I looked at the installation date for incus 19.0.1 it said it was installed on Wednesday (today is Friday) and everything was working yesterday (after reboot)…I don’t get it…

7

Yes it’s weird. I cannot reproduce if I install a brand new (virtual) machine.

I ended up forcing the install of 6.19.1 which is still in testing and it’s working.

So testing passes AFAIC and the issue is fixed.

8

6.19.1 is now in main. This is fixed.

9

weird i did not face any errors on arch because i auto upgrade daily and i was running 6.19.0-1 on 5th dec and one day after upgraded to 6.19.1-1

10

The issue would only really hit if you had locally cached container images (squashfs) that were due for auto-update.

2 Likes