Creating OpenVZ templates by leveraging TKLPatch

Where

mv ~/$rootfs/template.tar.bz2 ~/$name.tar.gz

perhaps the leading ~ is causing the problem (because $rootfs should be adequite). It still doesn't explain (to me anyway) why the script doesn't either error or complete. I'll check this when I get home though.

Anone else got any ideas of feedback?

The patch applies and it does most of the work. I changed it so the top level script (a mod of tklpatch) is now meant to handle the final tempate creation. But I've discoverred that it is not returning from

tklpatch-apply $rootfs $patch

the last line before it seems to exit cleanly is:

Removing `local diversion of /sbin/initctl to /sbin/initctl.distrib'

and then it just stops, it does not error. I confirmed this by a simple echo after the tklpatch-apply line and it doesn't get printed on the screen. I'm not sure what I'm doing wrong. Perhaps I should start again from scratch!?

Although when released the kernels are usually only rpms. Proxmox currently gives you the choice of 3 stable kernels that support OVZ (the forth, 2.6.35 Ubuntu kernel is KVM only):

2.6.18 - both KVM & OVZ, quite old now, but still supported.

2.6.24 - both KVM & OVZ, still available, but no longer supported with updates.

2.6.32 - both KVM & OVZ (latest stable development branch) - default PVE kernel (based on Debian Sqeeze).

Sorry for the late reply. I've been doing a thousand things this days. I'm really interested in helping you pushing this out. Could you please run the command with | tee logfile.log to see the complete output?

tklpatch-apply $rootfs $patch | tee tklpatch-apply.log

Also check: that the conf in the patch has execution permission. If not, you know what to do:

chmod +x /path/to/conf

If it's executing, it's probably returning an error, and that's why it doesn't continue. I had a similar case, and don't remember exactly what was it, but suspect of the exec permission.

Attach the tklpatch-apply.log and check the permission and come back with the results to further help you. 

Also: I'm not ver familiar with OpenVZ, but I think it would be the perfect backend for the Master Server, because appliances would be able to share the memory of the host. But last time I checked OpenVZ, it was a bit outdated. The current kernel was not stable. Which kernel for openvz are you using? 

I remembered what happened then: the conf file didn't had the shebang (#!/bin/bash). This made that the conf file didn't execute. I think that was what got me to a situation similar to the one you describe. 

If possible after those test, if you can share the script to see what's the procedure you're following to generate the image.

I've finished studying your scripts. You:

1. Apply a fixed patch to generate the OVZ template. (The patch is complete chinese for me :S)

2. At the end instead of creating the iso, your creating the tar.gz template from the resulting /template folder inside the patched-fs. 

Beginning from this (great) idea, I could add to the tklpatch a flag --output-format=format and format could be iso (default) ovz, vmware, ami, etc. So tklpatch would:

1. After patching the base iso, add the additional tkl-ovz patch if format is ovz. 

2. The output would be the template and not the iso. 

For the tkldevenv, some changes would be needed. Instead of patched-isos, you would get Output (generally speaking). 

I'll work on a pilot with only the ovz alternative, but after releasing the next version of tkldevenv with the patchtool (I'll just finish some minor changes and the deployment of the django app so that some early tester can try it out).

Great work you linux newb! ;)

P.S.: BTW I'm already thinking on ways to make this faster. If all images would be based on a fs, maybe we can save some time having the uncompress fs ready for patching. MMMMM, I'll think a bit more about it. 

What I have posted only creates an OVZ template from an ISO, but could be easily tweaked to apply a patch first as well (that was my initial intention but I left that for now because of the issues I ran into).

If you go ahead with including this with your other ideas Adrian then perhaps it could use switches to determine what formats are output? (ISO/OVZ/VMware image etc)

Yesterday I thought about that, and I think it should be possible to produce also the other formats, not only OVZs.

I haven't made my research yet, but does creating the vmware image and Amazon's ami scriptable? I would love to see TKLDevEnv could produce those. Speaking of which, I'll try to push out the first version next week including the web patchtool. 

Having a TLKPatch to convert ISO's into OpenVZ templates will be awesome! It might even push us to release openvz builds of the appliances (once we setup a testing enviroment).

Regarding your issue, try adding -x to the shebang (e.g. #!/bin/bash -ex) as that will be display every command executed to stdout, which should help you zero in on the issue.

As it turns out my problems were being caused by a service still running in the chroot. On advice elsewhere I replaced rsyslog with syslog-ng which apparently performs much better in an OpenVZ container. At the end of installation though the service is started and I was neglecting to stop it. For some reason it wasn't throwing out any errors, just stopping after applying the patch.

The strange behaviour of the rootfs not being able to be deleted until after a reboot got me thinking. And some close attention to a full log (thanks to both Alon and Adrian - both pieces of advice helped there) I saw the service starting, so I simply stopped it and now all works well. Yay

I think it could do with some tweaking and trimming still - the template clocks in at 163MB (3MB bigger than the ISO) which is huge! But its a start! And the template appears to work ok (although as stated above I haven't done extensive testing).

I'd also study what you did here, in order to blend this into the tkldevenv in a not-so-far future. 

Good work! 

It shouldn't be like that.

That shows my inattention and lack of quality control - but in my defense it was 2am after a barbecue with friends. I was so excited that I had got the process to work that I actually didn't test the final template. I tested an earlier template from before I had solved my issue with the process cleaning up and completeing totally. I made the mistake of thinking that because I hadn't fundamentally changed the template creation process that it would still work.

I will fix it and reupload shortly.

[Update] Fixed and new version uploaded.

Is it ok that the final tar.gz file ends up with all files in the directory turnkey-base.fs/template/ ?

I'll try with this result but that made me curious. 

[Update]: I've just compared with other tar.gz template from proxmox and they have a . (dot) folder only and the filesystem in it. I'll be upgrading the proxmox to 1.7 and see how it goes...

That's the main one I've been using but I was also having a bit of a play with some other info I found around (mostly on the Ubuntu forums). When I intially set out to do this I sat down and went through it step by step until it worked. I recall having problems with SSH but the fix included in Bodhizazen's blog did the trick from memory. I thought that I hadn't altered the OVZ part at all since I confirmed a working patch and I'm sure I tested the very first template I made with this patching process and it was ok (even though at that point the process wasn't completeing properly - the template was still ok). But obivously I've done something without proper testing.

I'll go back through Bodhizazen's tutorial again, I'm also just having a look at the Ubuntu minimal template that he made (its a lovely ~80MB - half the size of the one I made of Core!) so hopely I might get a feel for some other stuff that can be trimmed. I probably should just get it working first though I guess! Then tweak it.

As for PVE, I've got 1.7 running at work but still on 1.6 at home. So far I have only used KVM for Win and some Linux testing. I know it has some pretty trick features but I still like the minimal overhead and I also quite like the fact that you can get into the filesystem when the VM is off (via the host - although too much playing in there upsets the guest when it restarts).

Today I took a quick look at the process of creating a template. I found this. I haven't compared if it's the same method you are applying. But once I finish some things I'm currently working on, I'll sit down with this. I'll update my home proxmox today too, and I'm planning to change from kvm to openvz to make better use of resources. But I also check the status of memory overcommit on kvm just in case I'm missing something. 

The templates created are currently not working well enough to say that this is successful :( The templates boot but I am unable to connect via SSH. None of the first boot scripts ran as I expected them to and there are very few services running (not yet sure why).

This is a major blow but I intend to persevere and try to get this working. Sorry to post without doing proper testing first. I sincerely apologise for any inconvenience.

[update] something seriously wrong with networking - confconsole is finding no interfaces to configure (none!) and ifconfig returns nothing. The appliance does not respond to pings and cannot be contacted in anyway that I can find beyond the VNC console built into PVE (no web services eg Webmin, no SSH/SFTP). It seems to be able to make outgoing connections fine (apt-get update completes with no errors) but no incoming connections.

There is a link to the unofficial precreated templates of the TKL v2009.10-2 range of appliances in the top post.

Proxmox is pretty easy to use, but first ensure that the template conforms to the PVE naming convension or othrwise it won't show up in the webUI: <OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz

Then upload the tar.gz image to Proxmox, either use SFTP (to /var/lib/vz/template/cache) or the interface (under VM manager on the left > Appliance Templates).

Once the template is loaded, go to Virtual Machines (under VM manager on the left) and select the middle "Create" tab (in the main interface). Select Container (OpenVZ) for the type then select your template from the dropdown. From there it should all be self explanatory.

Hi!

If i understood one or two things :), it seems there are some Turnkey openvz templates available and others are in the work

Is there any wiki page tutorial for newbies (using Proxmox) explaining how to install one of these Turnkey OpenVZ template ?

Thanks in advance

I anticiapte that eventually they will be officially released but not clear on when that may be.

Once I iron out the kinks, the process I have documented here will be available for any users to convert any appliance (even a community created one utilising TKLPatch) can be convert relatively easily.

If there is enough demand, even if the devs don't officially release OVZ templates I'm sure someone (perhaps me?) will provide at least some of them.

Perfect explanation, clearly helpful fo starters like me.

So, there will be some plans for releasing all turnkey images 11.0 for openvz, am i right ?

I thought I'd already replied to this post this morning - but obviously not!

The templates created from this process do not work :(. I have been doing a lot more playing today and I went back over that tutorial and commented out everything that wasn't there. I thought I was on a winner but it seems things are getting worse... The template has no network connectivity at all!

I think I'm going to have to scrap the lot and start again. I've got no idea what's going on. It's especially frustrating as I'm sure I had a 10.04 TKL OpenVZ template that works (which I created earlier on), but none of my recent ones seem to work.

This VZ log from Proxmox suggests that the container is starting properly:

/usr/sbin/vzctl start 230
Starting container ...
Container is mounted
Adding IP address(es): 192.168.1.230
Setting CPU units: 1000
Setting CPUs: 1
Set hostname: ovz-template-test.home.lan
File resolv.conf was modified
Setting quota ugidlimit: 0
Container start in progress...
VM 230 started

But this log (VM Syslog) from Proxmox shows that something is wrong as the networking is clearly not being set up right:

Dec 23 10:43:16 ovz-template-test syslog-ng[57]: syslog-ng starting up; version='2.0.9'
Dec 23 10:43:16 ovz-template-test ntpd[71]: ntpd 4.2.4p8@1.1612-o Fri Apr 9 00:28:40 UTC 2010 (1)
Dec 23 10:43:16 ovz-template-test ntpd[72]: precision = 1.000 usec
Dec 23 10:43:16 ovz-template-test ntpd[72]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Dec 23 10:43:16 ovz-template-test ntpd[72]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Dec 23 10:43:16 ovz-template-test ntpd[72]: Listening on interface #1 wildcard, ::#123 Disabled

As I think I've mentioned already, ifconfig returns nothing but /etc/network/interfaces seems ok.

# Auto generated lo interface
auto lo
iface lo inet loopback

# Auto generated venet0 interface
auto venet0
iface venet0 inet static
    address 127.0.0.1
    netmask 255.255.255.255
    broadcast 0.0.0.0
    up route add default dev venet0

auto venet0:0
iface venet0:0 inet static
    address 192.168.1.230
    netmask 255.255.255.255
    broadcast 0.0.0.0

Have you got any idea Adrian?

Hi Jed, I took a look at your script against the guide. I think almost all where there, but I added some things I didn't see. Anyway I upgraded my home server, but haven't had a chance to test. Is the last upload working fine or should I (when I found some free time!) try to help you fix the script?

Thanks, 

If you read through the forums here you will find that the core devs (Alon & Liraz are not against OpenVZ. They are actually very supportive of it and as eluded to by posts in your thread on Proxmox forums, there have been discussions between PVE & TKL (see here) but they basically stalled. Whilst the projects sort of overlap and could work really well together, Proxmox put their primary effort into their hypervisor and TKL put their effort into a broad range of software appliances in various image formats. This is summed up in a post by Liraz (core TKL dev) here. Martin (PVE dev) clarifies his position here.

My understanding of the TKL perspective is that the core devs already have an established workflow and 40+ (soon to be many more) appliances, already supported in multiple formats - ISO, VM image (OVF), Xen image, Amazon AMI, etc. They have expressed interest in and support of OVZ templates. I'm sure if they has an easy way to script creation of TKL OVZ images into their workflow then they'd have done it ages ago. But they have a todo list forever long and there's only 2 of them so unfortunatly OVZ support falls by the wayside. Despite the fact that I would love it if it was, OVZ is not a priority for TKL. And in fairness why would it be? I suspect most/many TKL users are primarily Win users and probably have no use for OVZ templates at all.

Until TKL devs set up some new build process, or make OVZ templates a priority, the only way we can have TKL templates is to do it manually, or work out a scriptable way to convert ISOs to OVZ templates (hence this thread).

If you read the other thread that I linked to you will see that for the TKL devs its a case of having a reason to put greater priority on OVZ templates for Proxmox. I don't see this happening until someone steps up and sorts out the 3rd party channel suppport for PVE. Martin has stated that they'd be happy to support anyone who steps up and does it. And Liraz has stated that once thats done he'd be happy to prioritize OVZ templates.

I'm not very sure if it's directly related but, as exposed here http://forum.proxmox.com/threads/5369-Turnkey-Linux, it seems the proxmox guys proposed to help the Turnkey team members for the creation of openvz templates.

Why is it not possible for Turnkey team and proxmox team to work hand in hand ?

Thanks very much for getting this running Adrian.

I will be testing within the next few days hopefully. Getting some v11 based OVZ containers running on my new Proxmox VE server at work is high on my things to do list. :)

My fault, I forgot this is not only a patch, I'm starting to work right now on preseeding the values on first boot, when I finish I'll upload the new patch along with the scripts. 

BTW, take a look at it, if you see something you'd like to understand feel free to ask, we agree on that. 

The atachment only seems to just have the patch file, not the other scripts. Thanks mate.

As I was running in tkldevenv, I didn't get this error, but yes, I should remove that fixed path from the standalone version of the main script (tkliso2ovz). 

Hey Adrian, it looks like you may need to add creatation of the log path in the patch.

Initially I was having errors:

/usr/local/bin/tkliso2ovz: line 86: /var/log/tklpatch/turnkey-core-11.0-lucid-x86-ovz.log: No such file or directory

But creating the tklpatch folder (in /var/log) fixed it. Other than that it all seemed to work well. Ok, off to test the template :)

And included my version based on your work. I'll include this set of commands/patch to the tkldevenv, maybe with an additional command to patch-to-ovz directly.

Hope this works!

Perhaps the next step after posting this on the forums and maybe getting a bit more community members to test this will be for us to fire up an EC2 instance, rebuild all the ISOs into the OVZ format, push them to sourceforge and announce on the blog that they are ready for wider testing.

Our original plan was to make the TKL 11.0 release available in 5 formats:

ISO, VMWare's VMDK/VMX, OVF, Eucalyptus, Xen.

But your works makes it exceedingly likely OpenVZ will be soon added to that list. This is more interesting than just adding another format because unlike the other platforms, OpenVZ is a lightweight container-type virtualization system that is inherently more resource efficient than "hard" virtualization.

I think we're  almost ready to produce a batch of templates and publish it for testing! I'll be testing some appliance this week at home but so far is very stable to me. And they already startup preconfigured with default settings, so the complete turnkey experience is there. 

No issues to mention although I have only tested a couple (Core & Fileserver). Looking Good Adrian. :)

Hi Jed, I didn't had that problem when converting torrent-server, I'm currently using it in my server. So I'm not really sure what happened there, but I'll retry again to see if I get your errors. Maybe if they are not getting to the log, that's why I didn't catch them. It's possible as I probably runned the script and went off the computer and came again some minutes after. 

Anyway, is it working properly?

Hey Adrian I am just converting a few ISOs to OVZ templates and came across this error when decompressing the ISO:

zlib::uncompress failed, unknown error -3

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/gus/snd-interwave-stb.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/gus/snd-interwave.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/msnd/snd-msnd-classic.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/msnd/snd-msnd-lib.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/msnd/snd-msnd-pinnacle.ko, skipping

Otherwise the process seemed to go ok and seeing as they all seem to be kernel sound modules I suspect it's not a big deal, still seems strange. Any idea? Also FYI the errors occurred in the terminal but weren't recorded in the log file?

Using this process I have uploaded a few OVZ templates to SourceForge, have a look here. I would appreciate feedback from anyone wishing to test them.

I am currently testing a few but haven't tested everything I've uploaded so please be patient. And also please report any bugs, although I may not have the time or know-how to provide any quick fixes.

@Adrian, FYI I have not had a repeat of those errors above for any of the appliances I have converted so not sure what happened there. I built these OVZ templates using your TKLDevEnv with the latest OVZ conversion TKLPatch from your GitHub (Jan '11 IIRC).

I am running mine under PVE and have not had any major issues but I have noticed that there does not seem to be any startup scripts running on first boot (none that are interactive anyway) although perhaps this is something to do with the PVE implementation of OVZ?

Also Todd is having some issues with the Revision Control appliance (OVZ template uploaded by me; running under PVE AFAIK). If you have time Adrian be great if you could give your 2c. The post is here although, it's probably most relevant to continue this discussion either here (or perhaps I should've started a new thread). Thanks mate.

Any input from anybody else who is familiar with OVZ would also be awesome!

Download the latest kit from Adrian's GitHub account (link just above the download). Then apply as you would a patch, but instead of outputting a patch ISO it should output a .tar.gz OVZ template. If you are unsure on how to apply a TKLPatch then look at the documentation. Any further probs please feel free to post back.

I just had to set up a clean environment to create some new templates and found it harder than it perhaps should be, so for the uninitiated I have created a quick, dirty how to using the fileserver appliance as an example. I also checked and it looks like the kit available for download here is the latest version created by Adrian. The links may change so the wget lines may require adjustment.

Firstly in an installed TKL appliance, preferably a clean install of TKL Core (probably just to a VM or something) and once it is running execute the following commands (from the /root directory, by default that's where you should start from when you login):

Install TKLISO2OVZ:

apt-get update
apt-get install tklpatch
wget http://cdn.turnkeylinux.org/files/attachments/tkliso2ovz.tar_0.gz
tar xvfz tkliso2ovz.tar_0.gz
rm tkliso2ovz.tar_0.gz
mv tkliso2ovz /usr/bin
mv tklpatch-gen-ovztemplate /usr/bin
mkdir /var/log/tklpatch

Now creating an OVZ template of the Fileserver appliance is as simple as (download the ISO and convert it):

wget http://downloads.sourceforge.net/project/turnkeylinux/turnkey-fileserver/11.2-lucid-x86/turnkey-fileserver-11.2-core-x86.iso
tkliso2ovz turnkey-fileserver-11.2-lucid-x86.iso

If you are using ProxmoxVE you can change the name (to match PVE naming conventions - you will need to do this for each file adjusting for the appliance name):

mv turnkey-fileserver-11.2-lucid-x86-ovz.tar.gz turnkey-lucid-fileserver_11.2-0_i386.tar.gz

and then rsync it to the correct directory on your PVE host:

rsync -goptv --stats --progress  *i386.tar.gz 192.168.1.50:/var/lib/vz/template/cache

nice, nice....

Never saw this thread.... and since OVZ templates could also be used for LXC templates this is very interesting !

Thx

Most simple thing to clean is :

/lib/modules/*    /lib/partman    /lib/firmware/*

saves about 90Mb

Where are the firstboot scripts located... ?

I am trying to modify the openvz to lxc, so i am interested in that part

Hi all, I have recently made some new OVZs (using this method) and uploaded them. I have been having some issues though and from investigation it seems that the firstboot init scripts are causing some issues. The firstboot scripts are running but as they don't appear when you connect to the VM they just sit there running without other services starting. I will do some further investigation and see what we can do. I would also like to try to remove some debris to reduce their size (the kernel is one thing for starters).

I will look to do this soon but if anyone has any ideas I'd love to hear them.

I have just uploaded a major update of this and have repackaged Adrian's script and the tklovz patch as a TKLPatch itself. This allows for really easy install (although note its a little funky in that it does not allow for uninstall - it needs to be manually removed). Anyway details in the top of the OP.

@Hans - Thanks for your post. As it turns out I discovered the /lib/modules/* /lib/firmware/* locations myself and removed partman altogether (IIRC it's a component of one of the packages I uninstalled). I also removed a few other irrelevant packages and found a couple of other bits and pieces that could go. The TKL Core template is now ~100MB (~60MB less than the ISO & nearly 70MB less than they were).

I have reworked what Adrian did a little and OVZ containers now use the non-interactive default TKL inithook firstboot scripts. The interactive ones were causing issues (because OVZ doesn't have a true console) so I created an initialisation script ('init-ovz') that needs to be run manually (ideally straight after firstboot). This will run all the interactive firstboot scripts.

I don't know much about LXC but I would imagine that the templates created by this shouldn't need too much tweaking. Be great to hear how you go.

[edit] I have just discovered a minor bug in that apt-get autoremove is trying to remove a package 'turnkey-sslcerts' (which possibly should be set to manually installed anyway?). As it waits for input (y/n) it halts the conversion process. This isn't a huge issue and can be easily fixed but I'm not going to worry about it just now.

As you may have noticed, I have forked your tklovz patch (on GitHub). It still needs some minor work I think: The apt-get autoremove issue I just posted about and also the way I did the firstboot scripts would perhaps be better scripted into the tklovz patch rather than included in the overlay (what do you think Adrian?). Also I think that there is still probably some stuff I could get rid of (still some cruft in there and some of the packages that I set to manual install may not be needed).

All in all though I'm quite happy with it!

Also I've been thinking that it'd be nice to have this packaged as a .deb (allow for easy install and removal) and I was thinking of including it in my (as yet unused) PPA. Any thoughts on that?

Good to have you back Adrian :)

Looking forward to that script, because I am completely stuck at the moment

I extracted the openvz core to an rootfs directory for lxc, made a manual config for it and adapted the etc/network/interfaces to a static address within my host bridge address range (also static)

Removed the ntp, rsync and webmin from the rc[0-6].d directories to get minimal services started.

chrooted into the rootfs and set the root password

seems I have problems with tty's & pty,'s  I get :

root@userver1:/var/lib/lxc/tkl01# lxc-start -n tkl01
 * Starting system logging syslog-ng                                     [ OK ]
 * Starting Initialization hooks             openvt: Unable to open /dev/tty8: Operation not permitted
when I do a ssh into the machine, i get a password prompt but after that my other session gets the output....

hans@userver1:/var/lib/lxc/tkl01/rootfs$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 09:46 ?        00:00:00 /sbin/init
root        81     1  0 09:46 ?        00:00:00 /usr/sbin/sshd
root        86     1  0 09:46 ?        00:00:00 cron
root        96     1  0 09:46 ?        00:00:00 /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
root       121    81  0 09:46 ?        00:00:00 sshd: root@pts/0
root       135   121  0 09:47 ?        00:00:00 -bash
root       233   135  0 09:54 ?        00:00:00 ps -ef
root@tkl01 ~#

the prompt is from the host and the output is from the tkl container... :)

when you uploaded the script I will test it..

So far so good, I have now a running/working TKLcore in a  LXC container...:)

Seems the problem lies in the conf files in /etc/init

root@userver1:/var/lib/lxc/tkl01# lxc-start -n tkl01
 * Starting system logging syslog-ng                                     [ OK ]
 * Starting Shell In A Box Daemon shellinabox                            [ OK ]
 * Starting webmin                                                       [ OK ]

Ubuntu 10.04.1 LTS tkl01 /dev/console

tkl01 login: root
.....
Welcome to Tkl01, TurnKey Linux 11.2 / Ubuntu 10.04 Lucid LTS
.....
root@tkl01 ~# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 14:02 ?        00:00:00 /sbin/init
root        99     1  0 14:02 ?        00:00:00 /usr/sbin/sshd
root       132     1  0 14:02 ?        00:00:00 cron
root       153     1  0 14:02 ?        00:00:00 /usr/sbin/syslog-ng -p /var/run/
ntp        154     1  0 14:02 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.
104        218     1  0 14:02 ?        00:00:00 /usr/bin/shellinaboxd -q --backg
104        220   218  0 14:02 ?        00:00:00 /usr/bin/shellinaboxd -q --backg
root       231     1  0 14:02 ?        00:00:00 /usr/bin/perl /usr/share/webmin/
root       237     1  0 14:02 console  00:00:00 /bin/login --
root       251   237  3 14:02 console  00:00:00 -bash
root       285   251  0 14:02 console  00:00:00 ps -ef
root@tkl01 ~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
default         192.168.2.1     0.0.0.0         UG    100    0        0 eth0

Steps:

• created a LXC config
• just unpacked the ovz tar in the rootfs for LXC
• changes in rootfs/etc/init:
  • rc-sysinit.conf    ->   start on filesystem    (without waiting for lo device)
  • added a console.conf  which respawns exec /sbin/getty -8 38400 /dev/console  
• Removed Sxxinithooks and Sxxntp from rootfs/etc/rc[0-6].d

Somehow I still get a ntpd started, no idea where that is triggered (yet).    I think I will disable the webmin and shellinabox also,  those can be started when needed...

but I am very pleased.... very

Guys, sorry for being lost, I've been under a lot of work and real-life things, but I promise tomorrow I'll post my tkl2lxc script (which is ready almost a week ago). The script only fails on startup, so maybe combining Jed's work with this script will result in a working script to produce lxc templates from isos.

I'm travelling tonight, I hope as said before to be able to upload this patch tomorrow and maybe Hans can test the script.

My GitHub fork is here. I have decided to script the firstboot stuff (rather than use an overlay - I think it makes it easier to understand what is going on) and I have just commented out the apt-get autoremove for now. I have just pushed these updates to GitHub (I'm still getting the hang of git and GitHub, but I'm getting there...). Also I haven't updated the download (here) with the new version yet.

FYI what I did to get it to start cleanly was simply to move out all the firstboot scripts and just move back the unproblematic ones (ie non-interactive). I did it that way so it can apply to any and all appliances, regardless of the firstboot scripts it has. See the code here.

Open to suggestions on how to do it better though! :)

make that  and it will work :)

wget http://www.atbas.org/tkliso2lxc0.1.tar.gz

Although the script is mostly Adrian's work. I started it but he got it to work! Then I refined the OVZ conversion patch.

Anyway good work! I haven't got LXC setup anywhere so I can't test but I think it's great.

I adapted your tkliso2ovz and merged it with Adrian's lxc script and streamlined it a bit, and  now I have the same one for LXC  tkliso2lxc

Perhaps you can get it  and put it on your GitHub. That way you can generate OVZ and LXC files from the TKL iso's

I think TKL is now the only one which can generate prepared LXC containers... :)

apt-get update
apt-get install tklpatch
wget http://www.atbas.org/TKLiso2lxc0.1.tar.gz
tklpatch-apply / TKLiso2lxc0.1.tar.gz

usage:
tkliso2lxc turnkey-core-11.2-lucid-x86.iso

Almost everything is the same, except the init scripts are original and for inithooks I created a interactive.d directory

I think ovz and lxc are almost compatible, so if there are changes in the ovz conf, they probably are needed also in the lxc conf file.

You can grab the script here, and play with it. The problem is the same with init-scripts, I was holding this script until I could solve those, but I've been full with work/real life so I felt it was important to pusblish it and see if others can help two.

@Jed: I didn't notice the fork, at least github didn't send a message, anyway, I'll have to take some time to take a look at what you did, but depending of the amount of changes to inithooks, I think overlaying them it's ok. The fact is I removed proxomox from my home network, and replaced it with openstack. The transition haven't gone smoothly, and I'm currently in the middle of restoring all the services that where running at home, so: I won't be able to test more ovz templates, but I'll be able to test lxc and I think both differ little. 

@Hans, please share your results!

I'll keep reading the forum!

Since official TKL OVZ templates have been released there hasn't been any need. And even when applying patches, I have been patching the templates rather than just creating an ISO and converting it. It's pretty easy, I put intructions on the TKLPatch docs (although it would probably be self-evident to someone such as yourself).

The 12.0rc is available as an offical template too (here).

Perhaps it'd be easier to write a patch to apply to the OVZ template? I actually forked TKLPatch to include the ability to apply patches directly to OVZ templates (as well as ISOs) but after discussion with Alon development on that one stalled (he thought it would be better to just have a separate high level script - which would be much easier and straight forward).

ok, I see, the OpenVZ tgz file is now also automatically generated, cool ...

Any differences with the previous one with tklovz. Can you specify what is changed...

I will see if I can write a script which takes the tgz OpenVZ version and adapt what is needed for LXC.

more simple that way.

Jeremy,

Have you already been trying to make an OpenVZ version of the Debian 12.0rc2 version ?

I was reserving some time next week to try it out for LXC again ...

Should be a bit simpler without the upstart scripts I think.

Perhaps I can combine the OpenVZ and LXC code into 1 script since there are very little differences.