Issue with systemd-logind.service After Upgrading Incus Container from Debian 11 to Debian 12

Incus
1

During the upgrade of an unprivileged Incus container (with security.nesting = false) from Debian 11 to Debian 12, the systemd-logind.service encounters the following error:

Aug 14 17:12:41 ds-ca-it-lps-S01 systemd[1]: Starting systemd-logind.service - User Login Management...
Aug 14 17:12:41 lps-S01 (d-logind)[29155]: systemd-logind.service: Failed to set up mount namespacing: /run/systemd/unit-root/proc: Permission denied
Aug 14 17:12:41 lps-S01 (d-logind)[29155]: systemd-logind.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-logind: Permission denied
Aug 14 17:12:41 lps-S01 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=226/NAMESPACE

Additionally, on the host system, I observe the following error:

Aug 14 17:12:09 ds-ca-it-lxc-D04 kernel: audit: type=1400 audit(1723655529.497:103526): apparmor=“DENIED” operation=“mount” info=“failed flags match” error=-13 profile=“lps-S01_</var/lib/incus>” name=“/run/systemd/unit-root/proc/” pid=12583 comm=“(d-logind)” fstype=“proc” srcname=“proc” flags=“rw, nosuid, nodev, noexec”

Based on my research, it appears that AppArmor is preventing the systemd-logind service within the Incus container from accessing the /proc directory on the host.

Interestingly, if I create a completely new Incus container with Debian 12, I do not encounter this error. This new container is also unprivileged, with nesting disabled.

Does anyone have insight into how I might resolve this problem without setting security.nesting to true?

2

Hi!

I am getting this. Do you approach the upgrade in a different way?

$ incus launch images:debian/11 mycontainer
Launching mycontainer
$ incus exec mycontainer -- cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ incus stop mycontainer
$ incus rebuild images:debian/12 mycontainer
$ incus start mycontainer
$ incus exec mycontainer -- cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$
3

Yes, my approach was different:

incus exec ds-ca-it-lps-S01 bash
rpl "bullseye" "bookworm" /etc/apt/source.list
apt update && apt upgrade && apt dist-upgrade && apt autoremove
reboot

After reboot, systemd-logind service failed, and starts to have permission denied errors.
I did this process on at least 10 different containers that were debian-11, all hosted on different bare metal servers and all of them have this issue.

4

Try refreshing /etc/systemd/system-generators/lxc with what’s at distrobuilder/distrobuilder/lxc.generator at main · lxc/distrobuilder · GitHub

That should basically turn your current container into something that matches a new one.

5

@stgraber
Please can you explain how can I do that?
I have installed distorbuilder with snap, what’s the next step?

6

You don’t need distrobuilder.

Just edit the file in your container and replace its content with the one from Github, then reboot the container.

7

I suppose you would run

$ incus shell mycontainer
root@mycontainer:~# sudo apt install -y curl
root@mycontainer:~# cp /etc/systemd/system-generators/lxc /etc/systemd/system-generators/lxc.OLD
root@mycontainer:~# curl https://raw.githubusercontent.com/lxc/distrobuilder/main/distrobuilder/lxc.generator -o /etc/systemd/system-generators/lxc
root@mycontainer:~# logout 
$ incus restart mycontainer
1 Like
8

Thank you, that fixed it.

9

@stgraber Is it safe to use this distrobuilder script in a privileged container?
I have a case where I need to use privileged container, because I need to use block device from the host, but I can’t mount it on the container, if the container isn’t privileged.

10

Yeah, we use security.privileged=true for our own image builders because that’s still needed to do all the block stuff.

It’s not great but so long as you’re just running trusted software, in this case distrobuilder and you feed it similarly trusted data like packages coming from a distro, it’s fine.