[SOLVED] No Console with Proxmox 5.0 beta 2 and Debian 9 containers.

[sezycei]

I checked around the forums and couldn't find an open thread on this.

I've tested this on two separate clean installations of Proxmox 5.0beta2 on two separate machines.

If I used the GUI-downloadable Debian Stretch container template and create a new CT with pretty basic configurations, I get a black console and am unable to connect to the container via SSH. If I use any other container template with the same basic configuration, everything works fine.

Just wanted to bring this to your attention so you could test it in case it's not just me!

Thanks for the wonderful software that is Proxmox.

 

[manu]

Can you check if from your host the command

pct console <my_container_id>

brings you a login prompt ?

 

[manu]

is that an unprivileged container ?

 

[sezycei]

pct console <id> does not bring up a prompt.

I have tested it with both unprivileged and privileged containers.

 

[phol16]

I also encountered this. Is your networking device configured properly? Otherwise the container will hang at boot and not bring up a prompt.

 

[sezycei]

I also encountered this. Is your networking device configured properly? Otherwise the container will hang at boot and not bring up a prompt.

Yes, the network device is properly configured. Like I said, I have no issue with any other container template, including Debian 8.

EDIT: I even upgraded a Debian 8 container to Debian 9 Stretch and it works fine. It's just the downloadable Debian 9 Container Template as far as I can tell that is the problem.

 

[manu]

The Debian9 templace is working fine for me.
Can you post here your container configuration ?

You can also enter the container namespace, bypassing the login/console with pct enter <CTID>
Then you should check that you have at least one agetty process. This process provides you with a login prompt.

 

[gaz]

I had a problem similar to this. Try either of the following:
1. Wait 5-10 minutes after starting the container, and see if you get a login.
2. Give the container a static IP rather than DHCP.

There's some weirdness with certain DHCP servers that I cannot pin down - I just gave up and assigned static.

 

[sezycei]

I had a problem similar to this. Try either of the following:
1. Wait 5-10 minutes after starting the container, and see if you get a login.
2. Give the container a static IP rather than DHCP.

There's some weirdness with certain DHCP servers that I cannot pin down - I just gave up and assigned static.

I always assign static IPv4 - are you saying I need to assign a static IPv6 address as well?

 

[gaz]

I always assign static IPv4 - are you saying I need to assign a static IPv6 address as well?

No, the IPV6 didn't seem to matter for me - only IPV4. Apparently, your problem is different from mine. Please disregard.

 

[sezycei]

The Debian9 templace is working fine for me.
Can you post here your container configuration ?

You can also enter the container namespace, bypassing the login/console with pct enter <CTID>
Then you should check that you have at least one agetty process. This process provides you with a login prompt.

I entered the container via {pct enter <id>} and there is no getty process. I just tried the same with the Debian 8 container template and it was there perfectly fine. I followed the exact same steps and configuration options in the GUI setup for the containers to create them.

 

[sezycei]

No, the IPV6 didn't seem to matter for me - only IPV4. Apparently, your problem is different from mine. Please disregard.

Thanks for trying to help!

 

[sezycei]

I had a problem similar to this. Try either of the following:
1. Wait 5-10 minutes after starting the container, and see if you get a login.
2. Give the container a static IP rather than DHCP.

There's some weirdness with certain DHCP servers that I cannot pin down - I just gave up and assigned static.

Okay, it appears that if I wait about 20 minutes after starting the container, then I get the login prompt. On other container templates it's about 10 seconds.

Anyone know what may cause this?

 

[gaz]

Okay, it appears that if I wait about 20 minutes after starting the container, then I get the login prompt. On other container templates it's about 10 seconds.

That outsized delay is very similar to my problem. I was never able to truly diagnose the problem. Logging within the container seemed minimal and unhelpful.
Perhaps you can use 'ps' on the host to get a list of running processes on the container - perhaps that will give an idea.
something like:

 ps -o pid,cmd,wchan

That'll at least show where the processes are sleeping. But not sure that it's enough info to really debug.
Can you ping the container when it's started but hanging?

 

[manu]

the problem is that the getty service which display the login prompt, needs the network configuration to be applied before running.
you can check that by entering the started container with

pct enter <CTID>
systemctl list-jobs

you will see
47 networking.service start running

meaning that the service start has not completed yet

so maybe you have you have a broken network configuration ?

(NB: the behaviour of waiting for the network to display a login prompt is the same on all debian 9 systems, container or not)

normally in case of a broken network configuration, you should wait at max 5 minutes, like @gaz said

this behaviour is defined in the networking.service
systemctl show networking.service | grep -i timeoutstart
TimeoutStartUSec=5min

 

[manu]

also if you want to debug what is wrong at startup you can use

# systemd-analyze blame
      5min 154ms networking.service
           177ms postfix@-.service
             8ms systemd-logind.service
             7ms dev-hugepages.mount
             7ms systemd-remount-fs.service
             6ms ssh.service
             6ms systemd-sysctl.service
             5ms systemd-journald.service
             5ms rsyslog.service
             5ms systemd-user-sessions.service
             4ms systemd-tmpfiles-setup.service
             4ms systemd-journal-flush.service
             4ms dev-mqueue.mount
             3ms systemd-update-utmp.service
             3ms systemd-update-utmp-runlevel.service
             1ms postfix.service

 

[sezycei]

also if you want to debug what is wrong at startup you can use

# systemd-analyze blame
      5min 154ms networking.service
           177ms postfix@-.service
             8ms systemd-logind.service
             7ms dev-hugepages.mount
             7ms systemd-remount-fs.service
             6ms ssh.service
             6ms systemd-sysctl.service
             5ms systemd-journald.service
             5ms rsyslog.service
             5ms systemd-user-sessions.service
             4ms systemd-tmpfiles-setup.service
             4ms systemd-journal-flush.service
             4ms dev-mqueue.mount
             3ms systemd-update-utmp.service
             3ms systemd-update-utmp-runlevel.service
             1ms postfix.service

Thank you! I'll debug it later tonight, clearly I'm doing something wrong. I appreciate your time very much!

 

[sezycei]

also if you want to debug what is wrong at startup you can use

# systemd-analyze blame
      5min 154ms networking.service
           177ms postfix@-.service
             8ms systemd-logind.service
             7ms dev-hugepages.mount
             7ms systemd-remount-fs.service
             6ms ssh.service
             6ms systemd-sysctl.service
             5ms systemd-journald.service
             5ms rsyslog.service
             5ms systemd-user-sessions.service
             4ms systemd-tmpfiles-setup.service
             4ms systemd-journal-flush.service
             4ms dev-mqueue.mount
             3ms systemd-update-utmp.service
             3ms systemd-update-utmp-runlevel.service
             1ms postfix.service

My systemd-analyze blame definitely showed that the networking.service was timing out. My networking settings are as attached. The container gets both a valid IPv4 and IPv6 address.

Is there a way to view more specific information as to what is causing the 5 minute delay on networking.service?

 

[manu]

I see you have dhcp6 activated

most probably you don't have a DHCPv6 server in your network, but your container is probably waiting for one to answer

 

[sg23]

This thread is a bit old but it is the top google hit for "proxmox debian container no console".

I am just getting started with Proxmox and had this exact problem and it was in fact the IPV6 setting. Set to DHCP, networking service start times out after 5 minutes. Change network config to have IPV6 "static" and "none" and the console prompt comes up immediately.