A searched package appears twice, for each channel containing it

[marmau06]

Problem description

_ when searching for package "bc" (example) in gui, it appears twice for the channel refering it for one OS version, and twice for CLM adressing this channel...:

bc-1.07.1-5.el8.x86_64 | RHEL 8 x86_64 BaseOS bc-1.07.1-5.el8.x86_64 | RHEL 8 x86_64 BaseOS bc-1.06.95-13.el7.x86_64 | RHEL 7 x86_64 bc-1.06.95-1.el6.x86_64 | RHEL 6 x86_64 bc-1.07.1-5.el8.x86_64 | clm_rhel8-clm_rhel8-RHEL 8 x86_64 BaseOS bc-1.07.1-5.el8.x86_64 | clm_rhel8-clm_rhel8-RHEL 8 x86_64 BaseOS bc-1.06.95-13.el7.x86_64 | clm_rhel7-clm_rhel7_env-RHEL 7 x86_64 bc-1.06.95-1.el6.x86_64 | clm_rhel6-clm_rhel6_env-RHEL 6 x86_64

entries are linkged to different path/file: packages/1/473/bc/1.07.1-5.el8/x86_64/473de789269b7b28c3e8805be07af0473531a132/bc-1.07.1-5.el8.x86_64.rpm packages/1/f6e/bc/1.07.1-5.el8/x86_64/f6e357fc61da8981294493b05c1d81014f4f56c6f2dc22544234fc311f5fcd61/bc-1.07.1-5.el8.x86_64.rpm

In first one (473) we can not see "change log" (There was an error reading the selected package changelog. Please check that the package physically exists and has the correct permissions.) Second one is Ok (f6e)

Obviously, when trying to install the package on a server, it tries to use the "non working file.. Even if the file exists, at the mentionned path...

Version of Uyuni Server

Information for package Uyuni-Server-release:

Repository : Uyuni Server Stable Name : Uyuni-Server-release Version : 2022.06-183.9.uyuni2 Arch : x86_64 Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni Support Level : Level 3 Installed Size : 1.4 KiB Installed : Yes (automatically) Status : up-to-date Source package : Uyuni-Server-release-2022.06-183.9.uyuni2.src Summary : Uyuni Server Description : Uyuni lets you efficiently manage physical, virtual, and cloud-based Linux systems. It provides automated and cost-effective configuration and software management, asset management, and system provisioning.

Details about the issue

[mbussolotto]

Hi @marmau06 , just to confirm since you're using RHEL8: did you transform modular repositories into regular repositories as described here https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/content-lifecycle-examples.html#appstream-filters ? Thanks!

[mbussolotto]

CC @cbbayburt

[marmau06]

Hello, Sure, we are using CLM for all our OS releases,be cause we are interested in "blocking" patch list, using build feature. So for RHEL8, yes, CLM are used, with filters for appstreams... the problem i snot general to RHEL8 packages

for exemple here is what happen for package bc:

locate bc-1.07.1-5.el8.x86_64.rpm /var/spacewalk/packages/1/f6e/bc/1.07.1-5.el8/x86_64/f6e357fc61da8981294493b05c1d81014f4f56c6f2dc22544234fc311f5fcd61/bc-1.07.1-5.el8.x86_64.rpm /var/spacewalk/systems/packages/1/473/bc/1.07.1-5.el8/x86_64/473de789269b7b28c3e8805be07af0473531a132/bc-1.07.1-5.el8.x86_64.rpm /var/spacewalk/systems/packages/1/f6e/bc/1.07.1-5.el8/x86_64/f6e357fc61da8981294493b05c1d81014f4f56c6f2dc22544234fc311f5fcd61/bc-1.07.1-5.el8.x86_64.rpm

"473" is the wrong one...

