Installing on a fresh copy of Almalinux 9.1 and failed with with:
Downloading Virtualmin 7 release package: Success.
error: package is not installed
Spin pid is: 124156
warning: virtualmin-pro-release.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID b9a0b8b7: NOKEY
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-webmin: key 1 import failed.
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin-7: key 1 import failed.
Installing Virtualmin 7 release package: Success.
Installing dependencies and system packages: Success.
Spin pid is: 135570
The GPG keys listed for the "Virtualmin 7 Professional - noarch" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing package is: usermin-1.860-1.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin-7
Error: GPG check FAILED
Installing Virtualmin 7 and all related packages: [2023-01-16 05:37:30 EST] [ERROR] Failed with error: 1
Same issue for me, I’m on AlmaLinux 8.7. Even tried switching to CentOS 7 but no luck.
These are my virtualmin install logs:
Installing dependencies and system packages: Success.
Spin pid is: 63362
The GPG keys listed for the "Virtualmin 7 GPL - noarch" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing package is: usermin-1.860-1.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin-7
Error: GPG check FAILED
Installing Virtualmin 7 and all related packages: [2023-01-16 06:11:06 EST] [ERROR] Failed with error: 1
[2023-01-16 06:11:06 EST] [ERROR] Something went wrong. Exiting.
[2023-01-16 06:11:06 EST] [ERROR] The last few log entries were:
I don’t understand what either of those code sections have to do with the original problem?
I believe the bits in the first code section indicate dnf/rpm was already running so it couldn’t get a lock…nothing to do with checking the signature of a package.
And, the package that had the wrong signature was usermin, not virtualmin-config.
The problem with usermin should be fixed.
You should be able to run dnf clean all and proceed with the install from there. I don’t understand why you’d run it with -s? I thought you were trying to do an install…
um neither do I. It occurred at the same time the first (two, i had an install fail last night as well with the same result) times and I didn’t know if it was connected or ok or not…that’s why I asked. Like I said already had to start over and reinstall os, didn’t want to hit go and do it all over again.
It failed because of it…?
Yes. I checked the keys for both repos I just didn’t copy and paste everything here.
I tried clean all among other things last night and it didn’t work and I had to reinstall.
As for the -s, because it seemed prudent…? Now that I know that will cause it to fail that far in why not have that go first and catch any issues before changes have already begun?
Also not sure if this is intended behavior but when I ran with -s it installed a number of packages rather than just setting up repos.
There are some dependencies that the install script itself needs that are always installed, if missing. wget or curl or fetch, Perl, gpg, and we update ca-certificates (because old ca-certificates package can make our repos inaccessible since they run over TLS with a Let’s Encrypt cert).
There are two independent problems being discussed.
The first, usermin being signed with the wrong key, the reason this thread was started, has been fixed.
Your later issue, when you ran with the -s flag, you already had rpm running and so it was locked and no rpm actions could happen. We can’t really control that, but it means you have rpm running in another session or a scheduled job was running it, maybe an automated update process, I don’t know. It could also mean rpm didn’t exit cleanly and left a lock in place, for some reason. You may need to remove the lock file manually in that case, though I seem to recall it gets cleaned up automatically in some cases.
I guess we could detect a lock and try to wait for it. It’s not an issue that has ever come up, that I can recall, though…