[Spacewalk-list] Spacewalk 2.7 database corruption?

[Michael Mraka]

Brian Long:
> My team recently updated from 2.5 to 2.7 but we also had an operational
> issue where the database partition filled up (while running SW 2.5) and
> postgres came to a halt.  Since that time we have experienced a few issues
> although the upgrade to 2.7 went smoothly.
> 
> One of them is that the Web UI shows packages available (and I can download
> them from within the Web UI), but our clients cannot see the same packages
> even if I remove /var/cache/yum, yum clean all, etc. on the client.  I am
> trying to determine how to clean up the database and package repository
> such that the clients see exactly what is shown in the Web UI.  We have
> tried iterations of spacewalk-data-fsck to no avail.

There could be basically two reasons for this:
a) packages are excluded on client side, e.g. in /etc/yum.conf or via
yum-priority plugin,
b) there are stale channel metadata on spacewalk.
I'd check;
- can you see the "available" package in
  /var/cache/rhn/repodata/<channel-name>/primary.xml.gz on spacewalk server?
- if you remove /var/cache/yum on client and run 'yum repolist' (to
  download 100% fresh metadata) can you see that package in
  /var/cache/yum/.../<channel-name>/primary.xml.gz on client?
This should tell you where the information about available package has
bee lost (like server-network-client).

> Second, we have the following database errors when we try removing one of
> our admins:
> 2017-10-12 15:11:14.752 EDT ERROR:  could not read block 0 of relation
> base/16384/22380: read only 0 of 8192 bytes

This sounds as a disk failure... As I'm not failiar with this kind of
issues I can only point you to http://wiki.postgresql.org/wiki/Corruption

...
> How can we go about fixing these two issues?
> 
> Thank you for any assistance!
> 
> /Brian/


Regards,

--
Michael Mráka
System Management Engineering, Red Hat