[Spacewalk-list] Spacewalk 2.7 database corruption?

[Brian Long]

On Fri, Oct 13, 2017 at 3:58 AM, Michael Mraka <michael.mraka at redhat.com>
wrote:

>
> > 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,
>
No.  This is a SW issue since we appear to have server-side metadata issues.


> 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).
>

I should have mentioned I already found the following article and followed
the directions to try to regenerate the /var/cache/rhn repo information:
https://access.redhat.com/solutions/29056

Only a subset of my channels are listed in the /var/cache/rhn directory and
I need to debug how to get SW to recreate all the metadata.

I've also tried spacewalk-data-fsck and found various problems; I re-run
spacewalk-repo-sync for each repo with and without the -n / latest flag but
/var/cache/rhn metadata is not getting recreated.


> > 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

I will look into this.  I'm not sure we have a good offline backup from
before the corruption took place when /var/lib/pgsql filled up.

Thanks for your assistance!

/Brian/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20171013/48cdeeed/attachment.htm>