Apologies that things aren't moving as fast as any of us would like. I'd like to give you a little insight into what still lays in front of us here at TurnKey and some more thoughts on PHP, WordPress and plugin compatibility. I'll also note your options as I see them in the final section below. I wanted to provide the full depth of my understanding, as much for others who may be in your situation as for you. Please feel free to skip straight to that last section if you're in a rush...

Where we're at

Things haven't gone as fast as I would have liked. We're still probably at least a week or 2 out from a v16.0 WordPress appliance (possibly a little more if things don't go as smoothly as I anticipate). Things are definitely moving in the right direction though. Just yesterday I published a blog post announcing the release of Core v16.0rc1.

FYI, our next steps will be to ensure that all the other build targets (besides ISO) are building and working ok. Hopefully, things don't require too many significant changes and it all goes smoothly and quickly. During the time I'm working on that, hopefully lots of TurnKey users battle test Core (and TKLDev, and even assist with getting other appliances ready for publishing) to ensure that the basis of our new release is all good.

Once I have all the additional builds working, and have resolved any issues that may have cropped up from testing of the RC, then we'll move to publishing appliances. The plan will be to publish them in batches of around 10 (or more) at a time, as they're ready. As you might expect, Core and TKLDev will be in that first batch. I also intend to include LAMP and a number of our most popular LAMP based appliances, including WordPress in that first batch.

Round up of your current situation

So from what I understand, you are currently using a TurnKey v14.x appliance. That only provides PHP v5.6.40. Considering 5.6 has been EOL (end of life) upstream (i.e. the PHP developers) for over a year now, plus significant performance gains were introduced with PHP 7.0, I completely understand many WordPress plugin developers dropping support for that. Although it's perhaps worth noting that despite WordPress recommending PHP 7.3, the WordPress "requirements" page explicitly notes that the minimum requirement is PHP 5.6.20 (or higher). So if there is incompatibility with PHP 5.6, it's the plugins that you are using, not WordPress itself.

We haven't explicitly noted it in our previous discussions, but TurnKey v15.x provides PHP 7.0.33. Out of interest, I just did a quick random survey of a few popular WordPress plugins, and all the ones I checked support PHP 5.6+ (so implicitly also support 7.0). Although it was hardly scientific and as I noted above, I can understand plugin devs dropping support for older PHP. I'm sure that some smaller, less popular and less well resourced plugin providers have made the commercial decision to drop support for older EOL PHP versions (PHP upstream only support PHP v7.2+ currently). As something of an aside (and perhaps irrelevant to you), Debian 9/Stretch (the basis of TurnKey v15.x) will continue to provide backported security patches for PHP 7.0 (automatically installed by TurnKey's auto sec updates) until at least June 2022 and most likely well beyond.

So as I noted in my initial post in this thread, whilst v16.0 will be optimal, v15.x would still be of benefit. And depending on the specific plugins that you are using, might even be enough to meet your immediate needs (obviously this will depend on the individual plugins you are using). I guess if you are using plugins developed inhouse though, then that may be a different matter?!

Some more thoughts on compatibility

Personally, I'd be asking your web people for a comprehensive list of what minimum version of PHP each plugin actually needs. If I were you, I'd also be asking for confirmed max WordPress version compatibility of each plugin too. FWIW I noticed in my above (random and unscientific) check of popular WordPress plugins, that a couple weren't actually confirmed as working with the latest version of WordPress (they may still work ok, or perhaps not). So there's a (possibly slim, if your web people are onto it) chance that may also be a factor in your woes?

Bottom line is that it may well be the case that one or 2 (or perhaps more?) might actually require PHP 7.3. But it's quite possible that may only be a recommendation and 7.0 may be enough to meet minimum requirements (in which case moving to v15.x for now may be sufficient).

If you definitely need PHP 7.3 - Now!

If you definitely need PHP 7.3 right now and can't wait, then you could upgrade to v15.x and install PHP 7.3 - as per Jose's forum tutorial. The guy that provides the 3rd party deb.sury.org PHP repo (Ondřej Surý) is one of the Debian (and Ubuntu) PHP package maintainers, so he knows his stuff and is trustworthy. The downside though, is that you'll no longer get automated security updates for PHP. Also, he doesn't guarantee support for a particular PHP version beyond upstream EOL (as Debian does) - although it sounds like that's unlikely to be a concern for you.

Another option would be to upgrade to v15.x and then do a Debian "in place" upgrade from the Debian 9/Stretch base to a Debian 10/Buster base (what v16.x will be based on). I can't 100% guarantee that will work smoothly and everything will be ok (although TBH, I would expect that it would). You could even do that from your current install, although you can't skip a release (i.e. you'd need to go 8/Jessie to 9/Stretch, then to 10/Buster).

Note that if you do take the "in place" upgrade path, you will have something of a hybrid. All the packages will be updated, but some tweaks made by us will be overwritten by changes as you upgrade. Other additional tweaks that we provide (at build time) you won't get. So whilst it will be close to v16.x, a system upgraded like that won't be exactly the same as a v16.x server.

Sorry that it was a bit long... Regardless, I hope that it helps.

Yeah it's so close I can almost taste it... Just a last few little pieces I need to get in place and I'll start publishing stable appliances. I hate to make promises when I don't control all the variables, but I'm really hoping to be start releasing this week...

FWIW I'm just finalising the webserver security config...

As per my response to Brian a minute ago, the first batch should be ready early next week. I didn't explicitly note it in that post, but WordPress will be in that first batch.

A 3+ yo instance is really old! I assume that is probably a v14.2 instance (with PHP 5.6)?! The new upcoming one will be v16.0. Given that is a jump from 2 major versions ago, I'm not 100% sure how an automated data migration will go. But I'm open to give you a hand (here via the forums for free; or one-on-one if you're open to paying) to migrate your data with TKLBAM if you are interested. I can run some tests, but to actually be able to be involved with a "real world" migration would be quite interesting and could give me some further insight to assist with this.

Assuming nothing (else) goes wrong, then LAMP (and WordPress, OTRS and a few others) should definitely be published this week.

LEMP, I'm not 100% sure on just yet. No one has looked at that one, but once we get the first batch done, we should be able to get most of the others out pretty quick. As you've explicitly noted/requested it, I'll try to ensure that it gets some priority (and it should be pretty easy anyway). Regardless, hopefully it shouldn't be too far away.

I'll aim to post here when they're actually published, so if you get email notifications of posts to this thread you'll get a notification. And/or I intend to send out a "newsletter" email noting the first stable appliance release which you should get if you are subscribed to the TurnKey "newsletter" (if you're unsure, please log in, go to your user profile and check your current subscriptions.

Re Zurmo, yes we'll definately be updating it, but I'm not sure when. Although now that you've noted it, I'll try to get it into the next batch.

Which format are you after Brian?

Regardless, at this stage we will probably look to build a number of other formats at least for Core and wait for feedback before we proceed. That's be because we don't have direct access to the different platforms to test. If you have access to one of those platforms, perhaps you could assist with testing?

FWIW I did start pushing Docker builds to the Docker Hub, but then noticed some weirdness, so I hope to have a closer look at those and may redo what I have pushed already.

Although until we have the whole library done, the main focus will continue to be pushing out the updated appliances in ISO, LXC and for the Hub. I plan to publish at least 10 apps per week.

I'll have to have a look at Confconsole code re that error ASAP. I'm sure that I've personally tested setting a static IP and don't recall hitting that?! Hopefully I can recreate it, if not, I might have some more questions for you. Regardless, I'll have a look and get back to you ASAP.

When you say "VMware 6.5", are you're referring to "VMware vSphere/ESXi 6.5"? If so, could you please share the explicit release/build number? If you're not sure how, this VMWare doc seems to cover it. If you'd rather not share that detail publicly, then please feel free to email that to me (jeremy AT turnkeylinux.org).

Re the ISO install, generally, you should be able to just accept all the defaults. Although now you mention it, I do recall that my VMware tests had issues automatically determining where to install grub to. I'll revisit that and at least document it.

Re OVA, we have just published Core v16.0 as OVA (I haven't announced it yet). I don't have access to vSphere/ESXi so I'm hoping that we can get a bit of community testing before I start rolling it out. Would you mind giving that a quick test drive and see if it works for you?

I haven't been able to reproduce this issue?! I've also tested in a VMware Player (v15.5) VM too, just in case it's something that only shows up in VMware, but I couldn't get it to occur there either?! Unfortunately, I don't have ESXi/vSphere or Windows, so reproducing your environment is not currently possible.

While trying to reproduce this issue, I tried every combination of characters that I could imagine but beyond finding another (different) bug in Confconsole (some python2 code we missed when porting to python3), I haven't been able to reproduce this issue. Beyond that particular bug (caused by a valid IP address from a different subnet to the gateway IP), all other things that I tried produced an "Invalid IP" error, rather than a crash and a stacktrace as yours did. I guess that's something (finding a bug we'd previously missed) but it's not really helping me resolve this specific issue you're hitting... :(

Do you recall anything in particular that you did when that error occurred? If you still have the WordPress appliance running, could you please try again? This time note exactly what buttons you press.

The only thing that I can think of is perhaps the VMware interface passes through the exact Windows key codes to Confconsole and that upsets it? FWIW in Linux, the "Enter" key returns a single "newline" or "linefeed" character (aka 'LF' - aka ASCII character code 10 - aka '\n'); whereas "Enter" on Windows returns 2 characters, a "newline", but also a "carriage return" character (aka 'CR' - aka ASCII char code 13 - aka '\r' - i.e. together; 'CRLF' or '\n\r'). In other words, Linux assumes that a new line always starts at the far left, whereas Windows doesn't. TBH I'm not convinced that is the cause as I would have expected it to have caused an issue sooner, rather than just in this particular place. But I can't think of any other reason why it would happen?!

One way that you could test if that's the issue if you want is when trying to change the IP to static, instead of using the "Enter" key to select "Ok", instead hit the "Space" key. You will probably need to use the "Tab" key to move the cursor from the IP text input box, to the "<Ok>" button, then hit "Space" to select the highlighted option.

Regardless, I'll get my colleague (who is much more of a Python expert than me) to look into it first thing Monday. Hopefully he'll be able to see what the issue might be. If you have anything to add before then (e.g. try with the space key instead as noted above), I'd love to hear.

PS - I've opened an issue for this.

Ok, so we're fairly sure we've worked out the direct cause for the Confconsole crash (and the stacktrace). So we'll make Confconsole a bit more robust and provide a more useful error message, rather than just crash.

However, we're still not sure why the scenario that caused Confconsole to crash in the first place occurred (i.e. even once we improve Confconsole, the underlying cause will still exist). I have a suspicion what might have caused it, but I'm going to do some testing before I say too much more.

You can see more details/discussion on the issue.

Thanks heaps for the extra info Brian.

I just posted re Zurmo above (sorry I missed that post earlier).

Thanks for your further info re your experience with the ISO on VMware. It only seems to occur on VMware, so I'm not really sure why that is?! I'll definitely double check that some more and at the very least open an issue and note how to make it work, so then at least it'll be documented.

Re your note about it asking again for the '"wordpress" login user and password in the console', I assume that it was terminal log in prompt? (I.e. log in for the server with a hostname of "wordpress" as the 'root' user and the root password you set on firstboot)?! I probably didn't elaborate enough on the inithooks/confconsole changes in the release blog post, but I did note it in a comment if you're interested?

I still haven't had a change to look into the Confconsole static IP stuff yet, but I'll get to that shortly.

Hi Brian,

Could you please double check the updated Core OVA and confirm if it now works for you? I'm feeling pretty confident that it will, but the previous one passed all my tests too though, so fingers crossed...

If you hit any more issues, please report back ASAP with as much info as possible. If I can get a confirmed working Core OVA by COB Friday, then I should be able to have a WordPress OVA for you early next week.

---

The rest of this post relates to the networking issue you hit when you installed the ISO. We have done some investigations and discovered the underlying issue. Unfortunately it runs much deeper than I might have liked. On the upside, it actually seems to be fairly rare (unfortunately VMware does seem to be particular fragile - not sure why). I still need to do a little more testing before we decide on the exact path forward.

Without more specific info on the networking config you used, we're still not 100% sure exactly what went wrong in your case. But our testing to date reveals that in Debian Buster (the base of v16.x) the minimalist Debian DHCP client we're using (udhcpc) does have some race condition with the network config. Under some circumstance, it fails to configure network routing information. Confconsole should handle that scenario ok (although networking wouldn't work), but it was failing when trying to set a static IP if the routing info was missing.

So whilst we've improved Confconsole's handling of the underlying issue(s), including error reporting; we haven't found a satisfactory way to resolve the underlying race condition (when it occurs). Luckily it seems pretty uncommon, although as I said, unfortunately, VMware does seem to be a particularly fragile platform. I'm fairly certain that it may also occur on other platforms, but without manually removing the routing info, I've been unable to reproduce it on other VM platforms such as KVM or VirtualBox. We did put some time into trying to see if we could automate retrying to get routing info on failure, but that became a bit of a rabbit hole. So we've backed out until we can get more info about the specific circumstance when users hit that. Another pathway may be to test an alternate DHCP client.

Please download and test this OVA:

http://download.jeremydavis.org/turnkey-wordpress-16.0-buster-amd64.ova

Note: this (same) WordPress OVA is now available from the mirror. The below hashes should still apply; or the signed hash file can also be downloaded from the mirror. (Those links are the same as the ones on the WordPress appliance page.)

Also here's the hashes:

sha256sum:

a1779e10aff41b8c28e34418ae2a334c83fae6bfa805e0d8d335eda895279fba  turnkey-wordpress-16.0-buster-amd64.ova

sha512sum:

416451c70e49c4f9da1ea44b4e92aae0899f708eb1ad506512ab067f6a99d1ba01702d94b194a40152c4d159d8bee038d66fdfabb54a6e63a24ed1e7f77ec2c5  turnkey-wordpress-16.0-buster-amd64.ova

Please let me know how that goes.

If it's still no good, them please let me know with as much detail re what doesn't work (with screenshots if possible) and I'll try again. Assuming I can work thought whatever issues may come up, I should be able to get another updated image up within 24 hours.

If it works (fingers crossed), you can continue using it if you wish. Alternatively, you can wait for the "official" one to be published to our mirror by early next week. Note that unless you tell me it's no good and we try again, this image will literally be identical to the one that we publish next week. I built this OVA on the TurnKey build infrastructure, just I uploaded it to a bucket in my personal AWS account (mapped to my domain) before my colleague Alon signed and published it to the TurnKey mirror (as I think I may have mentioned, I don't have the release key).

So it looks like your server still has some networking issues?! On face value, these screenshots suggest to me that your server can't access the configured DNS server?! I.e. the nameserver you set in the networking config is either wrong, or unreachable.

Obviously you could start Confconsole again and use that to check/retry configuring the nameserver, but I think you might be best to stay on the commandline to diagnose this. That way we can rule out Confconsole as part of the issue. To check what nameserver is configured and if it's actually made it into the configuration in use:

First check the interfaces file (this is what Confconsole should be editing):

cat /etc/network/interfaces

Then what the system is actually using (this is configured dynamically, from the info in the interfaces file):

cat /etc/resolv.conf

FYI, here's the output from those commands on a system I have running that is working (actually the 192.168.1.5 nameserver doesn't exist, I just added that while I was testing, but as it only treats the second address as a fallback if the first doesn't respond, it doesn't matter in my case):

root@tkldev4 ~# cat /etc/network/interfaces
# UNCONFIGURED INTERFACES
# remove the above line if you edit this file

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.1.154
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1 192.168.1.5

root@tkldev4 ~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
nameserver 192.168.1.5
options timeout:1

Now to test, I'm going to use ping to test those nameserver IPs. It's not conclusive as the nameserver may be configured to not respond to incoming ICMP packets (i.e. ignore ping) but it's worth a shot IMO. And assuming that you are using the same nameserver for other VMs then if you get no response here, you can double check from another one that is working.

root@tkldev4 ~# ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=20.8 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.428 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.419 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.489 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 43ms
rtt min/avg/max/mdev = 0.419/5.529/20.780/8.805 ms
root@tkldev4 ~# ping -c 4 192.168.1.5  
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
From 192.168.1.154 icmp_seq=1 Destination Host Unreachable
From 192.168.1.154 icmp_seq=2 Destination Host Unreachable
From 192.168.1.154 icmp_seq=3 Destination Host Unreachable
From 192.168.1.154 icmp_seq=4 Destination Host Unreachable

--- 192.168.1.5 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 54ms
pipe 4

So in my case, 192.168.1.1 works fine (it's my local router provding gateway, DHCP & DNS - which forwards queries to the outside world). But 192.168.1.5 doesn't respond (no surprise as it doesn't exist).

I'd be inclined to check the settings of one of your other (working) servers and double check:

1. That the nameserver IP is correct.
2. That the netmask is correct.
3. And if both of those are consistent, that the nameserver can be pinged.

If the netmask and nameserver IP are the same on both old and new servers, and the nameserver responds to ping on the old server, but not the new; then you still have networking issues. Assuming that the static IP you've set is a routable address within the network, then my guess is that it's some networking/routing issue outside of the new VM. Perhaps something within VMware? Or perhaps in your broader network?!

Thanks for this note. I've opened an issue and we'll add those to the next release. Once you have the nameserver/networking issue sorted out on the server, then as noted on the issue, installing and enabling these should be pretty simple:

apt update
apt install php-zip php-imagick -y
systemctl restart apache2

FWIW, I just loaded this WordPress OVA into VMware Player (v15.5) and ran though these commands. It definitely removed that note and I couldn't see any other issues (at least not ones that make sense for us to do anything about IMO). So other than your DNS issues, it appears we may nearly be there for the initial OVA.

---

Also, outgoing networking is clearly working ok with this the new server! Otherwise you wouldn't have been able to access this WordPress page. I'm also assuming that WordPress is probably also reporting some other issues here too? As it wouldn't be able to resolve addresses via DNS either?! If it is, perhaps retry the previous apt commands? If it works now, that's great although I have no idea why it started working?!

Ok, glad that the outgoing network issue was an easy fix! :)

---

Re the security updates, it's worth noting that the WordPress ISO was built nearly a month ago now. And the OVA is essentially a repackaging of the ISO. Ideally we try to keep them as close as we can and under normal circumstances, they would be built at the same time, so it would rarely be an issue. We've made something of an exception in an effort to resolve the issues that you've noted. And considering the OVA build lag, perhaps you're right and we should be installing these security updates at build time?! Actually, I might just do that...

---

Thanks for the feedback on those messages. We'll have to consider exactly what we do there. On reflection, I can see how they may be confusing, however, it's worth keeping in mind that by my understanding, your scenario (i.e. a network without a DHCP server) is not that common.

So in most cases, not having that base information (as automatically provided by DHCP) often correlates with network problems of some sort. So whilst I'm sure we could improve the message, I think that it might be wise to provide some note that we couldn't get DHCP info?! If you have any further thoughts on a message that conveys that info without being confusing, I'd be keen to hear.

---

When you say:

I still don't understand why this can't boot cleanly into your menu. I have to hit just the right keystrokes to get it to display correctly, otherwise I end up at the command prompt. I think you will have people freaking about that. It appears "broken".

I assume you're referring to the 3 Webmin stopped/starting/started messages polluting the console in your screenshot?

If so, does it only occur on firstboot? Or on all boots? Is it only ever those exact messages (i.e. those 3 stopped/starting/started Webmin messages)? Or is it sometimes other messages? After you clear it, does it occur again later? Or only when you reboot?

FWIW, in general unfortunately, that's been something of an issue since v14.x to a greater or lesser degree. It got worse in v15.x as systemd got better at starting services asynchronously. I did put a fair bit of time into trying to improve it for v16.0 and mostly IMO it is better than it was (both in v15.x and when I first started working on v16.0 - late last year). But short of suppressing all service messages (leaving just a blank black screen) I couldn't completely eliminate it. The messages give a sense of stuff happening and can be really useful for noticing and diagnosing issues so I'm loathe to suppress them.

If it is only Webmin, then perhaps there is something we can do specifically for that that we can improve? Regardless though, unless it's something specific to Webmin, I think we'e past the point of diminishing returns regarding stopping pollution of the console with late messages...

---

Re the php modules, yes as per the issue I posted earlier, they should be included in future WordPress appliance releases.

TBH, I'm not sure why you had to fiddle with networking. The OVA should "just work"?!

Although it may be an issue between our config and your older VMware version? We've had some reports about networking issues with our v15.x VMs when upgrading VMware software. So we've erred on leaning towards the slightly newer virtual hardware for the v16.x release (it should "just work" on anything which VMware still lists as "supported" - note v12 "end of general support" was March 2019). TBH, trying to support the huge array of VMware software and versions can be a challenge...

Re your LXC question, technically it should already be available. And in theory it should work. But I'm not so sure in practice. Perhaps try specifying version '16.0' and see what happens? If you have issues getting the v16.0 WordPress LXC to work, probably best to start a new thread. :)

As a general rule, I would avoid updating PHP unless you actually need to. FWIW you should expect WordPress and most plugins to support PHP7.3 for about a year and a half at least (when "official" PHP 7.3 security support ends). However, even beyond then, PHP 7.3 (as installed on TurnKey from Debian repos) will continue to get backported security updates from the Debian Security team until July 2022 (and then from the LTS team until June 2024) - see Debian wiki. WordPress itself should continue to work fine with PHP 7.3 indefinitely, although some plugins (especially smaller ones and/or less popular ones) may require newer PHP versions.

WordPress is known for supporting really old versions of PHP, so it's highly unlikely that you need a newer version of PHP for WordPress itself. Although as I hinted above, some plugins may drop support for versions of PHP unsupported by PHP themselves. So I would recommend doing some research whether any of the plugins that you use actually need a newer version (TBH, I'd be surprised if they do).

Regardless, it's your server. So if you really do want to update PHP (or you really do need it) then it's completely possible. You can install it via Ondřej Surý's third party PHP apt repository. He's a Debian Developer and a member of the PHP packaging team, so it a trusted source. The instructions on how to do that are noted in the README.txt within the repo.

However, it's worth keeping in mind that if you don't actually need PHP7.4, then you are better off sticking with PHP7.3 as provided by the default Debian repos. Because of the way that Debian manages security, we can safely configure TurnKey to auto install security updates. If you update to PHP7.4, then there is no longer a distinction between feature updates and security updates (all updates update to the latest version where security bugs are patched, but new feature bugs may be introduced). So automated updates are not recommended. That means that you will need to manually check for and install updates (via apt).

Re the systemd messages on the console. If you wish to disable them by editing /etc/systemd/journald.conf and uncommenting (i.e. remove teh '#' from the start) of this line:

#ForwardToWall=yes

Then change the 'yes' to 'no'. SO you end up with a line that looks like this:

ForwardToWall=no

PS apologies on such a slow response...

We are currently working on v17.0 - which will include PHP7.4. Hopefully it will be released within the next few months. I hope to have an RC (release candidate) of Core within the next week or 2.

Having said that, PHP v8.0 is out already, so it will only be a few months before WordPress will start whinging about that instead... And then within another few months, v8.1 etc, etc. Once TurnKey v17.0 is released (with PHP7.4) it will likely be 2+ years before a newer PHP version will be included by default.

So you'll need to decide how you want to proceed.

If you want to follow WordPress's lead, then you can install the latest PHP from a third party. One of the lead PHP maintainers/packagers for Debian and Ubuntu maintains a PHP repository that I trust and works well. The downside of that is that you won't get automated security updates and will need to maintain that yourself. You could work around that by including the 3rd party repo in the daily updates, but each update is a new version, so there is always the risk of new bugs being introduced too.

OTOH, you could just use the default PHP and ignore the WordPress PHP version message(s) for now. Even though they recommend PHP 7.4, WordPress itself still supports PHP 5.6 so it's certainly far from a hard requirement. Debian supports the OS included PHP version with carefully crafted backported security patches. Even though upstream support for PHP 7.3 ends 1 Jan 2022, Debian (10/Buster) will continue to support the included PHP 7.3 until at least June, 2024 (and almost certainly longer).

Having said all that, where PHP version usually becomes an issue, is not with WordPress itself, but the plugins that you are using. The plugins too will require specific PHP version(s) and often their requirements are more limited than WordPress's. That can go both ways. E.g. a plugin maintainer might not have yet updated it to support a newer PHP version. Or they may drop support for an older PHP version (much) sooner than WordPress itself does. So the PHP version for plugins does matter! So you'll need to check what PHP version your plugins require.

Bottom line is that unless you need to update PHP version, I personally would hold off until we release v17.0. As I noted, that will include PHP 7.4 and will hopefully be available within the next couple of months. I'm more than happy to assist you to migrate your data. After that, when it starts nagging about PHP 8.0, you can decide which way to go from there.

For waht it's worth, I do hope to include a tool to easily change PHP versions in TurnKey. I started development of it quite some time ago, but hopefully it will be ready to include in v17.0. If not, I will release it ASAP.