TurnKey Core 13.0 RC (i386, amd64, wheezy)

Drumroll please... I'm thrilled to make not one, but two announcements!

  1. TurnKey Core 13.0RC: This is a release candidate of TurnKey Core 13 based on Debian 7.0 ("Wheezy")- the upcoming version of Debian, which hasn't officially been released bu shouldn't be too far off.
  2. 64-bit support: TurnKey Core 13RC is available in both 32bit and 64bit versions. This means we can now guarantee that TurnKey 13 will come with 64-bit support. The wait for is nearly over. To be honest lack of 64-bit support been a nagging source of embarrassment for TurnKey for quite a while now. A significant 66% of users said this was "Very important" to them. We agree.

Download the RCs and help us test them

64bit / amd64 build146MB ISO (changelogsignaturemanifest)

32bit / x86 build: 144MB ISO (changelog, signature, manifest)

Getting ahead of the curve for TurnKey 13

In the past we've released updates to the TurnKey library a few months after a new operating system release came out. We want this to change. Ideally new releases of the TurnKey library should come out roughly in sync with new releases of the underlying Linux distribution it is based on.

We're going to try and make that happen for the next release. Hence this early version of the new TurnKey Core release candidate.

This time around there's more than just wishful thinking involved. We have better tools. Part of the motivation for improving TurnKey's development infrastructure was to simplify development and increase efficiency to make it easier for the project to keep up with new OS releases while the growth of the TurnKey library continues.

That means for the next release we won't be waiting. Even though Debian 7 ("Wheezy") is still officially in the "testing" phase, it is coming together very nicely and we're moving into position for an early release. Because we can!

Multiple architectures

As Liraz mentioned, we've been hard at work cleaning up and upgrading our development infrastructure, re-engineering the build process from the ground up, reducing complexity, adding automation and making the whole structure easily reproducible and extendible.

We've been working towards three primary goals: efficiency, multi-architecture support, and easily reproducible open development toolkit that would allow the community to participate in the development of TurnKey on equal footing.

The first two goals are now complete and we're almost there with regards to the last goal: enabling anyone to build TurnKey appliances from scratch using the same tools the core development team uses.

Getting back to the RC's - all changes, bugfixes and tweaks are available in the changelog. As for the features, not much has changed except for the base distribution at this point.

Long story short, try the RC's and tell us what you think.

[Please note, due to spam comments on this old blog post have been closed. Please open a new thread in our forums].


OnePressTech's picture


Your timing could not have been better.

I just finished an Alfresco build on a non-TKLX 64-bit Debian Squeeze using DotDeb and select Wheezy packages (yes it seems to work fine if anyone was wondering) but I missed my TKLBAM and I hated having to make the decision to move to a two-platform model or to move away from TKLX.

Consider me a confirmed guinea pig.

I'll download TKLX13 Core next week and re-build my Alfresco. If you want a guinea pig for your build infrastructure I'll build the Alfresco using it. Perhaps Adrian Moya might be convinced to re-connect with his legacy Alfresco patch and we can help you with the TKLX13 Alfresco Appliance :-)

Thanks again to you and Liraz for your tireless efforts and excellent workmanship on this significant initiative.


Tim (Managing Director - OnePressTech)

BenL's picture

Hi Tim, I have Alfresco here on bitnami but am interested in your efforts on TKLX. I would be grateful if you could keep us informed of your progress.

Jeremy Davis's picture

Nice work once again guys. I like your thinking! Some of the TKL dreams getting a bit closer to reality! I'll download it and take it for a spin sometime soon.

@Tim - I'd be very interested in trying out your Alfresco appliance when it gets to that stage! I had a go at setting it up on vanilla Squeeze a little while ago but it was a bit flakey (I don't think it really had enough RAM was the main issue, but I didn't have any more to spare at the time). And it'd be great if we could get Adrian reinvigorated here again too. That man is a bit of a powerhouse... 

OnePressTech's picture

No worries Jeremy. As long as you're patient. I have to multiplex with other things so it will take 3 or 4 weeks elapsed time.

I will also be scratching my head over the latest disclosures of Java weaknesses and deciding how we might best secure the appliance and it would be good to have someone to bounce options off of.


Tim (Managing Director - OnePressTech)

