On Fri, Oct 13, 2017 at 3:58 AM, Michael Mraka <[email protected]> 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/
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
