From the project
Core & TKLDev v17.0 Stable Release & "preliminary" RPi3/4 builds
2022-05-17 Update: All affected appliances have now been bugfixed and rebuilt as v17.1. The v17.x release will continue, with all new appliances to be released as v17.1.
Important announcement: A serious bug has been discovered in v17.0. Everyone running v17.0 is advised to follow the directions as noted to fix the immediate bug. Due to this issue, the v17.0 release has been halted for now. v17.0 download links have been removed from appliance pages. Production will resume ASAP, first with the re-release of fixed v17.0 appliances; as v17.1. Then with the remainder of the library (all appliances will be v17.1 - including those not previously released as v17.0).
Also, please note that Raspberry Pi builds are NOT affected!
Update 2022-04-27: Please see the second instalment of the v17.0 release.
I'm excited to finally announce the stable release of Turnkey v17.0. It's been a bit of a slog, taking way longer than I had hoped and there are only two this time. Regardless, we've finally made it to the stable release milestone, at least for Core and TKLDev. Hopefully we can keep the momentum up and have more v17.0 appliances ready really soon!
In the meantime, these 2 new v17.0 appliances are published to our mirror network and are also available for download direct from their relevant appliance pages (app page links above, direct download links below) or launched directly from the Hub.
Finally, whilst I can't take any credit at all, I'm super excited that community member, Yannick has produced "preliminary" Raspberry Pi 3/4 builds! I've only just ordered mine, so I can do some testing and hopefully get "official" RPi builds released sometime soon. If you have an RPi3 or 4 (including '400'), please do download an image and give it a test drive. I'm sure that Yannick would welcome some feedback, considering all the hard work he has put in developing this from scratch! [edit: we've just realised that the image Yannick created supports both RPi3 & RPi4]
Downloads
Core (64bit / amd64 build): 339MB ISO ( changelog , hash file , manifest )
TKLDev (64bit / amd64 build): 419MB ISO ( changelog , hash file , manifest )
Changes of significance
As per previous TurnKey major version releases, the biggest change is the Debian version that this TurnKey release is based on. TurnKey 17.x release is based on Debian 11/Bullseye. As noted in the release candidate announcement the main changes have generally been at the software level, although much of the work will likely not be immediately obvious to an end user. Most of the python2 to python3 code updates occurred in v16.x, however, much of our build infrastructure (including tools in TKLDev) was still python2. So there has been some significant work on the tools in TKLDev (particularly fab and pool). In other instances, we have done some general software maintenance and implemented some bugfixes and/or code cleanup in our software.
Otherwise, we inherit the updated Debian packages. As per usual, upstream software will be refreshed (where relevant - neither of these apps include upstream third party software). There have also been a myriad of bug fixes applied and feature requests implemented. You can view the full changes that (will) apply to all v17.x appliances (to both these and the upcoming batches) via the Core v17.0 changes. The specific TKLDev changes are on top of that (shared changes common to all appliances are all noted in the Core changelog).
Beyond all the updated Debian goodness and custom TurnKey software improvements, v17.0 brings a new Webmin version (currently v1.990) and a number of changes with the intention of making TurnKey more IPv6 friendly (mostly thanks to community member, Richard van Dijk). We're not completely there yet (e.g. TurnKey's apt repo is STILL not available via IPv6) but at least there is some progress (FWIW, once v17.0 release is complete, I plan to focus on getting IPv6 working with our apt repo).
And to give it one more plug, (because I'm so excited about it) if you have a Raspberry Pi 4, please do go have a look at Yannick's RPi4 thread. Whilst it isn't (yet) official TurnKey, Yannick has been on and off involved with the TurnKey Community for a few years now and his efforts have been greatly appreciated. If you do give that a go, please be sure to post feedback on that thread. Even if everything works exactly as you expect, we'd love to hear that confirmed!
Launching from the Hub
For now, the Hub will still launch v16.x appliances by default (mostly because there are only 2 v17.0 app so far). At some point, once we get a few more loaded, we'll make v17.x the default (and eventually remove v15.x altogether). In the meantime, it's really easy to launch these 2 new apps (and the upcoming ones as they get added) in their v17.0 incarnation. You can click this link to launch a new v17.0 server. Otherwise, look for the "17.x" text link in the top right corner when logged into the Hub (just below "logout"):
Where are the other builds?
Due to the time it's taken to get to this point, we've decided to focus primarily on getting the appliances updated and released ASAP. As such, we'll only be publishing ISO and Hub (AWS EC2) builds initially. I know that this won't suit all of our users and we deeply apologise in anticipation. The rationale for this move is that the ISO build can be installed almost anywhere and the Hub builds provide our primary source of revenue (which keeps the lights on). Furthermore, with all appliances published as ISO, once we update and test the build code for other builds, pumping out the alternate build formats should be fairly straight forward. So focusing on the ISO and AWS EC2 builds first seems like a reasonable balance between what we'd ideally like (publish everything together) and giving the community the maximum value, at the soonest possible moment.
In the meantime, if you REALLY need/want a specific build, please feel free to share which one. I can't offer any guarantees, but at the very least, I'm more than happy to assist you testing to see if the existing code works (if it does, great - if it needs update, then we'll play it by ear).
Just to be clear, we do intend to publish other builds. I just can't give firm timeframe on when they'll be available. As I say above, if that doesn't suit you, feel free to share your feelings (although please keep it classy). If we get big enough pushback from you, then perhaps we'll need to reasses?
Stuff that didn't make it...
There are always tons of things I try to cram into a new release. I try to close as many issues as possible, focusing first on the bugs, but also trying to implement feature requests and make any other improvements we can along the way. Much of this work occurs behind the scenes and most community members probably have no idea of how much agonising occurs when it comes to deciding what to keep working on (trying to include), and what to leave until next time.
One of the bigger features I had hoped to include in v17.0 was UEFI boot/install (ISO) support. Unfortunately we ran out of time and I just can't hold v17.0 back any longer. I do hope to circle back to that at some point, as IMO it would make TurnKey more useful if it could be installed on newer hardware. I had also hoped to have the IPv6 apt repo ready for the v17.0 release. That won't make it either, but it doesn't actually doesn't depend on other stuff, so it's only a matter of waiting until I have a few spare cycles (haha I hear you say...).
It's perhaps also worth noting that TKLBAM is still python2 in v17.0. We have made some steps towards porting it to py3, but again we didn't want to hold up v17.0 any longer. Plus because TKLBAM is such a pivotal and important component, we can't afford to rush it and really do need to ensure that we test the heck out of it! The plan at this point is to pivot back to TKLBAM dev once v17.0 stable release is finished, and keep working on the update. Our current intention is to release "TKLBAM 2.0" within the lifetime of v17.x. Initially both TKLBAM & TKLBAM2 will be available side-by-side. Once we get to v18.0 (or perhaps before?) we will have TKLBAM2 only. Obviously the plan is open to changes, but I wanted to raise the curtain a little so you have some insight into our plans.
Please help test and give us your feedback
As per always, we'd be super happy if you gave these appliances a spin. Ideally, we'd love to hear how great they are. But obviously we'd also like to really hear of any issues you hit, any bugs we missed (or new ones we've introduced) or any other thoughts or feedback about v17.0.
If you aren't happy about no OVAs yet, features we're missing, or things we should have included but didn't, let us know! Obviously keep it respectful, but we always love feedback! :)
Comments (10)
v16 should still work ok, not sure about v17...
Reply 1Thanks Ian! :)
Reply 2Thanks tons Ian. LAMP should be in the next batch of builds we release.
To build LXC containers, have a look at the 'bt-container' script in buildtasks.
If you haven't used buildtasks before, the first thing to do is to create the config. For basic usage, you can use the default example:
cd buildtasks cp -R config.example config
Then run the script with the name and version of the appliance you want to convert to LXC. E.g.:
./bt-container core-17.0-bullseye-amd64
Note that by default it will try to download the "official" TurnKey ISO. If you want to build something that doesn't yet exist as an official ISO, then build an ISO first. The easy way is to use 'bt-iso' first. The harder (but quicker if you already have an ISO built) is to copy your ISO to /mnt/iso/ with an appropriate name (e.g. 'turnkey-my_app-17.0-bullseye-amd64.iso') and create the hash file via the 'bin/generate-signature' script. Then 'bt-container' will accept your ISO as a valid source for a LXC container.
tkl stable 17
Reply 3Successfully built Core in TKLDev without the workarounds from previous attempts so good to go
Also built Lamp with just the change to "main/plan" of python-mysqldb to python3-mysqldb.
initial testing seems to be working ok with Zenphoto and ResourceSpace. More testing to be done.
This is running ISOs. Any instructions for creating Proxmox templates?
Yep, A pity, but not a surprise
Reply 4It's a pity, but not really a surprise. Your testing demonstrates that there is some fundamental OS issue with our base LXC container build.
Have you tried entering the container via the host? I.e.:
pct VMID enter
Where VMID is the the ID number of your container. I suspect it won't work, but perhaps?
Excellent!
Reply 5Thanks so much for testing that. I'll need to do a bit more testing myself, but your feedback is invaluable. Hopefully I'll be able to at least publish a few soon.
Oops. My bad... And great work! :)
Reply 6I forgot that dpkg won't uninstall packages if other installed packages depend on them. TBH though, I'm not even sure why we were using dpkg and not apt in the first place?!
So I've updated the code to use apt instead now. It removes quite a few packages, but i don't think it will be a problem (fingers crossed). I did a quick build (of core v17.0) and it built fine this time. I also quickly tested the build on Proxmox and it seemed to be working well, although I only ssh'd in and had a quick poke around.
If you get a chance, it'd be great if you can test out the code now. If you're up for it, this should get you the latest code (that completely removes acpid):
cd buildtasks git stash git checkout fix-1636 git pull jeremy fix-1636
Great work Ian! That's super helpful!
Reply 7Great detective work Ian! Thanks for taking the time to look into this and even better that you managed to work out the issue and even developed a work around. Awesome! :)
To answer your question about how this could be included in the builds, there are a few different ways it could be done.
One would be to put the whole file into the relevant path within the container patch overlay. Just like in the build code, files in that directory are copied across, relative to root. I.e. if you put this file (including your changes) in buildtasks/patches/container/overlay/usr/lib/systemd/system/acpid.path, then it would overwrite the default. Having said that, you generally shouldn't edit files in /usr (with the exception of /usr/local; plus a few other specific exceptions). The main reason is that package updates may overwrite them. In the case of systemd, you can updated files in /etc (i.e. /etc/systemd/system/...) instead and they will override the default (in /usr/lib/systemd/system/...) but won't be overwritten by package updates.
Another perhaps even better way top achieve this for systemd unit files, is to just override the specific bit, rather than the whole file. Do that again in /etc, but this time create a dir and an override.conf file, rather than just the file. When you do that, you put the section header (i.e. the bit in square brackets) then just the line you want to add. E.g. creating the path and writing o the file via a docstring:
mkdir -p /etc/systemd/system/acpid.path.d cat > /etc/systemd/system/acpid.path.d/override.conf <>EOF [Unit] ConditionVirtualization=!container EOF
Possibly my favourite way to address this though is to just remove it (i.e. acpid) for the LXC builds.
Regardless, I've opened an issue to track this bug. As I noted, that whilst your fix certainly would work (it essentially stops the acpi daemon running when it's in a container), I think just removing it is the best way to go.
I have also opened a pull request that should fix it (and some other tweaks). It'd be fantastic if you could test it out. Here's how to load my updated code:
cd buildtasks git remote add jeremy https://github.com/JedMeister/buildtasks.git git fetch jeremy git stash git checkout fix-1636
That should "just work" and you should be able to build a v17.0 appliance with that bug resolved. If you can confirm that it fixes it and the container is working ok, I'm happy to merge it back into master (although I might get my colleague Stefan to also have a quick code review.
Please note that the 'git stash' command will hide away any files that you may have already edited. To get back to the default TurnKey code and recover the "stashed" files:
git checkout master git stash pop
Thanks heaps for helping out Ian!
Reply 8Great work Ian. Thanks again for helping out with testing and sharing your feedback.
In case you haven't already worked it out, the bt-... scripts (other than bt-iso) will first look for an ISO (and hash file) in /mnt/isos. If it doesn't find one, it will try to download from the TurnKey mirror. So if you want to do an alternate build of a custom appliance (or one that hasn't yet been published) you need to build to ISO first - using bt-iso. I.e.:
# this command will expect buildcode at /turnkey/fab/products/my_app_name ./bt-iso my_app_name # assuming success, iso should be saved to: /mnt/isos/turnkey-my_app_name-17.0-bullseye-amd64.iso # & this will build LXC: ./bt-container my_app_name-17.0-bullseye-amd64 # Note if /mnt/isos/turnkey-my_app_name-17.0-bullseye-amd64.iso doesn't exist, it will try to # download the iso from our mirror (and fail if not available)
As for what is going wrong with the new LXC templates, TBH, I'm not 100% sure. I'll try to have a quick look sometime soon, but I can't give any firm commitment.
Building LXC Container from ISO
Reply 9Figured out how to use bt-container with existing ISO. For TK17, needed to added bullseye to the list.
Used downloaded LAMP16.1 ISO to test and my own build of LAMP17.0 ISO. Process completed for both with no errors.
LAMP16 container worked as expected in Proxmox
LAMP17 container just hung using 100% CPU until forcibly shut down.
Thanks
Reply 10I installed it without any problem.
We haven't updated the bt-container script for v17 yet, so I'm not sure how that will go. But if you build for v16, it should "just work"! (note that you will want to make sure that you check out the '16.x' branch of both common and buildtasks).
And if you generate a v16.x ISO and ensure that it works properly as an ISO, then building your ISO to LXC (via bt-container) it should work.
Getting stuck at basic.target is a bit strange! Have you tried entering the container from the host (assuming Proxmox, via 'pct VMID enter')? Perhaps you can get in that way and see what is going wrong?