Lawrence Sylvain's picture

I know this thread is old, but I am very interested in an Alfresco appliance.  I am starting a software group for a small company and have decided to standardize on TurnkeyLinux appliances for our development infrastructure except in cases where there is a compelling reason to do otherwise.  For an emerging team such as ours (just brought on my first new engineer) and no IT department we can avoid spending time on many things that TKL has built in, such as security updates and backups.

TKL rocks!  All except one VM we are using is TKL.  The hold-out is an Alfresco VM I created months ago that is CentOS 6.2-based.  If time allows I may try my hand at building a TKL appliance, but I am spread thin on time and don't want to duplicate effort - especially since I'd be cutting my teeth creating my first TKL appliance.

Thanks for your efforts!

With Highest Regards,

Lawrence J. Sylvain

Lead Software Systems Engineer
Soliell, LLC

OnePressTech's picture

Hi Lawrence,

No additional progress on the Alfresco appliance. Sorry.

I'm still working through the appliance lifecyle management strategy for it.

I've been on a journey to build up a single unified SMB technical stack based entirely on open-source and cloud architecture that can be deployed under a managed service model at an SMB price point so I tend to look at lifecycle management first, maturity second and feature set third. Alfresco is excellent on items 2 & 3 but expensive for an SMB market for item1 (it has a hefty lifecycle management cost at the SMB level...lots of different moving parts under the bonnet...under the hood for any americans in the audience). Before I commit to including it in my stack I needed to ensure that it was not an overkill for an SMB client.

I have currently standardised on an integrated Customer Cloud based on:

- GitLab / GitHub (Build Centre)

- Wordpress + selective integrated Plugin Suite (Customer Cloud)

- OTRS & Zabbix & Pingdom (Support)

- Developer Tools & Test Cloud

So I am taking a pause to consolidate my lifecycle management structure before cotinuing the stack growth phase.

Alfresco wants to be the document management backbone of my stack but I expect it to double my lifecycle management costs and client support costs so I'm really just in a hold pattern until I sort out the logistics and commercials. I do have a client who this may be a perfect fit for so I will be revisiting this over the May / June timeframe.

Let's keep in touch.





Tim (Managing Director - OnePressTech)

BenL's picture

I agree: Alfresco is just too expensive and too complicated.=20

OnePressTech's picture

Hi BenL,

Are you currently lifecycle managing one or more Alfresco installations or are you in the "been there, done that, no thanks" crowd?


Tim (Managing Director - OnePressTech)

Lawrence Sylvain's picture

Yes, Alfresco has dependencies on Tomcat (with many whistles and bells), LibreOffice, PostreSQL, GoogleDocs....  the list goes on and on...  So the SMB challenges are indeed daunting.  Of course, that's the reason for having an appliance, but what I sense is that at least some folks here see this as a fairly extensive undertaking (i.e., not something  you can easily do in your spare time).

In your case, Tim, I can see how Alfresco could end up consuming a sizable amount of time in an undertaking that is intended to be far more comprehensive in scope.  Reading what you are up to, it's interesting that I am having to combine a few TKL VMs to accomplish what your one-stop solution will do on its own.  I will be very much interested in checking out your VM when it's available.

Heavy-weight SMB issues asside, Alfresco is an accessible, intuitive, easy-to-use document repository for management and non-technical employees as well as customers and partner companies.  Once I install it and spend a little while with introducing the admin functions to a saavy user I can turn it over to them to manage user accounts and organize the repository so I can get to work developing the actual solutions we deliver.  So there is value, but the issues cannot be ignored, so it seems Alfresco will probably need to reside in a dedicated TKL VM.  That wouldn't be the end of the world.  So this will probably come to to being a question of having time to complete the effort....   That's why there's an Alfresco Cloud service, eh?

With Highest Regards,

Lawrence J. Sylvain

Lead Software Systems Engineer
Soliell, LLC

Jeremy Davis's picture

In my (brief) Alfresco experience (installed and set up in my previous job) it was a resource hungry beast and as such my personal preference was to keep it in a separate VM. Although personally I generally prefer the redundancy of having each function within it's own VM (actually I use OVZ containers under Proxmox wherever possible). So as long as the host doesn't go down it is unlikely that you'll lose all your services at once... But that's just me...