in /var/spacewalk/systems/packages/1/473, there is also one ksh: locate ksh-20120801-28.el6_7.3.x86_64.rpm /var/spacewalk/systems/packages/1/473/ksh/20120801-28.el6_7.3/x86_64/4735046105d7897637aa5fb13a19e681c1aa0251/ksh-20120801-28.el6_7.3.x86_64.rpm

but this package exists only once.. lokking at it through gui, we cannot access to cgange log...

[mbussolotto]

@mcalmer do you have any idea?

[marmau06]

Hello, another package is no more reachable, preventing any patching for a server. I need a solution/explanation... Do I have to plan a complete re build of repositories ???? Thanks for your help!

Removing: kernel x86_64 2.6.32-754.39.1.el6 @rhel_6_x86_64 133 M kernel-devel x86_64 2.6.32-754.39.1.el6 @rhel_6_x86_64 26 M

Transaction Summary

Install 2 Package(s) Upgrade 22 Package(s) Remove 2 Package(s)

Total size: 94 M Total download size: 82 M Is this ok [y/N]: y Downloading Packages:

Error Downloading Packages: kernel-headers-2.6.32-754.47.1.el6.x86_64: failed to retrieve getPackage/1/d5a8768da97dbec696b8c9dd6f927e6471f614e3/kernel-headers-2.6.32-754.47.1.el6.x86_64.rpm from clm_rhel6-clm_rhel6_env-rhel6_x86_64 error was [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" perf-2.6.32-754.47.1.el6.x86_64: failed to retrieve getPackage/1/8c7b004caa68a085797ea32e0bb3844121075759/perf-2.6.32-754.47.1.el6.x86_64.rpm from clm_rhel6-clm_rhel6_env-rhel6_x86_64 error was [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" kernel-firmware-2.6.32-754.47.1.el6.noarch: failed to retrieve getPackage/1/8f92b432c6a040c2308c1dd37924b54b8f379e7f/kernel-firmware-2.6.32-754.47.1.el6.noarch.rpm from clm_rhel6-clm_rhel6_env-rhel6_x86_64 error was [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" kernel-2.6.32-754.47.1.el6.x86_64: failed to retrieve getPackage/1/9913b824f5d62ac9f47a7f0a9e389cd3e5f6035f/kernel-2.6.32-754.47.1.el6.x86_64.rpm from clm_rhel6-clm_rhel6_env-rhel6_x86_64 error was [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" kernel-devel-2.6.32-754.47.1.el6.x86_64: failed to retrieve getPackage/1/e2864eb1371103f00550b4d7ecbc6e5358568d89/kernel-devel-2.6.32-754.47.1.el6.x86_64.rpm from clm_rhel6-clm_rhel6_env-rhel6_x86_64 error was [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

[marmau06]

locate kernel-headers-2.6.32-754.47.1.el6.x86_64.rpm /var/spacewalk/systems/packages/1/d5a/kernel-headers/2.6.32-754.47.1.el6/x86_64/d5a8768da97dbec696b8c9dd6f927e6471f614e3/kernel-headers-2.6.32-754.47.1.el6.x86_64.rpm

[mbussolotto]

Hi @marmau06 , since this broken packages are coming from custom channel, you can remove them using: Software => Manage => Channels => Select the channel => Packages => List/Remove

[marmau06]

Hello, Ok I did the job for bc package... now, I can see it once for "base channel"... but CLM is still twice:

Then, I have the same issue for package that are visible only once (kernel from this morning...)

[marmau06]

Hello mbussoloto. Ok, your solution seems to work properly.. I tried on several packages, and it is Ok, meaning that bc package has been installed, and kernel packages (ie kernel-headers-2.6.32-754.47.1.el6.x86_64.rpm) are reachable for "change log" item... So I suppose that I could update the server (not yet, reboot required). What I did: remove individual packages as you said, resynchronize channels containing them... So next question is: have you a way to identify broken packages or do I have to recreate all repositories in Uyuni to be sure that I will not encounter same issue later, during production patching ? THen, did you identify any reason why those packages got "broken"? It is a little bit frightening...

Thanks in advance,

hervé

[mbussolotto]

Hello mbussolotto. Ok, your solution seems to work properly.. I tried on several packages, and it is Ok, meaning that bc package has been installed, and kernel packages (ie kernel-headers-2.6.32-754.47.1.el6.x86_64.rpm) are reachable for "change log" item... So I suppose that I could update the server (not yet, reboot required).

Good to know!

What I did: remove individual packages as you said, resynchronize channels containing them... So next question is: have you a way to identify broken packages or do I have to recreate all repositories in Uyuni to be sure that I will not encounter same issue later, during production patching ?

Currently, there's no way to identify broken package, but feel free to create an enhancement issue

Then, did you identify any reason why those packages got "broken"? It is a little bit frightening...

Not really, I tried to reproduce it but I never occur the issue (it might also be something on the channle side). I guess you can find more information on files:

• CLM: /var/log/rhn/rhn_taskomatic_daemon.log
• channels: /var/log/rhn/reposync/*

[marmau06]

Hello, I'm back... It's becoming "unbearable"... I was requested to install java on a RHEL8 server, and I had to remove up to ten packages that was failing as described in this topic... We have to find a way to correct automatically Uyuni repositories... otherwise, the very last solution will be to recreate all of them !!!

Please, find a solution !!!

a solution could be to identify packages with no available "change log"

=> Change Log There was an error reading the selected package changelog. Please check that the package physically exists and has the correct permissions.

[mbussolotto]

@lucidd do you have any idea?

[lucidd]

Hello, I'm back... It's becoming "unbearable"... I was requested to install java on a RHEL8 server, and I had to remove up to ten packages that was failing as described in this topic... We have to find a way to correct automatically Uyuni repositories... otherwise, the very last solution will be to recreate all of them !!!

Please, find a solution !!!

a solution could be to identify packages with no available "change log"

=> Change Log There was an error reading the selected package changelog. Please check that the package physically exists and has the correct permissions.

Did you check if the packages with unavailable changelog have the right permissions? Also are there any error in the logfiles that @mbussolotto mentioned?

[marmau06]

Nothing found in log files.... here is an example of a package whith no change log:

(notice that on two following screens, package is available twice for I686 architecture) "/1/3eb" "/1/4b8"

None of these two packages have change log available...

Physical files are present: locate accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm

here they are:

myserver:~ # ll /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 root root 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm myserver:~ # ll /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 root root 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm

Please tell me if yo need other things...

[mbussolotto]

Can you please run spacewalk-repo-sync -l ? I guess you would find a duplicate channel. Then you can try to remove it using spacewalk-remove-channel ? @lucidd what do you think?

[marmau06]

No duplicate channel found, sorry...

[lucidd]

ok i'm not entirely sure whats wrong here but a few things stand out. So having the same package twice can happen if the package is not entirely the same which the different checksums seem to indicate and that shouldn't be a problem i think. Can you check if the packages really don't have a changelog by running rpm -qp --changelog path/to/package on them? I assume that there is a changelog and that susemanager is just not able to read it. The other thing that confuses me is the path /var/spacewalk/systems/packages/ where i don't see any packages on any of our system they are in /var/spacewalk/packages/ instead and more importantly the permissions for those are -rw-r--r-- 1 wwwrun www.

[marmau06]

Here is the result, using the same package

gui message: Change Log There was an error reading the selected package changelog. Please check that the package physically exists and has the correct permissions.

locate packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm myserver:~ # rpm -qp --changelog /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm warning: /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

• Fri Nov 06 2020 Yunying Sun [email protected] - 2.8-1

• Initial Packaging

No ideas about /var/spacewalk/systems/packages/.. We didn't create it manually...

Here is the picture:

myserver:~ # ll /var/spacewalk/ total 132 drwx------ 4 postgres postgres 122880 Jul 21 17:41 db-backup drwxr-xr-x 3 root root 4096 Jun 3 04:01 packages drwxr-xr-x 4 wwwrun www 4096 Jun 7 08:35 rhn drwxrwxr-x 5 wwwrun www 4096 Jun 6 09:58 systems myserver:~ # ll /var/spacewalk/systems/ total 24 drwx------ 2 root root 16384 Nov 5 2021 lost+found drwxr-xr-x 3 wwwrun root 4096 Nov 5 2021 packages drwxr-xr-x 4 wwwrun www 4096 Nov 5 2021 rhn

[lucidd]

/var/spacewalk/packages being owned by root is not right. Can you change it to wwwrun www same as the rhn is. Also all of the contents of that directory should have the same owners. Let me know if that resolves the issue.

[marmau06]

Hello, So I changed ownership on /var/spacewalk/packages and its sub directories.. BUt I have always the same issue for the package accel-config-2.8-1.el8.x86_64.rpm as it is only present in /var/spacewalk/system/packages/ :

myserver:/var/spacewalk # locate accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm

myserver:/var/spacewalk # ll /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 root root 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm myserver:/var/spacewalk # ll /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 root root 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm

So root owned... is this normal to have /var/spacewalk/packages and /var/spacewalk/systems/packages/ ?

SOme weeks ago, we made a restore using smdba tool... Anychance it introduced such a mess ?

[lucidd]

files in /var/spacealk/systems and below should also be owned by wwwrun www. It could certainly be that something went wrong with the restoring process and it ended up like this.

[marmau06]

So it is normal to have packages in /var/spacewalk/systems/packages and /var/spacewalk/packages ? And I have to change ownership in /var/spacealk/systems too ? May be something to run, to get one and only one version of a rpm file ?

(probably I will make this on monday, as we have a patching run this sunday...)

[marmau06]

Ok, So iI did the chown on both /var/spacewalk/packages and /var/spacewalk/systems/packages

Package is always found twice: locate accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm ll /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 wwwrun www 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 wwwrun www 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm

Requesting change log in command line works for both

rpm -qp --changelog /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm warning: /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

• Fri Nov 06 2020 Yunying Sun [email protected] - 2.8-1

• Initial Packaging rpm -qp --changelog /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm warning: /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

• Fri Nov 06 2020 Yunying Sun [email protected] - 2.8-1

• Initial Packaging But gui fails for them.....

Any idea to fix this situation ?

Thanks

[lucidd]

Ok, So iI did the chown on both /var/spacewalk/packages and /var/spacewalk/systems/packages

Package is always found twice: locate accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm ll /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 wwwrun www 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm -rw-r--r-- 1 wwwrun www 65024 Nov 5 2021 /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm

Requesting change log in command line works for both

rpm -qp --changelog /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm warning: /var/spacewalk/systems/packages/1/3eb/accel-config/2.8-1.el8/x86_64/3eb370a7fcbfe6b04838dc5dcb7a1e54c984bbc4/accel-config-2.8-1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

• Fri Nov 06 2020 Yunying Sun [email protected] - 2.8-1

• Initial Packaging rpm -qp --changelog /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm warning: /var/spacewalk/systems/packages/1/4b8/accel-config/2.8-1.el8/x86_64/4b80efb60f8a3b73a4fc8d2d45fbd9ae8812972f68b5c69712b3917324a5e483/accel-config-2.8-1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

• Fri Nov 06 2020 Yunying Sun [email protected] - 2.8-1

• Initial Packaging But gui fails for them.....

Any idea to fix this situation ?

Thanks

so given the permissions should be fixed now and changelog is present in both files does it also work now from the web ui? Do you still have any issues installing the package or is only the dublicate search result an issue?

[lucidd]

So it is normal to have packages in /var/spacewalk/systems/packages and /var/spacewalk/packages ? And I have to change ownership in /var/spacealk/systems too ? May be something to run, to get one and only one version of a rpm file ?

(probably I will make this on monday, as we have a patching run this sunday...)

im not sure about /var/spacewalk/systems/packages but packages should definitely be in /var/spacewalk/packages and yes /var/spacewalk/packages permission should be the same as mentioned above. As for removing the "duplicates" i don't know if they are an issue or what the difference between them is. They are not entirely the same otherwise they would have the same checksum so it is also unclear which of them to keep.

[marmau06]

Here is another example, they have the same cksum:

myserver:~ # cksum /var/spacewalk/packages/1/782/nano/2.9.8-1.el8/x86_64/7824b7513db8f22f458ae2a74b196136f519ddcd6100013c64e9a09b9cc1a33b/nano-2.9.8-1.el8.x86_64.rpm 4036722584 594424 /var/spacewalk/packages/1/782/nano/2.9.8-1.el8/x86_64/7824b7513db8f22f458ae2a74b196136f519ddcd6100013c64e9a09b9cc1a33b/nano-2.9.8-1.el8.x86_64.rpm myserver:~ # cksum /var/spacewalk/systems/packages/1/2d0/nano/2.9.8-1.el8/x86_64/2d00f87056ac10304212bb99015fb4d3512f0f65/nano-2.9.8-1.el8.x86_64.rpm 4036722584 594424 /var/spacewalk/systems/packages/1/2d0/nano/2.9.8-1.el8/x86_64/2d00f87056ac10304212bb99015fb4d3512f0f65/nano-2.9.8-1.el8.x86_64.rpm

Well, to day, I have to find a solution to fix this... As we do not know what happened, and wht do do to remove the right package:

we have several channels... rhel6, 7, 8... Debian 9, 10,11.... we have several CLM using them...

Today, we get this issue when trying to install "new packages" on some servers. At this time, global patching is still working, but we do not know how man time it will..

Here is the tree of directory:

myserver:/var/spacewalk # tree -d -L 2 . ├── db-backup │   ├── lost+found │   └── tmp ├── packages │   └── 1 ├── rhn │   ├── comps │   └── modules └── systems ├── lost+found ├── packages └── rhn

myserver:/var/spacewalk # tree -d -L 2 systems/ systems/ ├── lost+found ├── packages │   └── 1 └── rhn ├── comps └── modules

We can see that we have the same tree under /var/spacewalk, then under /var/spacewalk/systems...

What will happen if we keep only /var/spacewalk/db-backup, remove all other subdirectories, then initiate a new channel synchronization ?

Thanks

[marmau06]

Hello, issue has been fixed and here is what I did:

I move lost+found from /var/spacewalk/systems/ to /var/spacewalk/.. I don't know what happened as the real FS is /var/spacewalk/.

Using GUI, I removed all packages from Uyuni... It took a while.. I restarted Uyuni services, I restarted deletion processing several time because I thought that is was sticked.. But at a time, I got the message of completion... /var/spacewalk/packages was emptied... /var/spacewalk/systems was still full of files... So I removed completely /var/spacewalk/systems/. I restarted "spacewalk-repo-sync for all parent channels.. I rebuilt all projects in CLM... all files are owned by wwwrun:www/usr/local/sbin/sync_repos.sh

/var/spacewalk/systems/ didn"t reappear..

And now, it works normally... Another benefit: as sync was defined for "latest", we saved some storage in FS.. :)

I do not know what happened, but I suspect smdba restore test to introduce such a mess...

Thanks for you help

[mbussolotto]

@marmau06 Finally a good news :) . I would keep this issue open because we need to verify smdba procedure is safe

[marmau06]

Sure... and may be we did something wrong when testing restore... So getting the right procedure would be fine... :)

[mcalmer]

Well, smdba restore only the Database. But your problem was, that the package files were already at the wrong place .../systems/... . I have no idea how the packages ended up there and how such paths also ended up in the database.

The only idea would be, that somebody played around with config options in rhn.conf. You can change the mountpoint there. Its a big mystery :-)