[Spacewalk-list] diffirence between yum and up2date

[Michiel van Es]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- -------- Original Message --------
Subject: [Spacewalk-list] diffirence between yum and up2date
From: Justin Sherrill <jsherril at redhat.com>
To: spacewalk-list at redhat.com <spacewalk-list at redhat.com>
Date: 9/16/2009 3:52 PM

> Michiel van Es wrote:
>> Hello,
>>
>> I found out that some machines (CentOS 4 machines) are not seeing
>> updates through yum but up2date does.
>> What is the diffirence between the 2? Both use Spacewalk right?
>>
>>
>> An example:
>>
>> [root at bcmw01p ~]# yum -y update
>> Setting up Update Process
>> Setting up repositories
>> spacewalk-client-tools    100% |=========================| 1.9 kB    00:00
>> Reading repository metadata in from local files
>> No Packages marked for Update/Obsoletion
>> [root at bcmw01p ~]# up2date -fu
>>
>> Fetching Obsoletes list for channel: centos4...
>>
>> Fetching Obsoletes list for channel: centos4-Base...
>>
>> Fetching Obsoletes list for channel: centos4-Updates...
>>
>> Fetching Obsoletes list for channel: centos4-extras...
>>
>> Fetching Obsoletes list for channel: centos4-addons...
>>
>> Name                                    Version        Rel
>> ----------------------------------------------------------
>> OpenIPMI                                1.4.14         1.4E.25
>>  i386
>> OpenIPMI-libs                           1.4.14         1.4E.25
>>  i386
>> audit                                   1.0.16         4.el4
<snip>
>>
>>
>> Kind regards,
>>
>> Michiel
>>
> 
> So up2date talks to the server and gets a real time list of available
> packages.  It also does some dependency solving on the server side.
> 
> yum however simply downloads the yum cache on the server that may lag
> behind what is actually in the channel or may be out of date (if
> something isn't working correctly).
> 
> You might wanna try deleting /var/cache/rhn/repodata/CHANNEL_LABEL
> 
> then run 'yum update' on a client.  It will error out, but should
> initiate a yum cache rebuild.  If you look in that directory after a few
> minutes you'll see files in there being created.
> 
> If you don't, then something is wrong.  Make sure taskomatic is running.
> 
> -Justin
> 

Hi Justin,

Thanks for the tip!
I will try that on some guests who are having these problems and wil
lreport the outcome.

Kind regards,

Michiel


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKsj3BAAoJEKmnTNucqQlOwVYIAMAm3lUkyy0ecMBsbfLXnATn
Gj2d3eJBhNeL6kBALDESwF3LpzaduIAPL3kekc/z8JjkUs4elWAaPSTxl76OO8vZ
vg/H9uv0yEGd/33WQcj78DAMmPMLoMPEErkoVYLJYNHBTikluJ0lxNHsSC5ENgiz
FI3jXBxnaANjB6ytxRRjDJd4BNt+w5ZT1tbeHy7JuVJLN3nlIXBJYbgeya4/2kBx
fL3QXPYzm2FyQyLgUtuTbh04s0uHvuwtoXPaFrWMD1aCpukssGWEC5J4EmIujr3M
fXQGRPHQgkAb71qwd4LZQL612CaAoCWjk+oFQaMmhirW26ke2n4QjLxgtXLbp1Y=
=3o+9
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9CA9094E.asc
Type: application/pgp-keys
Size: 1728 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20090917/6a5c3265/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9CA9094E.asc.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20090917/6a5c3265/attachment.obj>