No, the key was generated in 2022. Jammy was the current version then, and we have something like 75,000 active installs on Ubuntu versions from 20.04 through 24.04. This key definitely works with Jammy (and Focal and Noble).
Legit. That also makes sense, since the keyring ACCEPTED the key. Both apt-key and gpg --list-keys --keyring ... show the key and donāt complain about it at all.
But apt itself simply balks at it.
ETA: For funzies, I also went old-school and used apt-get instead of just apt. Same result.
Itās a known, tricky, intermittent issue on Ubuntu thatās not directly tied to Virtualmin but affects many users.
Please refer to this thread:
If you will read uptopic, you will see that I have already gone through the steps outlined in that thread, which are also the steps recommended to me separately, here, and that exactly none of them made any difference.
Just for fun though, I went through the suggestion from that thread:
ALTERNATE METHOD:
sudo gpg --keyserver pgpkeys.mit.edu --recv-key <PUBKEY>
sudo gpg -a --export <PUBKEY> | sudo apt-key add -
sudo apt-get update
With the following result on the first command:
root@bee:/home/mikey# sudo gpg --keyserver pgpkeys.mit.edu --recv-key 3E570892B9A0B8B7
gpg: keyserver receive failed: No data
We havenāt published our key to pcpkeys.mit.edu. That canāt possibly do anything.
Since we are grasping at straws, force a reinstall of apt?
I wouldnāt have thought so, either, but @Ilia seemed to think I should try it, so I tried it!
Removedā¦ Sorry I anticipated to help out.
As you can see above, I am root when I am executing these commands.
If apt were failing for anything else, Iād think that might help, but all the other repos apt is pulling from work fine. I can update Ubuntuās own packages without an issue, and in fact just did so a short while ago.
Removedā¦ Sorry I anticipated to help out.
I have been administering Unix and Unix-like systems for 35 years. I have never once, in all that time since sudo came into existence at all, heard of anything at all where sudo -s behaved different from logging in as root.
Nevertheless, since we are, as @ID10T points out, down to grasping at straws, I tried logging in as root, and running virtualmin setup-repos again.
It made no difference whatsoever.
Since you know it all with that attitudeā¦ Like I saidā¦ Best of luck!
Look, folks.
There are two broad possibilities.
Either apt has a bug, or Virtualminās repo has a problem.
Since nothing else is broken, only virtualminās repo; and itās consistently broken no matter what remedy I apply, including getting rid of every possible reference to it and reinstalling with Virtualminās own installer scriptā¦that makes it seem to me that itās Virtualminās problem.
I note that someone else in this community had this same problem all the way back in April, and the only answer was shifting the blame to the installer for a ācreativeā installation and insisting he would not have had this problem if heād just followed the instructions.
Well, Iāve followed the instructions, and itās still broken.
Iām not trying to argue with you about it. I just donāt know whatās wrong. I canāt reproduce it, Iāve tried, and Iām still trying to figure out what could be going wrong.
The only theory I have is that thereās something about apt configuration on systems that have been upgraded from a quite old version of Ubuntu (ten years would be trusty, maybe?). So far I havenāt found confirmation of that, but thatās the best theory I have, since both people who have reported the problem were on systems that had been upgraded, rather than a fresh install.
Iām not criticizing anything youāve done, nor am I saying this is your fault.
@Joe I appreciate that. And L-rd knows Iāve been in your shoes enough times, since Iām also a software engineer by day, and sometimes, systems just getā¦weird.
The only theory I have is that thereās something about apt configuration on systems that have been upgraded from a quite old version of Ubuntu (ten years would be trusty, maybe?).
That theory holds water. I actually just delved into the dropletās āhistoryā page, which strangely does not include a specific date, but does confirm it was created 10 years ago, which was honestly just a ballpark when I first mentioned it. The services the system is running date back further than that ā I ran a small webhosting business that went from hosted-at-home (frac-T1 to the house of all things) to colo to Digital Ocean. The system in question is the remaining rump of that business, just a handful of vhosts for friends and a couple of things of my own.
Iām not sure what to look for to fix itāthereās been nothing glaring when I looked at /etc/aptās config filesābut itās close to the last sensible thing we have left!
My point was that maybe some configuration got left, so forcing a complete reinstall might help. I canāt do a large upgrade without pauses making sure I know the consequences of something or having it offer me an option to keep a configuration or go with the packagers new version.
Time to start a fresh on a new box - perhaps?
It canāt, as long as we believe the Virtualmin key is the real issue. Again, I know that apt thinks it is, but it could be a bug. However, I have no solid evidence to support this.
Was this system upgraded from 20.04 or 18.04? And were the upgrades done in consecutive years or one after the other a few days ago?
Ten years ago would be starting with 12.04 or 14.04.