[SOLVED] LXC Debian 13 With Nesting Disabled - No Console

L

lukeh990

New Member
Oct 8, 2024
1
0
1
I am trying to run a Debian 13 LXC container with nesting disabled. Trying to use the console feature just results in a black screen. Using pct enter 2000 works fine.

2000.conf - LXC Config
Code: 
arch: amd64
cmode: console
cores: 1
hostname: test-2000
memory: 512
nameserver: 10.3.3.253 10.3.3.254
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:A0:68:16,ip=dhcp,type=veth
ostype: debian
rootfs: vm_storage:vm-2000-disk-0,size=8G
swap: 512
unprivileged: 1

I tried switching the console mode to /dev/console and I got the systemd entries but I got these concerning errors:
Code: 
...
container-getty@2.service: Failed to set up credentials: Protocol error
container-getty@2.service: Failed at step CREDENTIALS spawning /sbin/agetty: Protocol error
console-getty.service: Failed to set up credentials: Protocol error
console-getty.service: Failed at step CREDENTIALS spawning /sbin/agetty: Protocol error
console-getty.service: Deactivated successfully.
container-getty@2.service: Deactivated successfully.
container-getty@2.service: Scheduled restart job, restart counter is at 5.
container-getty@1.service: Start request repeated too quickly.
container-getty@1.service: Failed with result 'start-limit-hit'.
container-getty@2.service: Start request repeated too quickly.
container-getty@2.service: Failed with result 'start-limit-hit'.
console-getty.service: Scheduled restart job, restart counter is at 2.
console-getty.service: Failed to set up credentials: Protocol error
console-getty.service: Failed at step CREDENTIALS spawning /sbin/agetty: Protocol error
console-getty.service: Deactivated successfully.
console-getty.service: Scheduled restart job, restart counter is at 3.
console-getty.service: Failed to set up credentials: Protocol error
console-getty.service: Failed at step CREDENTIALS spawning /sbin/agetty: Protocol error
console-getty.service: Deactivated successfully.
console-getty.service: Scheduled restart job, restart counter is at 4.
console-getty.service: Failed to set up credentials: Protocol error
console-getty.service: Failed at step CREDENTIALS spawning /sbin/agetty: Protocol error
console-getty.service: Deactivated successfully.
console-getty.service: Scheduled restart job, restart counter is at 5.
console-getty.service: Start request repeated too quickly.
console-getty.service: Failed with result 'start-limit-hit'.

I feel this is directly related to the nesting feature as I can use the console just fine when nesting is disabled.

The reason I don't want nesting enabled is because I plan on putting a small daemon on here that doesn't need to nest other container runtime and I want to reduce possible attack surfaces.

I should also say that use of the console function isn't going to be necessary for my workload because the plan is to make a dedicated LXC template with DAB. And, all the settings configurable outside of the terminal. But I just think it is weird that the nesting flag completely breaks such a prominent portion of the PVE Web UI without a warning.
 
Hi,
Debian (like most distros nowadays) uses a modern systemd version that needs nesting. But feel free to open an enhancement request for showing a hint about this in the UI: https://bugzilla.proxmox.com/
 
I've created a privileged LXC container with the Debian 13.1-2 template. It has the same issue, the console remains blank and no login prompt appears.

Since it's privileged, the nesting option is greyed out.

I tried creating a Debian 12 template container, which worked as expected, and upgraded it to 13. After rebooting the template, the same blank console with no login.

Any thoughts?
 
I can verify this. The privileged LXC 13.3 template creates a blank console with no login prompt. However, an unprivileged container with nesting works as expected. I thought I was doing something wrong until I read the earlier comments. It would appear that the privileged template requires a fix.
 
I know it is off-topic, but as developer and software architect I like to know more about this. Google unfortunately did not help and the AI just repeats variants of "systemd breaks everything, because it is so modern".

Does anyone has some pointer telling WHY systemd now even needs such special functionality like cgroup2 for such basic functionality as launching a login getty? And does not even provide a fallback?