Chris Musty's picture

13 looks like an awesome release too!

I am so hanging for sydney support...

Chris Musty


Specialised Technologies

OnePressTech's picture

Go Aussie :-)


Tim (Managing Director - OnePressTech)

Dylan Zych's picture

Turnkey linux is one of the best, most thought out linux distros that exist... the fact i can deploy a wordpress blog within 5 minutes is amazing... the dual x86 and x64 is also a huge change that will do nothing but improve the turnkey library... ive used many of the apliances, both virtual and bare-metal in production, and they are awesome... the fact that its intigrated into Proxmox as openvz containers is also a plus, because proxmox is also a fantastic linux distro... i cant wait to rsync the new library!!! keep up the great work guys... :-)

Dylan Zych's picture

forgot to mention, the switch to debian in my opinion was a great decision... dont get me wrong, ubuntu rules and im a huge fan and also a user, but i feel for stability, if its not centos or redhat, its def debian... and personally, i'm an apt-get guy myself... :-)... thanks

Jeremy Davis's picture

Purely from a forum mod perspective it is definately been a good choice. I don't think there has been any OS level bugs reported since the switch (still a few bugs but related to  the softwar on top of the OS). Ubuntu is great but Debian is simply much more polished and tested/

Jeff L's picture

Great news on the x64 front! And I am still VERY happy with the decision to move to Debian for stability for the very reasons Dylan stated. Hopefully installer from iso will recognize plugged in USB flash drives for feeding non-free debs (like Broadcom NIC firmware) during install (several of the v12 spins did not recognize the usb as a deb source on install).

Eric (tssgery)'s picture

I'll give it a whirl later this week.


Should we just post any issues/comments in this thread?

Jeremy Davis's picture

But I have just updated and tidied the bug tracker (on LaunchPad) a bit so that is another (or additional) option... I'm not really sure on the dev's preference so I try to report bugs (that I experience and other report) on LaunchPad anyway.

Alexandre Takacs's picture

Great news ! Will keep busy over the WE :)

Adrian Moya's picture

I've been waiting for long time that the development toolkit gets overhauled, as I mainly enjoyed developing appliances for the project. The fact that I moved to openstack at home (and being unable to create my own openstack images from the tklpatch source, at least in an automated pleasant way) moved me away from turnkey, but I still follow the project carefully, and keep contact with the main devs.

I think that when I have access to the early release of the dev toolkit I'll be happy to contribute back to the project. Also the fact that I'm going back to proxmox at home (My openstack studies have finished for now) will help to motivate myself on playing with patches again. I hope to read about that release soon!

tchelle's picture

I am a big fan of Turnkey and would like to use tk-core-13rc 64bit in an AWS demo for my company. The data warehousing software we use is memory intensive so the new 64bit core allows me to put on a realistic demo for the first time. Will you be making a v13rc 64bit AMI available?

V Kozlov's picture


Great news!
However, we are looking forward to when you collect OpenVZ container core debian 64
Thanks for your work!
Paulo Cesar Emerique's picture

Hi, we are focused on Alfresco deployments, and had to "go another route" to provide 64 bit Alfresco servers (Alfresco demands 64 bits on recent versions).

We look forward to work with you (Tim Hibberd ...) on a good configuration ... from our experience we must tune "kernel max open files", "Postgre memory settings", Tomcat memory settings ...



Paulo Cesar Emerique / www.esensetec.com.br

Bill Carney's picture

I'm new to the Linux world, and TurnKey.  Is there an upgrade path that will bring my existing VMs up to date when this is released?  Thanks for any insight.

Jeremy Davis's picture

Not yet anyway. But once Debian 7 is released then Debian 6 (basis of TKL v12.x) will have 12 months of support. So you will have a 1 year window to test, modify (if necessary) and deploy on v13 before you lose the Debian supported security updates to the core OS.

Also TKL appliances that include upstream apps will benefit from upgrading sooner rather than later (the included upstream software will be the latest version, whereas the v12 version will be getting a little dated and may contain bugs...)

