Chux Uzoeto's picture

I have been running proxmox ve with KVM for a while now.  Decided recently to give TKL a go within proxmox, and it has been a bad experience so far.

The containers install OK (but show errors where one would expect the initialization scripts would have been run) .. after proxmox CT install, system boots into a console CLI prompt, where I am able to login.

All attempts (via proxmox 'vzctl enter'  OR via the web console OR via an ssh session direct on the appliance) to initialize the container fails with similar error messages as below ..

  • Proxmox VE 3.1-45
  • I have tried the following appliances:  jenkins, sugarcrm, zurmo, vtiger, canvas (all version 13.1, x64 .. except vtiger which is 12.1)
  • As can be seen below, it complains about the nat module of iptables
  • Errors seem to suggest python-tk is missing (and indeed dpkg shows its not installed)
  • I installed (via apt-get) python-tk and apt-utils, but I am still unable to run a successful turnkey-init
  • Anyone able to point me to how I can attempt to resolve this problem?
  • Is there a way to get the appliances configured without using  turnkey-init?

The error messages is attached as a text file, because your system kept flagging it as spam when I tried to paste it here ..

Jeremy Davis's picture

I have been using TKL appliances on PVE since v1.9 and for me the v13.0 appliances are the smoothest experience yet...

Usually i create the container via the Web UI and then login via SSH once the container has been created. Since version v13.0, manually running turnkey-init is not required (it auto runs on first login).

My first guess is that the downloads are corrupt but I am only guessing... I just retested the v13.0 (x64) Canvas appliance on my PVE v3.1 home server and it starts and the init hooks run fine. For what it is worth here is a copy of the terminal:

root@proxmox:~# vzctl start 132
Starting container ...
Container is mounted
Adding IP address(es):
Setting CPU units: 1000
Setting CPUs: 1
Container start in progress...
root@proxmox:~# vzctl enter 132
entered into CT 132

Then it went to the usual init screens where you enter passwords etc. Finishing with:

[screen is terminating]
exited from CT 132
Chux Uzoeto's picture

Thanks for responding ..

The only thing you have done differently from what I have done is starting the CT via vzctl (I have been starting them first time via the vnc console)  ..

I have just tested canvas, by using vzctl to shut down the running CT, restarted via vzctl but I don't get the same result as you do (I don't get the init sections running).  Perhaps the first start via vzctl is significant ?

I get:

root@lab1:~# vzctl start 605
Starting container ...
Container is mounted
Setting CPU units: 1000
Setting CPUs: 1
/bin/cp: preserving permissions for `/etc/hosts.6': Operation not supported
 ERROR: Can't copy file /etc/hosts
Configure veth devices: veth605.0
Adding interface veth605.0 to bridge vmbr0 on CT0 for CT605
Container start in progress...

Generally, I also see issues pertaining to a $DISPLAY not being set when powering up via the proxmox GUI .. so, maybe first start via vzctl is indeed significant ..  OR perhaps these template images are corrupt, but I pulled them off the proxmox ve interfaces in the last few days. 

I will delete one of the images and start from scratch as a test, but the CT creation on proxmox takes hours to complete .. So, not something I am anthusiastic to try. 

Why do you reckon the creation of CTs takes such a long time on proxmox?  Perhaps something wrong with my setup?  FWIW, I have been creating the CTs with bridged networking and no fixed IP address

Chux Uzoeto's picture

Hello Jeremy,

Just seen your question .. yes, the templates were downloaded off the proxmox GUI storage management section ..  and just a few days ago.

On further considerations, I am beginning to wonder if my issues may not be related to using bridged networking (instead of nat/routed) .. is it possible that the turnkey initialization scripts expect nated networking in CTs?

Anyways, I am starting a test by creating a new CT with routed/nated networking .. will come back and confirm when it's done (TKL CT creation takes at least 2-3 hours for me .. rolls-eyes .. LOL) ..

regards ..

Jeremy Davis's picture

I usually use the web UI for the whole process. I don't usually use the commandline to start them, it was just easier to do that to demonstrate (I usually use the 'start' button in the web UI). So I'm not sure if that's the issue...

The templates download from SourceForge. While usually they are pretty good, over the years I have had the odd occasional issue with a corrupt SF mirror. Rather than re downloading you can find the signatures for the files on SourceForge (look for the sig file that relates to the template you are using here and use the process documented in the second half of this page).

But perhaps you are right. I generally always use the venet ('routed mode') and haven't tested with veth ('bridged'). Although out of interest I just did, I also launched it via the UI then entered via vzctl (rather than SSH) and it also worked fine.

As for how long it takes to start, part of the delay is the time it takes to untar the template (although in my case it's only a minute or 2 max). The next is the time it takes to do the auto updates (another few minutes max depending on internet connection - all the headless TKL appliance builds do an auto security update on first boot before the interactive bit runs - FWIW I let that finish before I entered the container).

Chux Uzoeto's picture

I rebuilt from the same images as I used previously (one with routed networking and the other with bridged) .. and I have exactly the same failure ..  I guess that takes away the suspicion of network config being the problem

This time, first start was via vzctl, but I cannot even get a successful session via 'vzctl enter' .. so, it does seem like these images are indeed corrupt ..

In terms of the amount of time it takes to deploy these containers, again that is a massive departure from my experience .. I generally wait for the proxmox GUI to come back with an OK when building a CT, before attempting to use it.  So, far I have not encountered a CT create session that completed in less than 2 hours ..

Perhaps my environment could be an issue:  I run a cluster of 2 proxmox nodes, and storage (both images and CTs) comes off 2 low spec NAS (one on OmniOS/napp-it .. the other on zfsguru) .. I will have  to run some tests and monitor CT creation to figure out where the delays are cominmg from.

In the meantime, I am downloading the images directly from sourceforge now .. will test again with fresh images and come back with some feedback.

Thanks again for your responses .. they have been very helpful.

Jeremy Davis's picture

If it is an issue with corrupt images on SourceForge then redownloading may not solve it for you - both PVE and via your web browser will find the closest/fastest SF mirror to you so you will probably get them from the same source/mirror. If you have the same or similar issues then I would suggest you do the integrity check that I mentioned above.

If the integrity checks out then it may be something up with your hardware or setup? It may even be related to your slow CT creation times?

I've just remembered that some time ago, at work I had a few intermittent strange issues with a PVE host, including some containers taking a long time to create and strange container issues similar to yours. Otherwise the PVE host worked fine so I just worked around it. But years later, when I upgraded the hardware and repurposed it as a desktop I discovered that it had a bad stick of RAM (Windows installed ok but did tons of random bluescreens, forcing me to do some diagnostics on the hardware). Could be worth consideration?

As for your slow CT creation, I would definitely run some network diagnostics on your nodes and NAS.

Add new comment