No worries on quick response, although it looks like it didn't actually bring any value...

Also out of interest, after a closer look at your OP, it appears that gpg found the relevant keys, but couldn't find any user data attached?! That's all a bit weird...!? I'll need to investigate at some point...

As I hinted in my quick response earlier, for v16.x (Buster based) we've rotated our key(s). However, we've gone further than that this time and now have separate keys for each repo (buster, buster-security & buster-testing). There is also a new (separate key) for image signing too... Mvoing forward we'll be generating 4 new keys for each major TurnKey release. But that'll probably be a little while away...

Beyond my silly Ubuntu keyserver typo, I think that the issue is that the key IDs that apt is complaining about are the key IDs, but for some reason it's not getting the key ID info unless you load via the full fingerprint?! TBH, I'm not at all sure why it doesn't work as I'd expect, but anyway hopefully I have a workaround. Please see below the fingerprints of the 4 new keys (and their associated email addresses, which correspond to the relevant purpose) as you can likely see; the first 3 are the repo keys:

release-buster-main@turnkeylinux.org
421EBF52305747499EA106B3EF81D7D8EE49B5E5
release-buster-security@turnkeylinux.org
F96FA43E5996BC2CED4CA6E7E3A68C7D36ED4595
release-buster-testing@turnkeylinux.org
5EFDC34B1D948E749003297CEE9FBD11ADE6FE8E
release-buster-images@turnkeylinux.org
A8B2EF4287819B03D3516CCA76231C20425E9772

If you use GPG with these fingerprints via the Ubuntu keyserver, they should work ok... FWIW, I just tested like this and it worked for me?!:

gpg --no-default-keyring --keyring ./test.gpg --keyserver keyserver.ubuntu.com \
     --recv-keys 421EBF52305747499EA106B3EF81D7D8EE49B5E5

Which output:

gpg: key EF81D7D8EE49B5E5: public key "TurnKey GNU/Linux Buster Main apt repo (GPG signing key for TurnKey Linux Buster Main apt repository) " imported
gpg: Total number processed: 1
gpg:               imported: 1

(If you note the key ID, you can see that's actually the same key that it tried to import when you ran: "gpg --recv-keys 1C7082DDE779614F"?! But this time it has the full info so the import suceeds...)

FWIW if I now list the keys, like this:

gpg --no-default-keyring --keyring ./test.gpg --keyid-format LONG \
     --fingerprint 421EBF52305747499EA106B3EF81D7D8EE49B5E5

I get this:

pub   rsa4096/EF81D7D8EE49B5E5 2020-02-05 [SC] [expires: 2040-01-31]
      Key fingerprint = 421E BF52 3057 4749 9EA1  06B3 EF81 D7D8 EE49 B5E5
uid                 [ unknown] TurnKey GNU/Linux Buster Main apt repo (GPG signing key for TurnKey Linux Buster Main apt repository) 
sub   rsa4096/1C7082DDE779614F 2020-02-05 [S] [expires: 2040-01-31]

TBH, I'm still not sure why it doesn't "just work" using the key IDs that apt complains about. It sounds like I might need to look into that a bit closer... But at least that should get you going...

It's also worth noting that I have now uploaded the v16.0 packages to buster-testing, so if you want to have a play with those and see how they work for you, then the buster-testing repo sources.list line is:

deb http://archive.turnkeylinux.org/debian buster-testing main

Please note that best practice for adding repos dictates that the keyfiles (i.e. .gpg files) should NOT just be dumped in /etc/apt/trusted.d, but instead should be put somewhere else, the developing convention appears to be /usr/share/keyrings so that's where we'll be putting them. So here's how to add the buster-testing key and repo entry:

KEY_FILE=/usr/share/keyrings/tkl-buster-testing.gpg
gpg --no-default-keyring --keyring $KEY_FILE --keyserver keyserver.ubuntu.com \
    --recv-keys 5EFDC34B1D948E749003297CEE9FBD11ADE6FE8E
echo "deb [signed-by=$KEY_FILE] http://archive.turnkeylinux.org/debian buster-testing main" \
    > /etc/apt/sources.list.d/tkl-buster-testing.list

So now, the tkl-buster-testing.list will only authenticate against the /usr/share/keyrings/tkl-buster-testing.gpg file. No other repos can be authenticated against that key either... If/when you wish to disable the buster-testing repo, simply rename the file:

mv /etc/apt/sources.list.d/tkl-buster-testing.list /etc/apt/sources.list.d/tkl-buster-testing.list.disabled

Hopefully that all works and if you do test out any of the new packages, I'd love to hear some feedback.

Thanks for the additional info.

Ah, bugger, re the turnkey-sysinfo error! I probably should have anticipated that... In v16.0, we've made some quite radical updates to much of our software (part of he reason why the v16.x release is so far behind schedule...).

And one big change is that turnkey-version and turnkey-sysinfo have been merged into a single package (they have common dependencies and so I decided to just bundle them all together in a single package). I did generate a "transition" package (i.e. just an empty package) for turnkey-version so the upgrade wouldn't fail, but it completely escaped me that it would still cause issues...

So I may need to rethink my previous plan. What I may do instead is pull out the common dependency into it's own (3rd) package and move turnkey-sysinfo and turnkey-version back into their own packages?! Anyway, I'll have a bit of a think about it and see how we go...

If you wish to install the updated package (i.e. just 'turnkey-sysinfo') it looks like you may need to manually uninstall turnkey-version. But please be aware, that as I say, I may well move turnkey-version back to it's own package... So I'd actually recommend that you hold off on that, perhaps until early next week? Feel free to ask if therre's been any progress on that front (I'll try to post back if there is, but often a bump is useful for me! :)