As for upgrading - the preferred way is to migrate your data to a new instance (rather than doing an in place upgrade) and that is what TKLBAM is designed for. Reality is though it doesn't always work flawlessly when going between versions, so I would suggest that you migrate your data to a new TKL instance running as a local VM. Then you can iron out any issues there may be prior to doing your real migration.

Here's how I'd do it:

  1. TKLBAM backup of your existing appliance
  2. Install v13 appliance (once released...) to a local VM (eg VirtualBox)
  3. Restore your backup to this new instance
  4. Get it fully functional (will depend on the appliance - may require very little work, may require a bit...). Make sure you thoroughly document everything you do... This can be done locally, or here on the forums (if you're looking for input and pointers). Regardless it'd be nice to share when you're done! :)
  5. Once you have your new v13 VM working just how you want it, run another TKLBAM backup of your production site, then lock it (assuming it has dynamic content - otherwise skip this step...)
  6. Restore your TKLBAM backup to your new v13 production server and follow the steps you documented earlier...
  7. Enjoy! :)
Tomasz Kluza's picture


Great news about the support for 64bits. Anyone playing with the PVE and the TK C 13 64 bits ?

Jeremy Davis's picture

But only under KVM and I haven't really done much with it...

Allan L's picture

Sorry - I can't see how to report bugs for this RC release. First: great product - I'm very impressed. Second: Manual partitioner is a mess of {$!TAB or similar - sorry I didn't do a screenshot but you can't miss it. Was able to complete the job because I know the Debian partitioner so can guess what was unreadble. Booting the 64bit .iso in a KVM - graphic i/f via VNC. Once again - well done and amny thanks.

Allan L's picture

Note - I'm setting this up for use as a VM image. It will never be run on bare hardware.

1. Grub changes for serial (we need this in our way of launching VMs) - no problem. Would be nice if it were configureable. Otherwise OK.

2. Grub change to use apci for the timer else time runs erraticly in the VM can cause ntp problems. Needs clocksource=acpi_pm on the GRUB_CMDLINE_LINUX line. Would be nice if it were configureable. (i.e. if you know this image is for a VM you need this)

3. fstab changes to use disk labels (because this is how we do it when we a launch a VM). Worked via webmin - nice -:)

4. VMs always need rng-tools. The hosts provides a virual rng device. rng-toold daemon stuffs the random bits into /dev/random. If you don't do this you will never get anything out of /dev/random in a VM. Forget making gpg keys etc. Should come pre-installed.

5. Now the (almost) show stopper. ntp is a mess. something runs ntpdate which stops ntp from starting on boot. Either it is the script in /etc/network/if-ip.d or it is webmin (I suspect webmin because the Debian scripts protect each other with a lock file and this problem does not happen on raw Debian).

I tried loading the webmin-time module via apt-get but that just made things worse. This seems to use ntpdate for timesync instead of ntp. Thus it breaks real ntp.

So I removed webmin-time.

Then I wanted to remove ntpdate but that would take out tklbam too!!!

My fix was to remove the x permissions on ntpdate - so far so good but this is not a real solution. Maybe problems down the road.

VM servers need ntp (using the host as the ntp server). There are serious problems with time jumps otherwise.

As if this isn't enough for ntp there is another problem in that the time servers are not being updated by dhcp.

Please take another look at how ntp is set up. It is a major basic service that all appliances need. Maybe there needs to be a selection 'use ntp or ntpdate?'

6. Webmin shows me eth1 which does not exist - not on ifconfig or ip link.

That's enough for today. Thanks again - don't see the above as negative in any way.

Josh's picture

I am loving TKL, and have an upcoming project that need 64 bit. Lookin forward to some news about stable release date!

Thank you!

Angus 's picture

We have had no news about the 13.0 RC, since the blog post.

No reply to Josh's questions from a month ago.

I am starting a new project and want to back turnkey linux, but where is the update on progress and testing?

MrZaius's picture

Last year's release cycle was an April RC and an August stable release.

Jeremy Davis's picture

So as such, there will be no TKL v13.0 stable release prior to a Debian Wheezy stable. And last I heard the devs are madly working on a v12.1 release ready to roll out the v13.0 release as soon as they can after Wheezy goes stable.

Angus 's picture

Thanks for the update... 

Jeremy Davis's picture

