How could it be a decade ago if you have Ubuntu Jammy and virtualmin 7.10 ???
I have been running Virtualmin, on this machine, for as long as this machine has been in commission, which is about a decade. I have upgraded both the OS and Virtualmin regularly throughout itâs lifespan.
This is the first time that upgrade has failed, and failed despite doing everything weâre supposed to do, and failed repeatedly despite every advice.
Appreciate to be insulted while I was simply asking.
So you already did several update and not only 1, Ten years ago. Which is obviously not the same.
So when was the last update. And what did you do during it ? The problem might be here
The problem is that the key is not available, but still called out, and that none of the âofficialâ ways to fix it, actually fix it.
We understood there is a missing key. But you didnât answered to my question.
How can I guess what you did during the last update or whatever between it and today ??? If there was no problem before and suddenly you no longer have key ⊠Itâs rare an update wipe out it
So the question is what is requesting that key and where is it (the request) coming from. I would have thought that somewhere in a log that program is generating the error is there no trace of it?. where in the system is it getting the name of the key ? 3E570892B9A0B8B7 that obviously does not exist (perhaps never did)
1 Like
Itâs not that rare. I googled for the exact missing key and found quite a few people all having the same problem.
Every single one of them also received useless advice on how to fix it.
At any rate, I upgrade the way anyone on Ubuntu upgrades: to bump release, do-release-upgrade; run of the mill updates, apt update; apt upgrade. Nothing bizarre, nothing grotesque.
/m
Presumably, itâs getting added back every time I run setup-repos, since Iâve taken out all reference to virtualmin from my apt files to run setup-repos several times now, and it keeps coming back.
/m
You seems to like to be insulting. So I assume I can too.
As long as you give useless description and useless comment about what you did as the jerk you seem to be (And undoubtedly you are one). And contradict yourself between post. You will only get replies which canât fix anything.
Please Mod delete my post.
Everybody calm down, please.
This is a technical problem with a technical solution. Yelling at each other wonât help. I donât know why/how OP has metadata seemingly signed with the wrong key. Iâm pretty sure that isnât the key we sign the Virtualmin 7 repos with.
1 Like
You must have the public key that matches the key we use to sign our repos. That key can be found at https://software.virtualmin.com/lib/RPM-GPG-KEY-virtualmin-7
Thatâs the key that gets installed when you run the repo-setup, and itâs the key we use for signing our Virtualmin 7 repos.
When I look at this key with apt-key list (or using gpg directly), it looks like this:
pub rsa4096 2022-01-08 [SC] [expires: 2029-01-06]
586C 427B 9590 C1C4 35A5 FE39 3E57 0892 B9A0 B8B7
uid [ unknown] Virtualmin, Inc. (Package signing key for Virtualmin 7) <security@virtualmin.com>
sub rsa4096 2022-01-08 [E] [expires: 2029-01-06]
Do you have that key in the key ring apt is using?
If you do, then it seems like youâve somehow/somewhere got repo metadata that is signed with some other key than our Virtualmin 7 key, and I donât know how that would happen. I canât reproduce the problem; when I setup repos using the install script, it worksâŠit installs the right key, and apt update works without error. So, I honestly donât know whatâs happening on your system.
Maybe thereâs something cached. Try removing all mentions of virtualmin repos in sources.list and sources.list.d and then delete the entirety of the metadata in /var/lib/apt/lists (everything with virtualmin in the filename name). Then try using a current version of the install script with the --setup flag.
Also, whatâs the output of host software.virtualmin.com on your system?
apt-key list shows two possible keys for Virtualmin, and neither are the one you list:
pub dsa1024 2005-07-11 [SC]
31D2 B188 72EA F68E FB81 F81D E8DD 3FA0 A0BD BCF9
uid [ unknown] Virtualmin, Inc. <security@virtualmin.com>
sub elg2048 2005-07-11 [E]
and
pub rsa4096 2017-05-01 [SC] [expired: 2024-04-29]
E36F 0664 7D8E BD2B E364 2BCE D9F9 0107 60D6 2A6B
uid [ expired] Virtualmin, Inc. (Package signing key for Virtualmin 6) <security@virtualmin.com>
I had attempted that, before (hence, my frustration). I just did so again, with the same end result, quoted below.
sudo sh -c "$(curl -fsSL https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh)" -- --setup
[INFO] Log will be written to: /etc/apt/virtualmin-install.log
[INFO] Started Virtualmin 7 GPL software repositories setup
⣠Phase 1 of 1: Setup
Downloading Virtualmin 7 key â
Installing Virtualmin 7 key â
Downloading repository metadata [ERROR] Failed with error: 100
â
[ERROR] Something went wrong. Exiting.
[ERROR] The last few log entries were:
Hit:6 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:7 http://ppa.launchpad.net/ondrej/apache2/ubuntu jammy InRelease
Hit:8 http://ppa.launchpad.net/ondrej/php/ubuntu jammy InRelease
Get:9 http://security.ubuntu.com/ubuntu jammy-security InRelease [129 kB]
Get:10 https://esm.ubuntu.com/infra/ubuntu jammy-infra-security InRelease [7,450 B]
Get:11 https://esm.ubuntu.com/infra/ubuntu jammy-infra-updates InRelease [7,449 B]
Get:12 https://software.virtualmin.com/vm/7/gpl/apt virtualmin InRelease [10.7 kB]
Err:12 https://software.virtualmin.com/vm/7/gpl/apt virtualmin InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3E570892B9A0B8B7
Reading package lists...
W: GPG error: https://software.virtualmin.com/vm/7/gpl/apt virtualmin InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3E570892B9A0B8B7
E: The repository 'https://software.virtualmin.com/vm/7/gpl/apt virtualmin InRelease' is not signed.
Downloading repository metadata: [2024-09-12 12:56:54 CDT] [ERROR] Failed with error: 100
[2024-09-12 12:56:54 CDT] [ERROR] Something went wrong. Exiting.
[2024-09-12 12:56:54 CDT] [ERROR] The last few log entries were:
(to be clear, there were no âlast few log entriesâ listed â thatâs where output ends).
Investigating further, the line that gets added to virtualmin.list by --setup is:
deb [signed-by=/usr/share/keyrings/ubuntu-virtualmin-7.gpg] https://software.virtualmin.com/vm/7/gpl/apt virtualmin main
root@bee:/etc/apt# apt-key list
However, the output of apt-key does not seem to know about that file.
Running gpg --list-keys --keyring /usr/share/keyrings/ubuntu-virtualmin-7.gpg does turn up the key you suggested.
/usr/share/keyrings/ubuntu-virtualmin-7.gpg
-------------------------------------------
pub rsa4096 2022-01-08 [SC] [expires: 2029-01-06]
586C427B9590C1C435A5FE393E570892B9A0B8B7
uid [ unknown] Virtualmin, Inc. (Package signing key for Virtualmin 7) <security@virtualmin.com>
sub rsa4096 2022-01-08 [E] [expires: 2029-01-06]
On the surface, even if apt-key doesnât know about the âcorrectâ file, apt/apt-get ought to, since itâs being called out explicitly in the configured line. However, that still doesnât feel like it would solve our problem, since the âcorrectâ key is not the one apt is even looking for. Itâs looking for 3E570892B9A0B8B7. from virtualmin-install.log:
2024-09-12 12:56:44 URL:https://software.virtualmin.com/lib/RPM-GPG-KEY-virtualmin-7 [3212/3212] -> "RPM-GPG-KEY-virtualmin-7" [1]
Downloading Virtualmin 7 key: Success.
Spin pid is: 36017
gpg: key 3E570892B9A0B8B7: "Virtualmin, Inc. (Package signing key for Virtualmin 7) <security@virtualmin.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
So thatâs even the key it keeps retrieving and then somehow insisting it does not have!
root@bee:/etc/apt# host software.virtualmin.com
software.virtualmin.com has address 51.158.66.131
Add that key and remove the old keys.
apt-key add /usr/share/keyrings/ubuntu-virtualmin-7.gpg
And, use apt-key del to remove the old keys. Then do apt clean and apt update.
The good news: the old keys are now gone.
The bad news: it doesnât change anything. apt clean and apt update yield the same results:
root@bee:/home/mikey# apt clean
root@bee:/home/mikey# apt update
Hit:1 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy InRelease
Hit:2 [https://repos.insights.digitalocean.com/apt/do-agent](https://repos.insights.digitalocean.com/apt/do-agent) main InRelease
Hit:3 [https://repos-droplet.digitalocean.com/apt/droplet-agent](https://repos-droplet.digitalocean.com/apt/droplet-agent) main InRelease
Get:4 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy-updates InRelease [128 kB]
Hit:5 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy-backports InRelease
Get:6 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) jammy-security InRelease [129 kB]
Hit:7 [http://ppa.launchpad.net/ondrej/apache2/ubuntu](http://ppa.launchpad.net/ondrej/apache2/ubuntu) jammy InRelease
Hit:8 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) jammy InRelease
Hit:9 [http://ppa.launchpad.net/ondrej/php/ubuntu](http://ppa.launchpad.net/ondrej/php/ubuntu) jammy InRelease
Get:10 [https://software.virtualmin.com/vm/7/gpl/apt](https://software.virtualmin.com/vm/7/gpl/apt) virtualmin InRelease [10.7 kB]
Get:11 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy-updates/main i386 Packages [690 kB]
Get:12 [https://esm.ubuntu.com/infra/ubuntu](https://esm.ubuntu.com/infra/ubuntu) jammy-infra-security InRelease [7,450 B]
Get:13 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy-updates/main amd64 Packages [1,988 kB]
Get:14 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy-updates/universe i386 Packages [731 kB]
Get:15 [https://esm.ubuntu.com/infra/ubuntu](https://esm.ubuntu.com/infra/ubuntu) jammy-infra-updates InRelease [7,449 B]
Get:16 [http://mirrors.digitalocean.com/ubuntu](http://mirrors.digitalocean.com/ubuntu) jammy-updates/universe amd64 Packages [1,123 kB]
Err:10 [https://software.virtualmin.com/vm/7/gpl/apt](https://software.virtualmin.com/vm/7/gpl/apt) virtualmin InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3E570892B9A0B8B7
Reading package lists... Done
W: GPG error: [https://software.virtualmin.com/vm/7/gpl/apt](https://software.virtualmin.com/vm/7/gpl/apt) virtualmin InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3E570892B9A0B8B7
E: The repository '[https://software.virtualmin.com/vm/7/gpl/apt](https://software.virtualmin.com/vm/7/gpl/apt) virtualmin InRelease' is not signed.
Does apt-key list show the new Virtualmin key?
Yes.
pub rsa4096 2022-01-08 [SC] [expires: 2029-01-06]
586C 427B 9590 C1C4 35A5 FE39 3E57 0892 B9A0 B8B7
uid [ unknown] Virtualmin, Inc. (Package signing key for Virtualmin 7) <security@virtualmin.com>
sub rsa4096 2022-01-08 [E] [expires: 2029-01-06]
Iâm baffled.
Has there been some change in the kinds of keys apt accepts, and old upgraded systems need a configuration change or something to make them work with modern keys? That doesnât seem right, as RSA keys have been around for a long time, and what weâve always used, but maybe the newer longer key is a problem. The only instance of this exact problem happening in the past was also with an upgraded systemâŠso, that seems to be the common thread, but I canât seem to google up any explanation for it (but I donât know how to search for this).
Well, at least itâs not just me! 
If there had been, I would have expected do-release-upgrade to do whatever magic was necessary, there. Ubuntuâs usually pretty good about making sure do-release-upgrade is all you need.
Unless Jammyâs out of date with respect to gpg itself? That seems unlikely, but how many people in the world are using the longer keys, yet?