blank/black/empty console issue since update

[Dunuin]

Did you enable nesting for those LXC? Systemd of newer LXCs like Debian 11 might require this. Starting with PVE7 all LXCs will be created with nesting enabled by default but with PVE6 the default was disabled nesting. So if you created those LXCs with PVE6 nesting is probably not enabled.

Also keep in mind that not all LXCs won't run with PVE7 anymore. Because PVE7 dropped cgroup support so its required that the LXC supports cgroup2. PVE6 suppoted cgroup and cgroup2.

 

[manilx]

Did you enable nesting for those LXC? Systemd of newer LXCs like Debian 11 might require this.

 

[manilx]

Yes, nesting is set.

 

[ahmedlm]

Any solutions to this? I found the same issue using debian LXC. Ubuntu is fine.

An easy solution is to change console mode from "tty" to "shell". Select the CT ===> go to: Options ===> Console mode ===> change it to "shell" and you'll see a working shell.

 

[manilx]

This worked! I didn't have to login though.....

 

[ln1401]

Thanks that helped me also today

 

[jvaughn]

I know this is oldish, but for anyone else who gets here by Googling the issue. With the debian-11-standard_11.3-1_amd64.tar.zst CT image, I had this same issue.
Changing the Console mode to /dev/console (I guess tty isn't available until login kicks off?) showed systemd waiting on "A start job is running for Raise network interfaces" for 5m1s before getting to the login.
Following the guidance here of avoiding DHCP on IPv6 and/or changing the timeout allowed for a timely start.

 

[ahmedlm]

I know this is oldish, but for anyone else who gets here by Googling the issue. With the debian-11-standard_11.3-1_amd64.tar.zst CT image, I had this same issue.
Changing the Console mode to /dev/console (I guess tty isn't available until login kicks off?) showed systemd waiting on "A start job is running for Raise network interfaces" for 5m1s before getting to the login.
Following the guidance here of avoiding DHCP on IPv6 and/or changing the timeout allowed for a timely start.

Thanks. I've just tested this and it seems to be the issue. I created a Debian 11 CT and set the IPv6 to 'static', started the container and got a login prompt almost immediately. Then I stopped the CT and changed the IPv6 to DHCP, started the CT and it hanged there for a few minutes before giving me a login prompt. Changed it back to static and it worked fine again.

 

[rickard2014]

I know this is oldish, but for anyone else who gets here by Googling the issue. With the debian-11-standard_11.3-1_amd64.tar.zst CT image, I had this same issue.
Changing the Console mode to /dev/console (I guess tty isn't available until login kicks off?) showed systemd waiting on "A start job is running for Raise network interfaces" for 5m1s before getting to the login.
Following the guidance here of avoiding DHCP on IPv6 and/or changing the timeout allowed for a timely start.

Thank you, this also solved the same issue I was experiencing.

 

[Tony C]

I had a very similar issue when upgrading from 6.4 through to 8.1. All of my containers didn't display anything on the console but booted up and I could ssh in. The above fix to switch the console mode to /dev/console worked as stated above (and many thanks for the posted solution ). However I wanted to know why existing containers had this issue and new ones created from the exact same template didn't.

Basically systemd wasn't starting any agetty processes for the default 2 ttys. For some reason the relevant directory and symlinks were missing in the container. To re-instate the setup as per a newly created container, as root I did:

cd /etc/systemd/system
mkdir getty.target.wants
cd getty.target.wants
ln -s /lib/systemd/system/serial-getty@.service serial-getty@.service
reboot

The containers in question were Ubuntu. Granted I may have done something weird with those containers by toggling settings on the PVE panel way back when, but they are currently using the default settings. Anyway just in case it helps others...

 

[Tony C]

I had a very similar issue when upgrading from 6.4 through to 8.1. All of my containers didn't display anything on the console but booted up and I could ssh in. The above fix to switch the console mode to /dev/console worked as stated above (and many thanks for the posted solution ). However I wanted to know why existing containers had this issue and new ones created from the exact same template didn't.

Basically systemd wasn't starting any agetty processes for the default 2 ttys. For some reason the relevant directory and symlinks were missing in the container. To re-instate the setup as per a newly created container, as root I did:

cd /etc/systemd/system
mkdir getty.target.wants
cd getty.target.wants
ln -s /lib/systemd/system/serial-getty@.service serial-getty@.service
reboot

The containers in question were Ubuntu. Granted I may have done something weird with those containers by toggling settings on the PVE panel way back when, but they are currently using the default settings. Anyway just in case it helps others...

It seems that just creating the getty.target.wants directory is enough.

 

[kkoenen]

Add this lxc.apparmor.profile: unconfined to your /etc/pve/lxc/108.conf

 

[Matth3w]

I know this is oldish, but for anyone else who gets here by Googling the issue. With the debian-11-standard_11.3-1_amd64.tar.zst CT image, I had this same issue.
Changing the Console mode to /dev/console (I guess tty isn't available until login kicks off?) showed systemd waiting on "A start job is running for Raise network interfaces" for 5m1s before getting to the login.
Following the guidance here of avoiding DHCP on IPv6 and/or changing the timeout allowed for a timely start.

This worked for me. I was having this issue after upgrading from ubuntu server 22.04.1 LTS to ubuntu server 24.04.1 LTS.