As of about a week ago, the Debian team announced an anticipated final/stable release of Debain 7.0 aka Wheezy for weekend 4/5 May 2013!

Please note that this date is not 100% firm, but given the history of Debian releases, highly likely. From http://lists.debian.org/debian-devel-announce/2013/04/msg00006.html:

The intention is only to lift the date if something really critical pops up that is not possible to handle as an errata, or if we end up technically unable to release that weekend (e.g. a required machine crashes or d-i explodes in a giant ball of fire).

What this will exactly mean for the expected release date of TKL v13.0 is not completely clear as Alon and Liraz are yet to release the v12.x first and final update (v12.1).

But hopefully we will see TKL v12.1 here  really soon and the guys can refocus their efforts on getting v13.0 final out the door! :)

Andy Barnes's picture

There was a second RC of wheezy released by Debian on Saturday, I was wondering if you were going to be releasing another turnkey-core based on the latest RC before it's released?


Jeremy Davis's picture

This TKL v13RC is actually built on a Wheezy beta (beta2 IIRC??). As I mentioned above, the guys are working on a v12.1 release ATM and so I doubt we'll see any movement here until that is public (hopefully will be soon though!)

Andy Barnes's picture

We're trying to build an appliance that requires SELinux installed. When I add the packages "selinux-basics selinux-policy-default" it works fine for our squeeze build however it breaks the wheezy iso generation (fails to build iso when we tklpatch turnkey-core-13.0rc-wheezy-i386.iso our-patch/). No post install configuration done - just installing the packages from conf/pre-overlay

Where should we be providing feedback/bugs or are you guys not interested in this stuff until 13 has been released propper?


Andy Barnes's picture


<snip - because you don't want the whole output!>
Setting up virtuoso-vad-conductor (6.1.4+dfsg1-7) ...
Setting up virtuoso-vad-isparql (6.1.4+dfsg1-7) ...
Setting up openjdk-6-jre-lib (6b27-1.12.4-1) ...
Processing triggers for ca-certificates ...
Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate cert.pem
WARNING: Skipping duplicate certificate cert.pem
7 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Adding debian:Actalis_Authentication_Root_CA.pem
Adding debian:Buypass_Class_2_Root_CA.pem
Adding debian:Buypass_Class_3_Root_CA.pem
Adding debian:EE_Certification_Centre_Root_CA.pem
Adding debian:StartCom_Certification_Authority_G2.pem
Adding debian:T-TeleSec_GlobalRoot_Class_3.pem
Adding debian:Trustis_FPS_Root_CA.pem
Processing triggers for python-support ...
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)
Removing 'local diversion of /sbin/initctl to /sbin/initctl.distrib'
root@core ~# ls

If I remove selinux-basics & selinux-policy-default it builds fine.

Andy Barnes's picture

Wierdly if I remove selinux-basics & selinux-policy-default and then build an iso image. Boot a new machine off said image and then do;

apt-get update; apt-get install selinux-basics selinux-policy-default

it works fine :-/

Alexandre Takacs's picture

Now that Debian 7 has been released (http://www.debian.org/News/2013/20130504) what is the Informal languageETA for TKL13 " actual " ? Yes, I am impatient... but also understand that it might still take some time...

Adam's picture

I have been using the TK13 core appliance with Hostapd, has been very stable so far! (I have also been regularly updating with apt).

Philoo's picture

I've been using the 64 bit image quite a lot for the past few weeks as a quick reset test system. Great job! Love it.

Only yesterday did it occur to me that I did not need to re-approve or the ssh key after a reinstall.  I've not looked into it closely (was like 10PM) and it is not too big a deal in my setup but I think this means the ssh server keys are copied from the squashfs  partition and not re-generated. 

This might be a bug or a feature but could you at least give a warning/reminder in the 1st boot script just before or after the admin password setup ?

Ed Carp's picture

This is awesome - both 32-bit and 64-bit support!  I run several versions of TKL on different server hardware, and it's nice to be able to run 64-bit versions and take advantage of 4+ GB of RAM, and at the same time run a 32-bit version on older hardware (the smallest machine I've got Core running on is an eMachines T1090 with 512MB of RAM and a 120 GB hard drive).

Feix's picture

turnkey-lamp-13.0-wheezy-i386 - manual partitioning not work!