Has anyone been able to get Incus working under Ubuntu 25.04? A completely fresh install, everything defaults, launch a container with incus launch images:ubuntu/noble test (or any other image), then shell into it with incus shell test and do apt update in it and…it just stops doing anything. It looks like an Apparmor issue, but I have no idea what the specific issue is or how to fix.
I guess no one cares or I’m the only one who has tried it, but there’s something going on with AppArmor in 25.04. Adding raw.apparmor="signal," to a container’s config allows it to work again. A related issue is the absolute massive amount of spam about ptrace being denied in syslogs and that could be mitigated as well by adding it to the abovementioned raw.apparmor.
Just mentioning here for posterity’s sakes. I suppose I’ll have to open an issue ticket later on Incus’s Github unless someone else does it before me.
Hi!
This requires some investigation and steps to reproduce the issue.
Do you get the same result if you install Incus in an Ubuntu 25.04 VM? Then, install Incus in the VM.
incus launch --vm images:ubuntu/plucky testing-if-incus-works
I did try Ubuntu 25.04 in a VMware VM, but it did the same thing there as well, if that answers your question.
I was thinking more about creating that Ubuntu 25.04 VM using Incus, and in there installing Incus to test whether the new Incus installation is usable.
So I went through the steps to try to replicate what you are getting.
This is what I have been expecting.
$ incus launch --vm images:ubuntu/plucky testing-if-incus-works
Launching testing-if-incus-works
$ incus shell testing-if-incus-works
root@testing-if-incus-works:~# apt update
...
root@testing-if-incus-works:~# apt policy incus
incus:
Installed: (none)
Candidate: 6.0.3-4
Version table:
6.0.3-4 500
500 http://archive.ubuntu.com/ubuntu plucky/universe amd64 Packages
root@testing-if-incus-works:~# apt install incus
...
root@testing-if-incus-works:~# incus admin init
Would you like to use clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]:
Name of the new storage pool [default=default]:
Where should this storage pool store its data? [default=/var/lib/incus/storage-pools/default]:
Would you like to create a new local network bridge? (yes/no) [default=yes]:
What should the new bridge be called? [default=incusbr0]:
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
Would you like the server to be available over the network? (yes/no) [default=no]:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]:
Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]:
root@testing-if-incus-works:~# incus launch images:ubuntu/noble noble
Launching noble
root@testing-if-incus-works:~# incus shell noble
root@noble:~# ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=2.02 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=2.02 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=2.18 ms
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 302ms
rtt min/avg/max/mdev = 2.018/2.072/2.175/0.042 ms
root@noble:~# apt update
#### is stuck - indeed something is wrong here ###
Indeed, a system container created in an Ubuntu 25.04 VM does have Internet connectivity (ICMP / ping works), but a quick apt update is stuck.
But is that an Incus issue or is it a distro issue? Can we perform a TCP connection to the Internet from this container?
root@noble:~# telnet www.google.com 80
-bash: telnet: command not found
root@noble:~# nc www.google.com 80
HEAD / HTTP/1.0 # you type this and press Enter twice
HTTP/1.0 200 OK
Content-Type: text/html; charset=ISO-8859-1
...
^C
root@noble:~#
A TCP connection works, therefore something is wrong with the distro or with the apt command.
This does not yet look like an Incus problem.
Here is the snippet from kernel.log in the Ubuntu 25.04 VM, when we run apt update in a container.
2025-04-26T10:06:40.559507+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.556:604): apparmor="DENIED" operation="signal" class="signal" profile="incus-noble_</var/lib/incus>" pid=6047 comm="apt" requested_mask="send" denied_mask="send" signal=int peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.564510+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.562:605): apparmor="DENIED" operation="ptrace" class="ptrace" profile="incus-noble_</var/lib/incus>" pid=6053 comm="systemctl" requested_mask="read" denied_mask="read" peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.576500+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.574:606): apparmor="DENIED" operation="ptrace" class="ptrace" profile="incus-noble_</var/lib/incus>" pid=5056 comm="systemd" requested_mask="read" denied_mask="read" peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.576509+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.574:607): apparmor="DENIED" operation="ptrace" class="ptrace" profile="incus-noble_</var/lib/incus>" pid=5103 comm="systemd-journal" requested_mask="read" denied_mask="read" peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.577490+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.575:608): apparmor="DENIED" operation="ptrace" class="ptrace" profile="incus-noble_</var/lib/incus>" pid=5103 comm="systemd-journal" requested_mask="read" denied_mask="read" peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.584543+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.582:609): apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 namespace="root//incus-noble_<var-lib-incus>" profile="unconfined" name="ubuntu_pro_apt_news" pid=6055 comm="(python3)"
2025-04-26T10:06:40.585538+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.583:610): apparmor="DENIED" operation="ptrace" class="ptrace" profile="incus-noble_</var/lib/incus>" pid=5056 comm="systemd" requested_mask="read" denied_mask="read" peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.585544+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.583:611): apparmor="DENIED" operation="signal" class="signal" profile="incus-noble_</var/lib/incus>" pid=6053 comm="systemctl" requested_mask="send" denied_mask="send" signal=term peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:40.600499+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.598:612): apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 namespace="root//incus-noble_<var-lib-incus>" profile="unconfined" name="ubuntu_pro_esm_cache" pid=6056 comm="(python3)"
2025-04-26T10:06:40.751507+00:00 testing-if-incus-works kernel: audit: type=1400 audit(1745662000.749:613): apparmor="DENIED" operation="signal" class="signal" profile="incus-noble_</var/lib/incus>" pid=6055 comm="python3" requested_mask="send" denied_mask="send" signal=int peer="incus-noble_</var/lib/incus>//&unconfined"
2025-04-26T10:06:45.766516+00:00 testing-if-incus-works kernel: kauditd_printk_skb: 6 callbacks suppressed
Therefore, we have a reproducible list of commands that demonstrates a problem.
The specifics:
- The host is Ubuntu 25.04. Have not tested with surrounding versions.
- The host was in a VM (Incus/QEMU).
- Incus was installed from the
universerepository, and have not tried from Zabbly. - AppArmor errors appear to disallow certain commands to run in a container created on that host. Example with
apt update. Network connectivity is present and working.
Well, apologies. It looked like an issue with Incus to me, but I figured I’d ask first if others are seeing the same and what they think about it. At least you’ve now confirmed that it’s not just me, so that’s still something.
Here is an example that affected AppImages (some similarity to containers) but was fixed, Bug #2098993 “Last updates to apparmor broke all AppImages, whic...” : Bugs : apparmor package : Ubuntu
Apparently there have been changes to the AppArmor configuration that break things here and there and require the appropriate reporting. I do not know what exactly needs to be done.
Well, I have now filed a bug report at Bug #2109394 “AppArmor breaks Incus containers” : Bugs : apparmor package : Ubuntu
1 Like
Well. Good to know I’m not the only one seeing this!
Still the same problem. This is on a baremetal 25.04 install with Incus from the Zabbly repo.
As of 27/04 the bug was confirmed and the only suggestion so far is :
This looks to be caused by incus using change_profile to change confinement. AppArmor is allowing this but only to a point creating a stack of the incus policy and unconfined. We will need to investigate the specifics of exactly what is going on here. But in the mean time you should be able to work around this by disabling the apparmor_unconfined_restriction. Using
sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=0
More problems in 25.04 - I also can’t get a host directory mounted into a new LXC instance, although it works with existing ones.
With the new container I now get
Error: Failed to start device "storage": Required idmapping abilities not available
… when the underlying storage is MergerFS.
Edit : to correct what I said above, I can mount the host directory into the instance, it just won’t allow shift=true.
Another edit : this looks to be AppArmor again, in this case it is preventing onexec.