If you have any other feedback regarding any of the other updates, please share. Especially if you have any weird experiences or notice any bugs. We did a fair bit of internal testing, but they've only been on clean installs, we've done no substantive testing on v15.x appliances that have been upgraded.

I've just uploaded new packages of turnkey-version and turnkey-sysinfo which should fix your previous errors. Please feel free to give them a go! Hopefully you should be all good...

Although I note that unless you just left them as they were (i.e. if you applied a workaround previously), they may not install nicely now... Let me know if you have any issues and I'll help you fix things up.

Firstly, thanks so much for testing that out.

I think that we're all good now. The initial (new) error you've posted appears to essentially just be the reverse of the original error. I.e. before this most recent change, it was complaining that turnkey-sysinfo included the same file as the old turnkey-version. But as soon as it upgraded to the "new" turnkey-sysinfo (which no longer contains that file) then it can install the "new" turnkey-version package.

FWIW, I just pulled the 2 packages apart again (as they were previously). I was trying to be clever and bundle them together, but it seems clear now that was a bad idea...

Seeing your output though has triggered a chain of thoughts. I need to do some further consideration....

Firstly, I see the new di-live installing. FWIW that was a lot of work...! I've ported the core to python3 and rebased most of the rest back on current Debian source code (don't ask what it was...!). Now it's no issue to have installed, but also, it has no value other than initial install from ISO. So FWIW it's actually not needed on an installed system at all. In v16.0 ISOs it will cleaned off the new system before initial reboot. So you should be able to safely remove it if you wish (i.e. "apt remove di-live").

However, there is another package that we were building ourselves (busybox-initramfs) which is quite important. The significant changes I've made in di-live mean we no longer need to build that package and can instead just install a (very similar) default Debian package instead (busybox). However, for users such as yourself, that won't happen automagically. In the short term it's no real issue as busybox-initramfs from stretch (i.e. v15.x) will continue to provide the required functionality. However, I suspect that at some point in the future, that may not be the case and something may break. So it is something that I will need to look at further. I have some ideas, but I'll need to do some testing...

FWIW I've opened an issue re doing a Debian style "in-place" upgrade and explicitly noted 'busybox-initramfs' so it doesn't get forgotten.

