Do you love TurnKey? Have a few spare cycles and want to help out?

Excellent, glad to hear that worked.

FWIW, it would be awesome to work out what is required to get TKLDev running in a container, but it isn't a current priority for us. If you do turn back to that at some point, please do share.

Thanks too for confirming that the Core LXC/Proxmox build works on your setup. That's a solid start. Now we know that works, it'd be good to check out some of the more complex appliances. Note that at this point, I would recommend avoiding our VPN apps and the Domain Controller.

In specific answer to your questions:

I assume you will let us know when 17.1 is available for building from?

I will publish a blog post about it, plus will cross post links elsewhere (including updating blog posts like this one). So hopefully you should get notified.

What specifically are you looking for when we build something? Errors during the build? Warnings during the build? Errors/warnings when the container is installed and run? I know I saw a warning or two during the build I did. I don't know whether they're 'normal' so you might get some reports that aren't necessary, but I guess that's part of the learning process! I won't report what I saw, I'll wait to see if they still occur in v17.1 and report them then if they do.

Showstopping errors during build are the first thing to address. All critical errors will halt the build process. In the case of the Proxmox/LXC builds, we've already passed that point. I haven't even tried any of the other builds, so I have no idea what shape they are in.

Once you have the build completing successfully, it is worth having a quick look over the build output. As you noted, there will likely be some warnings during the build process. Most (if not all) of them are likely not really an issue, but it's worth double checking. It's especially important to note new warnings during a transition (i.e. moving to a newer Debian base - like we are for v17.x). Hence why documenting these would be useful for future people such as yourself.

The next step is to ensure that the build actually works. Again we've somewhat got to that point with the Proxmox/LXC builds. At least for Core. For what it's worth, initially they just locked up. But we've worked that issue out (and now remove acpid - which was causing the lockup).

Regardless, because it's still somewhat new, the more reports the better (even if that's just "works for me too"). There have been plenty of times that things work fine for me, but others experience issues. So the more people testing, the better the chance that we can find (and fix) any issues before release.

In the case of Core, I've personally only tested logging in via SSH and had a quick poke around. I checked resource usage (via htop - top is installed by default, but htop is better and can be installed via 'apt install -y htop') as well as quickly scanning the journal ('journalctl'). Within an unprivileged LXC instance, there'll likely be warnings and many (hopefully all) may be expected. But again, if you're not sure, they're often worth a look (or just report them so myself &/or others can).

Again documenting these would be a good idea. Also FWIW, from my quick tests, both Webshell and Webmin appeared to work ok, and I also briefly checked that our custom services and scripts (such as inithooks (firstboot scripts) and confconsole) appeared ok. Once these common components are confirmed working in Core, the need to devote too much more time to further testing these in other appliances is generally not required. Although many appliances have custom inithooks, so I always check /var/log/inithooks.log looking for any scripts that exit with a non-zero exit code (usually 'exit 1').

From there, as noted above, we need to test more complex appliances, that include different software and services. In the case of web apps, I will often check the main app via my web browser, enable "developer tools" and check for any 404 or javascript errors. (Again some are ok, like 404 for favicon.ico - others not!). As you're likely aware, a few of our appliances don't play nice in an unprivileged LXC instance. As noted, ones that come to mind are our VPN apps and our Domain Controller. About 70% of our appliances are based on LAMP, so testing a few of our webapps is pretty important. To be explicit, we do fairly simple "smoke tests" on all the ISO builds. So in theory, any general "showstopper" bugs you find should be specific to Proxmox/LXC build. Although maybe you've spotted something that we've missed?

As far as reporting goes, it's much better to get a report that doesn't matter, than not get a report when it is an issue! As with many tech related issues, there is generally never such a thing as too much information! Whilst it's hard to explicitly tell you want to report and what not too, if you report stuff that isn't important, I'll likely be able to filter that out pretty easy. But I can't read your mind to get more info about things you don't share! :)

Again, it's probably a good idea to document any specific warnings that aren't a problem. This could be an opportunity to start that process? We could then even consider suppressing or at least contextualising them in the future perhaps?!

As you learn more, you'll likely get better at knowing what's important to report and what specifically relevant info to share. But even then, I still tend to be fairly verbose when reporting issues. Actually, in my experience, just the process of sharing info can often lead to insights. If I had a dollar for everytime I've been able to resolve an issue myself, simply by going through the process of carefully and exhaustively documenting what is occurring - I'd be a wealthy man! :) Bottom line, please don't hold back on what you share.

Is there any documentation that describes the build process? I'm clearly not an expert in building containers, but it would be interesting (yes I have a strange mind!) to understand the process better which might allow me to find the causes of errors/warnings and maybe even fixes for them.

There is a ton of documentation on the build process but unfortunately, it's not been well maintained, nor is it organised all that well. Most of it relates to the appliance build code (i.e. building appliances from scratch to ISO). So may not be that directly relevant to you in this scenario. If you do have a read of any of that and notice any issues, anything that doesn't make sense, or doesn't match what you see, please do not hesitate to ask and/or report any issues or areas for improvement.

Unfortunately, there isn't much documentation specific to the "alternate" or "optimized" builds - as provided by buildtasks. The build scripts are mostly just bash (with a few python scripts within bin). They may look a bit intimidating if you're not familiar with bash, but they're actually relatively straight forward. They're more-or-less just a list of commands to run, with some control logic (which could, at least in theory, just be copy/pasted straight into the command line).

In the the case of most of the bt scripts, here's the basic flow of what they do:

• unpack the iso and extract the root filesystem
• remove and/or install specific packages
• tweak config as relevant (much of it via "patches" - which are just bash scripts and/or files to overlay)
• cleanup to remove any remaining cruft
• pack updated root filesystem into relevant package/container - e.g. bt-container compresses to a tar ball ready to be used on Proxmox

I hope that provides some insight and value. If you have further questions, etc. Please ask.

Thanks again for helping out. Just having people such as yourself engaging and interested in learning and helping out is like fuel for us!