Cockpit Software Update referencing local directory tree I did not declare as repos

Rocky Linux General
1

I migrated my core system from CentOS 7 to Rocky Linux 8.5. I did a clean install on new media and then pulled in my legacy data volumes. My core server is a KVM host and also hosts repos over my LAN for the various OS versions my KVM guest systems use. Overall, the migration was quite successful, but I do have a problem with the Cockpit feature that looked to be a good thing to use. The problem is with the Software Update function.

Software Update complains about pending update while there are none. When I try to apply all, I get this very odd complaint:

Applying updates failed
package atk-2.28.1-2.el7.x86_64 cannot be verified and repo media-2 is GPG enabled: /var/www/html/CentOS-7.8.2003/x86_64/Everything/Packages/atk-2.28.1-2.el7.x86_64.rpm could not be verified. /var/www/html/CentOS-7.8.2003/x86_64/Everything/Packages/atk-2.28.1-2.el7.x86_64.rpm:: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY: Header DSA signature: NOTFOUND: Header SHA1 digest: OK: V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY: DSA signature: NOTFOUND: MD5 digest: OK

So there are a bunch of problems here. None of my repos defined in /etc/yum.repos.d reference media-2 as a repo. What appears to have happened is that the system picked up on my local directory structure for the repos i serve to other systems and figured it would reference them for this Rocky Linux 8.5 system.

How can I stop this?

I cannot find any file that defines this as a repo. (I am assuming there are similar media and media-1 repo definitions somewhere that also need to be stamped out”

2

So, you get nothing with:

grep -rE "var|www|CentOS" /etc/yum.repos.d

Overall, there should be no “CentOS-7.8.2003” at all, CL7 repos are now 7.9.2009.

3

Correct. No matches.

I carry on my server repos for CentOS 7.8 and 7.9 as well as Rocky Linux 8.4 and 8.5.

When I attempt operations in Cockpit for updates, i discovered there is a set of messages in /var/log/messages:

Dec 27 12:15:38 wort journal[49826]: Skipping refresh of media: Cannot update read-only repo
Dec 27 12:15:38 wort journal[49826]: Skipping refresh of media-1: Cannot update read-only repo
Dec 27 12:15:38 wort journal[49826]: Skipping refresh of media-3: Cannot update read-only repo
Dec 27 12:15:38 wort journal[49826]: Skipping refresh of media-5: Cannot update read-only repo

A further clue is that the mystery repo (media-2 and probably the rest) appear to have been picked up from loop mounts of the ISOs for the various versions I have support for in my environment. The loop mounts allow me to do network installs for new VMs i create inside my KVM environment.

4

One should be able to clean out the 7.8 and 8.4, because there is no need for them now that we have 7.9 and 8.5. Only the latest versions have any support.

I have a faint recollection that you can select an ISO in libvirt/KVM; no need for loop mounts.

Cockpit … seen, but never used. What do you get with:
dnf repolist
(and is that different in the host vs the guests)

5

What a nightmare! Good news is that I have it fixed for now, but it took more than dismounting the loop mounts. The key was the operation of the pkcon utility.

My use of the loop mounts made sense once upon a time and I simply persisted it over the years without noticing that I didn’t need it anymore. Your suggestion gave me a kick in the pants to validate that they were obsolete. So my environment is simpler now - yay!

Regardless, the issue was, where on earth did all those extra repos get defined for what Cockpit was using and why was it apparently using something that yum and dnf were not. Since these mystery repos were not seen in dnf or yum, I could not reliably enumerate the full list nor could I do anything about them. I got lucky in searching around the net and found references to pkcon, yet another package management utility.

pkcon repo-list showed the full list of repos i expected, plus a number of other disabled repos i did not expect. It also listed media and media-1 through media-5 as a mix of Rocky Linux 8 and CentOS-7, all enabled. Eureka!

So, easy-peasy just use pkcon repo-disable media-1 , right? Nope:
Fatal error: failed to write repo file: Cannot commit to read-only media
OK, how about pkcon repo-remove media-1 ? Nope:
Command failed: A repo id and autoremove required

This is stupid.

So now I try creating /etc/yum.repos.d/local-media.repo . A very brief file, with just enough to kill this off?
[media-1]
name=loop mounted media-1
enabled=0

After creating the file, all I did was pkcon repo-list and all was well. It showed media-1 as disabled and all the others in that sequence disappeared.

Going back to Cockpit, a refresh showed all was well.

So in the end, Cockpit appears to use pkcon for software updates. At some point in the proceedings, it automatically picked up on mounted repo media (which in my case were loop mounts). These were included as repos automatically, despite there being no file identifying them in /etc/yum.repos.d/ . Interestingly enough, Cockpit does make references here and there to the need for a reboot of the system to fully fix some problems. In my case, I created a minimal .repo file. This combined with the dismounts was enough to make the problem go away. I suspect that if i wanted to keep the mounts, i could have expanded my minimal .repo file to include the other dynamically created repos.

In all this, there is an inconsistency between pkcon vs dnf and yum. pkcon being “helpful” really confuses things. What a way to run a railroad.

1 Like
6

Awesome that you did find out the reason. Unfortunate that there are such things to be found.
I might have seen pkcon … once. Good to know that that was more than enough.

PS. yum is dnf; just an alias/symlink to the other name.