(rant follows please ignore on any risk of being triggered)
systemd is known to be a de-facto monolith on a system (it is very hard to replace a part of it, such as use systemd, but not its freedesktop DBUS stuff on servers and so on), and now I see systemd dependencies even spread outside the systems to the hosts. There were three major breaks for containers I had in the last 10 years and EACH was related to systemd. Containers were lightweight and portable before systemd, but now many ready-to-use and turnkey-ready containers (such as turnkey linux) ship with systemd.

If any turnkey linux maintainer by accident reads this: please limit dependencies! To start a binary, no host-system infecting monolithic ecosystem is needed, so please try to avoid this spreading cancer and keep it as KISS (Keep it Simple, Stupid) as possible.
 
Last edited:
Hi @sdettmer,
systemd versions >= 242 requires nesting to be able to create Linux namespaces, which is used to isolate services. There are still distros that do not use systemd that you could use for your containers.
 
  • Like
Reactions: sdettmer
Hi,
thank you for your quick reply!

fiona said:
Hi @sdettmer,
systemd versions >= 242 requires nesting to be able to create Linux namespaces, which is used to isolate services.
Click to expand...
Thank you for the information. I googled further unfortunately the question why *require* it remains open.
Maybe baking in this and every feature in a monolith (instead of providing specialized building blocks which can be combined as needed) might desirable for someone, but *requiring* it seems bad.

fiona said:
There are still distros that do not use systemd that you could use for your containers.
Click to expand...
Yes, true that (even if apprently not turnkey-linux).
However we start seeing more and more applications and services that depend on systemd, with all the downsides this has.
For example that upgrading turnkey linux containers may cause boot failures and so on. Complexity is an enemy of stability. systemd is very successful to find complex partial solutions for simple problems, and we can enjoy them changing frequently. Unfortunately, the big players (IBM/redhat...) push that to everywhere (of course locking-in customers is good for the business), so we all lose our freedom - which interestingly most seem not to even notice.

Anyway, this is clearly out of scope here, Promox can only add the nesting for priv mode in GUI and/or enable it by default, as in practice probably most will need it
(again a detail, where unrelated software needs to align to systemd). Anyway.

Thank you for your support!
 
sdettmer said:
I googled further unfortunately the question why *require* it remains open.
Click to expand...

From what I remember, systemd uses cgroup v2 to manage and isolate processes and their resources. This fundamentally requires read/write access to /sys and /proc because the Linux kernel intentionally uses a single hierarchy for this API [1]. The "nesting" feature provides this access, because container runtimes do exactly the same thing.

I think the "specialized building block" that you want is another init system that provides fewer features.

[1] https://docs.kernel.org/admin-guide/cgroup-v2.html
 
  • Like
Reactions: fiona
Robert Obkircher said:
From what I remember, systemd uses cgroup v2 to manage and isolate processes and their resources. This fundamentally requires read/write access to /sys and /proc because the Linux kernel intentionally uses a single hierarchy for this API [1]. The "nesting" feature provides this access, because container runtimes do exactly the same thing.

I think the "specialized building block" that you want is another init system that provides fewer features.

[1] https://docs.kernel.org/admin-guide/cgroup-v2.html
Click to expand...
Thank you for your input. Yes, I think this "fewer features" hits the nail.

systemd forcibly isolates processes and requires the resources, even if running in a specialized container that is offering a single service with no need to isolate from itself, but there is no way to opt-out to unwanted features, ending up with needing less safe environments (instead of of letting the whole container isolate and refuse it from accessing the unneeded APIs, systemd enfores to do so).

So maybe we will see container image vendors to migrate away from systemd, but since systemd is widespread in the system (init, resolv, socket activation, logging...) it might be difficult to replace in "real world" containers.

I'm not sure how big the risk of nesting support actually is (a team mate said it could ease to break out of the container, and monitoring solutions may calculate container resource usage wrongly, which probably was the main issue here). As a workaround, a container can be started in an own VM mitigating these risks, for quite some resource usage penalty.
 
You must log in or register to reply here.
Top Bottom
Back