Incus containers with idmapping broken with kernel 6.9

[bljohnsondev]

The latest update to Bluefin upgraded the kernel from 6.8 to 6.9. Incus has an issue with using idmapping shift=true with the 6.9 kernel. This was fixed with Incus 6.2 but Bluefin is still shipping 6.1. Here is a link to the Incus issue for more information:

Linux 6.9+ idmapping abilities are required but aren't supported on system

Prior to Incus 6.2 any containers running with shift=true idmapping throw an error and will not start.

[m2Giles]

Incus 6.2 is now in the COPR and is being used on the most recent builds.

https://github.com/ublue-os/bluefin/actions/runs/9568962423/job/26380372476#step:11:7290

[m2Giles]

Additionally, we have a distrobox with incus in it at ublue-os/toolboxes as another option. That pulls packages directly from zabbly.

[bljohnsondev]

Incus 6.2 is now in the COPR and is being used on the most recent builds.

https://github.com/ublue-os/bluefin/actions/runs/9568962423/job/26380372476#step:11:7290

Awesome. I'll hold off on updates for now until it's ready (hopefully in a near future release).

Additionally, we have a distrobox with incus in it at ublue-os/toolboxes as another option. That pulls packages directly from zabbly.

Really? That sounds like a great option. I checked the repo and I'm only seeing ubuntu, fedora, wolfi, bluefin-cli and powershell.

[m2Giles]

It's under apps

I volume mount /var/lib/incus and make sure the guid for incus admin matches both inside the container and on the host.

The actual incus distrobox
ghcr.io/ublue-os/incus-distrobox

[bljohnsondev]

It's under apps

I volume mount /var/lib/incus and make sure the guid for incus admin matches both inside the container and on the host.

The actual incus distrobox ghcr.io/ublue-os/incus-distrobox

Does the incus container need to be run with systemd using --root --additional-packages "systemd" --init --unshare-all?

Without it the incus command in the container errors out saying the daemon isn't started. If I try it with systemd it's a new incus install (wants me to run the incus admin init).

Thanks for your assistance.

[m2Giles]

It needs the flags --root and --init at a bare minimum. The assemble file I use with it:

[incus]
image=ghcr.io/ublue-os/incus-distrobox:latest
init=true
nvidia=true
root=true
entry=false
volume="/var/lib/incus:/var/lib/incus /lib/modules:/lib/modules:ro"
init_hooks="usermod -aG incus-admin ${USER}"

[bljohnsondev]

I guess we may be getting a bit outside the scope of the initial issue but another quick question related to running Incus in a distrobox container like this.

I did get it to sort of work but there were some issues with existing Incus networks becoming unavailable, etc. My containers are showing up as expected but won't start because the network attached to them is showing as unavailable. I can't seem to remove the existing bridge network even after detaching it from all the containers.

Will there be conflicting issues with also running Incus on the host as well? I'd imagine that can't be a good thing. Perhaps that's the issue I'm having with the networks, etc.

Should I uninstall Incus on the host and if so is there a recommended way of doing this when Incus has been installed via ujust install-incus? I've backed up my containers in the event I break something or have to wipe Incus and start fresh.

Thanks again! That assemble file was extra helpful.

[m2Giles]

I would make sure that the host incus is simply not running at the same time. Everything should be store inside of /var/lib/incus including the dnsmasq configurations. So simply disable incus.socket and incus.service on the host.

I personally have stopped using the version on the host and manage everything with the distrobox instance. I still use incus from the host, but only using the client binary.

Again make sure that the host and guest have the same GID for incus-admin and it will just work.

[bljohnsondev]

I would make sure that the host incus is simply not running at the same time. Everything should be store inside of /var/lib/incus including the dnsmasq configurations. So simply disable incus.socket and incus.service on the host.

I personally have stopped using the version on the host and manage everything with the distrobox instance. I still use incus from the host, but only using the client binary.

Again make sure that the host and guest have the same GID for incus-admin and it will just work.

I disabled Incus on the host and everything looks good. I did make sure to match the GID and I can also see and interact with the Incus containers from the host.

I also updated to the latest version of Bluefin running the 6.9.4-100 kernel and Incus 6.2 is working great.

Now if I could figure out how to have the incus distrobox container run at system startup/login it would be perfect. For now I can work with this and manually start it on login.

Thanks for your assistance!

[bljohnsondev]

I'll close this issue now since I think it's been answered.

• Incus 6.2 is in COPR so it should be included in a future update that will fix this issue.
• For those like me who couldn't wait until then there is a rather excellent solution for running Incus in distrobox that will use the latest version of Incus and works for the latest version of Bluefin.

Thanks again!

[m2Giles]

Here is how I autostart mine. Note, you may experience slowdowns on shutdown since incus by default has a 900 second timeout.

m2@m2home:~$ cat /etc/systemd/system/incus.service 
[Unit]
Description=Start incus distrobox
After=network-online.target
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true
Environment=HOME="/home/m2"
Environment=USER="m2"
ExecStart=/usr/bin/distrobox-enter incus
ExecStop=/usr/bin/podman stop -t 30 incus

[Install]
WantedBy=default.target