Great work! Looks like you've nailed the issue to the tkldev-setup script not being able to verify the bootstrap. I've opened an issue on the tracker for that. I'll make that a priority as that will cause us issues...
TKLDev issue
To answer your question re the importance of the issue, I guess it doesn't really matter, as manually setting up those repos resolves the issue. However, IMO it's an issue well worth fixing ASAP for a few reasons:
The bootstrap isn't being verified. I guess it's fairly unlikely that someone malicious is distributing a hacked bootstrap which includes malware, but I think it's best to be sure!
I don't think that a buggy setup really inspires confidence in TurnKey as an appliance building framework. Obviously bugs happen in all software, but the less the better - and to hit one so quickly is far from ideal...
The learning curve for the uninitiated might already feel a bit steep. Hitting an issue like this so early in the process might be just enough to scare a new comer off.
And perhaps most importantly from our perspective, we use TKLDev ourselves to build all the appliances. When we do a build run, we do that on a clean instance of TKLDev. So requiring manual intervention to build an appliance is a deal breaker!
MySQL/MariaDB background
For the benefit of anyone reading this post, some background and context should probably be noted. First up, it should be explicitly noted, that as of v15.0, TurnKey provides MariaDB, rather than actual MySQL. MariaDB is a MySQL fork, which is intended as a "drop in MySQL replacement". It was created by the original developer/founder of MySQL, along with many of the MySQL dev team who jumped ship when Oracle bought out Sun (who owned MySQL). You can red more about the history on Wikipedia.
As of 9/Stretch Debian have removed MySQL completely and provide MariaDB instead. We (in TurnKey v15.x) followed Debian's lead, who in turn are following the lead of other Linux distros such as Red Hat, and use the terms "MySQL" and "MariaDB" interchangeably (so all the old MySQL commands work, but you're actually using MariaDB).
Just to confuse things, Ubuntu haven't followed that lead of other Linux distros and provide both MariaDB and MySQL packages as clear and distinct software options (as it seems you are aware). It's well worth keeping that in the back of your mind if applying an Ubuntu tutorial to TurnKey - as Ubuntu is based on Debian, often Ubuntu tutorials are relevant, but unlike Ubuntu, TurnKey is 100% binary compatible with Debian. It's perhaps also worth noting, that whilst MariaDB is a drop in replacement for MySQL, once you start using MariaDB, it's not guaranteed that you can go back to MySQL. That is because MariaDB contains additional features which MySQL (at least the free open source version) doesn't support. If you're interested, you can read more about MariaDB <--> MySQL compatibility. Anyway, from here on in I'll continue to use the terms "MariaDB" and "MySQL" interchangeably (and to specifically refer to MariaDB as included in TurnKey).
MariaDB/MySQL root user with no password
So to get back to your concern re no password. The change to use of 'unix_socket' (aka 'auth_socket') authentication for the root MySQL user account (as opposed to 'password' authentication) became the default for MariaDB v10.4.3+. FWIW my reading suggests that it is also the default for MySQL v5.7+ too.
Whilst on face value, not having a password for the root user account may seem like a huge concern, IMO it's actually a security improvement! It's been the Debian default since the introduction of MariaDB in 9/Stretch. TurnKey followed suit and kept that default in v15.0 onwards.
It sounds like your research has given you a bit of an understanding of it, but let me explain how it works. In Debian prior to 9/Stretch (& TurnKey prior to v15.0), a password was used to authenticate the root MySQL user via a network connection. In TurnKey as an additional security measure, the root account was locked to localhost.
However since Debian 9/Stretch (& TurnKey v15.0); a unix socket is used instead. A unix socket is sort of like a special file. This socket is owned by the relevant Linux user (so in this case, it's owned by the root Linux user). This means that only the root (Linux user) user can access the root MySQL user account, thus limiting access to the specific user. Another feature of unix sockets is that they are only available via localhost (you can't ever authenticate via a unix socket remotely; unless via a method such as SSH where you are essentially accessing localhost via a secure remote connection). The theory is, that the security & authentication mechanism for the root Linux user login should be sufficient to stop unauthorised access to the localhost system, and therefore the root MySQL account.
I would argue that's a legitimate assumption to make. If someone untrusted has root access to your server, then access to MySQL DBs is probably the least of your problems!
Another factor is that many additional system functionalities of MySQL require root access. E.g. starting/stopping the MySQL service, rotating the MySQL logs, cron jobs/maintenance scripts which compress, cleanup and/or otherwise optimise your DBs, etc. The way that was resolved previously was via a special "root equivalent" system user account (named "debian-sys-maint"). However, that user had it's password stored within /etc in plain text! Whilst this has historically been somewhat common practice (using file permissions to ensure that only the root user has read access to this plain text password) in more recent times, it's been recognised as a potential security weakness and most apps are moving away from that model. AFAIK, newer MySQL releases support storage of encrypted passwords (so no more plain text), but 'unix_socket' authentication is generally considered superior.
MySQL password set on firstboot & final words
The MySQL password you are asked to set on TurnKey LAMP (and LAMP based appliances) firstboot is for the "adminer" MySQL user account. That is a root like user too (so you can do DB administration via Adminer) but as it's available via a web interface, it requires a password.
I can't really speak to why Ubuntu have chosen to do things differently. As I noted above, AFAIK use of socket authentication is the default for both MariaDB v10.4.3+ & MySQL v5.7+. FWIW the MySQL v8.0 docs (under "Socket Peer-Credential Authentication") note:
[...] auth_socket authentication is well suited to server administration user accounts for which access must be tightly restricted.
Great work! Looks like you've nailed it!
Great work! Looks like you've nailed the issue to the tkldev-setup script not being able to verify the bootstrap. I've opened an issue on the tracker for that. I'll make that a priority as that will cause us issues...
TKLDev issue
To answer your question re the importance of the issue, I guess it doesn't really matter, as manually setting up those repos resolves the issue. However, IMO it's an issue well worth fixing ASAP for a few reasons:
MySQL/MariaDB background
For the benefit of anyone reading this post, some background and context should probably be noted. First up, it should be explicitly noted, that as of v15.0, TurnKey provides MariaDB, rather than actual MySQL. MariaDB is a MySQL fork, which is intended as a "drop in MySQL replacement". It was created by the original developer/founder of MySQL, along with many of the MySQL dev team who jumped ship when Oracle bought out Sun (who owned MySQL). You can red more about the history on Wikipedia.
As of 9/Stretch Debian have removed MySQL completely and provide MariaDB instead. We (in TurnKey v15.x) followed Debian's lead, who in turn are following the lead of other Linux distros such as Red Hat, and use the terms "MySQL" and "MariaDB" interchangeably (so all the old MySQL commands work, but you're actually using MariaDB).
Just to confuse things, Ubuntu haven't followed that lead of other Linux distros and provide both MariaDB and MySQL packages as clear and distinct software options (as it seems you are aware). It's well worth keeping that in the back of your mind if applying an Ubuntu tutorial to TurnKey - as Ubuntu is based on Debian, often Ubuntu tutorials are relevant, but unlike Ubuntu, TurnKey is 100% binary compatible with Debian. It's perhaps also worth noting, that whilst MariaDB is a drop in replacement for MySQL, once you start using MariaDB, it's not guaranteed that you can go back to MySQL. That is because MariaDB contains additional features which MySQL (at least the free open source version) doesn't support. If you're interested, you can read more about MariaDB <--> MySQL compatibility. Anyway, from here on in I'll continue to use the terms "MariaDB" and "MySQL" interchangeably (and to specifically refer to MariaDB as included in TurnKey).
MariaDB/MySQL root user with no password
So to get back to your concern re no password. The change to use of 'unix_socket' (aka 'auth_socket') authentication for the root MySQL user account (as opposed to 'password' authentication) became the default for MariaDB v10.4.3+. FWIW my reading suggests that it is also the default for MySQL v5.7+ too.
Whilst on face value, not having a password for the root user account may seem like a huge concern, IMO it's actually a security improvement! It's been the Debian default since the introduction of MariaDB in 9/Stretch. TurnKey followed suit and kept that default in v15.0 onwards.
It sounds like your research has given you a bit of an understanding of it, but let me explain how it works. In Debian prior to 9/Stretch (& TurnKey prior to v15.0), a password was used to authenticate the root MySQL user via a network connection. In TurnKey as an additional security measure, the root account was locked to localhost.
However since Debian 9/Stretch (& TurnKey v15.0); a unix socket is used instead. A unix socket is sort of like a special file. This socket is owned by the relevant Linux user (so in this case, it's owned by the root Linux user). This means that only the root (Linux user) user can access the root MySQL user account, thus limiting access to the specific user. Another feature of unix sockets is that they are only available via localhost (you can't ever authenticate via a unix socket remotely; unless via a method such as SSH where you are essentially accessing localhost via a secure remote connection). The theory is, that the security & authentication mechanism for the root Linux user login should be sufficient to stop unauthorised access to the localhost system, and therefore the root MySQL account.
I would argue that's a legitimate assumption to make. If someone untrusted has root access to your server, then access to MySQL DBs is probably the least of your problems!
Another factor is that many additional system functionalities of MySQL require root access. E.g. starting/stopping the MySQL service, rotating the MySQL logs, cron jobs/maintenance scripts which compress, cleanup and/or otherwise optimise your DBs, etc. The way that was resolved previously was via a special "root equivalent" system user account (named "debian-sys-maint"). However, that user had it's password stored within /etc in plain text! Whilst this has historically been somewhat common practice (using file permissions to ensure that only the root user has read access to this plain text password) in more recent times, it's been recognised as a potential security weakness and most apps are moving away from that model. AFAIK, newer MySQL releases support storage of encrypted passwords (so no more plain text), but 'unix_socket' authentication is generally considered superior.
MySQL password set on firstboot & final words
The MySQL password you are asked to set on TurnKey LAMP (and LAMP based appliances) firstboot is for the "adminer" MySQL user account. That is a root like user too (so you can do DB administration via Adminer) but as it's available via a web interface, it requires a password.
I can't really speak to why Ubuntu have chosen to do things differently. As I noted above, AFAIK use of socket authentication is the default for both MariaDB v10.4.3+ & MySQL v5.7+. FWIW the MySQL v8.0 docs (under "Socket Peer-Credential Authentication") note:
I hope that sets your mind at ease...