Further to my original 3 paragraphs in that issue, I've since realised, that you should actually have the (new-for-turnkey Debian) busybox package installed (and thus added a 4th paragraph - see the paragraph that starts "[update]"). So I suspect that you have both busybox and busybox-initramfs installed! To confirm, please run the following:

apt policy busybox*

FWIW as noted (in "[update#2]") a local v15.0 VM I have running also has both installed... So TBH, I'm not really sure what is going on, it definitely requires some further investigation. But on the upside, it does appear that having both installed shouldn't cause issues. I'll do some testing ASAP and see how things go when doing an in-place upgrade on a v15.x server myself...

If you care to share some logs, that might be useful for me. You'll need to either copy paste them, or attach them to your original post (only the 1st post in a thread can have attachments). Although if you'd rather email them to me direct, that's also fine (jeremy AT turnkeylinux.org). The logfiles that would be good are in /var/log/apt/ namely term.log & history.log. Probably just those will do, but perhaps check the date of one the most recent rotated ones to see if they're worth also including. I.e.:

# ls -l /var/log/apt/history.log.1.gz
-rw-r--r-- 1 root root 1879 Jan 25 00:59 /var/log/apt/history.log.1.gz

(The date of this file shows that my /var/log/apt/history.log file covers the period Jan 25th 1am until now). I hope that all makes sense?!

Also apologies on the whole "stream of consciousness" rambling in this post... As you can see, I had a lot going on in my head as I was writing! :) I haven't gone back to try to make this more concise as this post has soaked up lots of time (not that I grudge that at all - actually I really appreciate the thoughts, ideas and considerations that it's provoked). I really can't justify spending more time tidying it up. Hope it makes some sense to you though...! :)

Great thanks for that. I really appreciate your feedback. I hope to push these new packages to "buster main" any day now. So having been able to hear about your experience has been invaluable. FWIW once I push them to buster main, then everyone who has done an upgrade to buster will mostly likely get them next time they do an apt upgrade. So it's kind of important...! :)

Thanks too for sending those log files. I've got them and have had a quick browse. I'll have a closer look at them ASAP. I may have some further questions, but I doubt it.

Really appreciate all the feedback and understanding. Thanks for being such a solid human! :) I think we're on the final stretch for the v16.0RC release...

Best practice dictates that specific keyrings should be used for specific repos. That ensures that each repo is only signed by it's own key and no other from the general/combined keyring (and blocks some potential pathways to install malicious packages). So TurnKey only includes the official Debian keys in the default apt keyring. TurnKey keys are kept in separate keyrings:

• TurnKey Buster security keyring: /usr/share/keyrings/tkl-buster-security.gpg
• TurnKey Buster main keyring: /usr/share/keyrings/tkl-buster-main.gpg
• (Optional) TurnKey Buster testing keyring: /usr/share/keyrings/tkl-buster-main.gpg

FWIW you can see those keyring locations within the apt sources.list files. I.e.:

# grep -r keyring /etc/apt/sources.list*
/etc/apt/sources.list.d/turnkey-testing.list:deb [signed-by=/usr/share/keyrings/tkl-buster-testing.gpg] http://archive.turnkeylinux.org/debian buster-testing main
/etc/apt/sources.list.d/sources.list:deb [signed-by=/usr/share/keyrings/tkl-buster-main.gpg] http://archive.turnkeylinux.org/debian buster main
/etc/apt/sources.list.d/security.sources.list:deb [signed-by=/usr/share/keyrings/tkl-buster-security.gpg] http://archive.turnkeylinux.org/debian buster-security main

(I've got the TurnKey testing repo enabled...)

So to download the keys to the relevant keyring, use the keyring switch with 'apt-key':

apt-key --keyring /usr/share/keyrings/tkl-buster-main.gpg adv --keyserver keyserver.ubuntu.com --recv-keys 1C7082DDE779614F

Note that the '--keyring' switch must come straight after the 'apt-key' command! Otherwise it will say that it worked, but won't actually write it to the /usr/share/keyrings/tkl-buster-main.gpg keyring file.

I hope that helps.