Packages are synced directly from an URL using 

#> spacewalk-repo-sync -c <channel> -u <URL> -t yum

No rhnpush.

Lots of discrepancies via spacewalk-data-check:

#> spacewalk-data-fsck -v -r 

Checking if packages from database are present on filesystem
File missing: /data/satellite/redhat/1/867/ngspice/20-3.el5/i386/8673012a045320b9e387b7d1f93dcc18/ngspice-20-3.el5.i386.rpm
File missing: /data/satellite/redhat/1/c3a/zarafa-server/6.40.0-2.el5/i386/c3a367729e18df30b3b51e4c9e549edb/zarafa-server-6.40.0-2.el5.i386.rpm
File missing: /data/satellite/redhat/1/d66/python-boto/1.0a-1.el5/noarch/d66352cb5ee69d70e9c4d9a7a3bd72d0/python-boto-1.0a-1.el5.noarch.rpm
[...]
Removed file missing in db: /data/satellite/redhat/1/stage/php53-ldap-5.3.3-5.el5.i386.rpm
Removed file missing in db: /data/satellite/redhat/1/stage/vim-minimal-7.0.109-7.el5.i386.rpm
44536 files scanned
ERROR:  2620 files missing in database


Can we get an update on how to proceed?

Unfortunately I can't reproduce the bug.

# spacewalk-repo-sync -c centos5-x86_64 -i java-1.4.2-gcj-compat
Repo URL: http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=os
Packages in repo:              3641
Packages passed filter rules:     9
Packages already synced:          0
Packages to sync:                 9
1/9 : gjdoc-0.7.7-12.el5-0.x86_64
2/9 : zip-2.31-2.el5-0.x86_64
3/9 : jpackage-utils-1.7.3-1jpp.3.el5-0.noarch
4/9 : chkconfig-1.3.30.2-2.el5-0.x86_64
5/9 : bash-3.2-32.el5-0.x86_64
6/9 : java-1.4.2-gcj-compat-1.4.2.0-40jpp.115-0.x86_64
7/9 : libgcj-4.1.2-54.el5-0.i386
8/9 : gawk-3.1.5-16.el5-0.x86_64
9/9 : libgcj-4.1.2-54.el5-0.x86_64
Linking packages to channel.
Repo http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=os has comps file comps.xml.
Repo http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=os has 0 errata.
Sync completed.
Total time: 0:00:46

# psql -a -U spaceuser spaceschema
spaceschema=# select path from rhnpackage where path like'%java-1.4.2-gcj-compat%';
 redhat/1/0ef/java-1.4.2-gcj-compat/0:1.4.2.0-40jpp.115/x86_64/0ef8755f100250dde0a1befbe6a7399a/java-1.4.2-gcj-compat-1.4.2.0-40jpp.115.x86_64.rpm

# ll /var/satellite/redhat/1/0ef/java-1.4.2-gcj-compat/0:1.4.2.0-40jpp.115/x86_64/0ef8755f100250dde0a1befbe6a7399a/java-1.4.2-gcj-compat-1.4.2.0-40jpp.115.x86_64.rpm
-rw-r--r--. 1 root root 30128 Jun 15  2008 /var/satellite/redhat/1/0ef/java-1.4.2-gcj-compat/0:1.4.2.0-40jpp.115/x86_64/0ef8755f100250dde0a1befbe6a7399a/java-1.4.2-gcj-compat-1.4.2.0-40jpp.115.x86_64.rpm

# spacewalk-data-fsck -v
Checking if packages from database are present on filesystem
    9 files scanned
Checking if packages from filesystem are present in database
    9 files scanned


Also download from webUI works.

Can you still reproduce the issue when syncing new packages or is it just matter of previously sync'ed packages?

1) A newly created channel seems to work better for the packages I've had previously problems with, but I cannot exhaustively test that; a quick "yum update" on a client didn't lead to any problems so far.

The problems seems to be rooted in the way the server has been upgraded from 1.7 to 1.8 which was done by another department. So "old" channels seem to be the root cause, but no amount of resyncing seems to be able to repair the damage.

Can you suggest something here?


2) Yes, I can still reproduce parts of the problem via

# remove all not consistent packages from filesystem
$> spacewalk-data-fsck -r -v

[...]
83166 files scanned
ERROR: 41024 files missing on disk
Checking if packages from filesystem are present in database
Removed file missing in db: /data/satellite/redhat/1/00c/mtr/2:0.71-3.1/i386/00c7d795c366bd2f0fc988f9910fda78/mtr-0.71-3.1.i386.rpm
[...]

# sync a newly created channel
$> spacewalk-repo-sync -c centos5.9-base-64

# check again
$> spacewalk-data-fsck -f

And I get new non-consistent packages again.

mc seems to be a good example. This definately fails for even my freshly synced repo + channel:

Client:

[...]
Error Downloading Packages:
  1:mc-4.6.1a-35.el5.x86_64: failed to retrieve getPackage/mc-4.6.1a-35.el5.x86_64.rpm from centos5.9-base-64
error was [Errno 14] HTTP Error 404: Not Found


Server:

/data> l satellite/redhat/1/cba/mc/4.6.1a-35.el5/x86_64/cba2247cd02a06869a6c684ef36fd4d3/mc-4.6.1a-35.el5.x86_64.rpm
ls: cannot access satellite/redhat/1/cba/mc/4.6.1a-35.el5/x86_64/cba2247cd02a06869a6c684ef36fd4d3/mc-4.6.1a-35.el5.x86_64.rpm: No such file or directory

root@deerms45:/data> l satellite/redhat/1/cba/mc/1\:4.6.1a-35.el5/x86_64/cba2247cd02a06869a6c684ef36fd4d3/mc-4.6.1a-35.el5.x86_64.rpm
-rw-r--r-- 1 root root 2211952 Mar 15 15:20 satellite/redhat/1/cba/mc/1:4.6.1a-35.el5/x86_64/cba2247cd02a06869a6c684ef36fd4d3/mc-4.6.1a-35.el5.x86_64.rpm


When I choose the detail page of this particular package I can see all package details, but again filesystem path is completely wrong:

https://spacewalk/rhn/software/packages/Details.do?pid=9556


Available Architectures:	 x86_64 , i386
Available From:	 centos5.9-base-64 centos5.5-base-64 
[...]
File System Path:	redhat/1/cba/mc/4.6.1a-35.el5/x86_64/cba2247cd02a06869a6c684ef36fd4d3/mc-4.6.1a-35.el5.x86_64.rpm
[...]
Download: Missing File: mc-4.6.1a-35.el5.x86_64.rpm


It seems to me that there is a bug when generating filenames for DB vs filesystem use.

Can anybody point into a direction?

I've committed changes to spacewalk-data-fsck which can remove wrong path from database. Then subsequent spacewalk-repo-sync should put correct path to the db.

spacewalk-data-fsck change in master
commit acfb6c56e4d623f619d3dd978320a577fed0c68b
    911738 - remove incorrect path from db

> commit acfb6c56e4d623f619d3dd978320a577fed0c68b

Could you apply the commit above manually and report back whether it helps to fix your issue?

Fix for this bug is present in Spacewalk 2.0, closing this bug as CURRENTRELEASE.