[Spacewalk-list] diffirence between yum and up2date

Fri Oct 9 14:11:21 UTC 2009

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

Hi Justin,

It's been a long time but I get some new issues:

- - I find that yum is not working at all: it can not find any repo or
package with the spacewalk repo's enabled (and the centos repositories
disabled).
- - I removed the cache in /var/cache/rhn/repodata/CHANNEL_LABEL and am
seeing that the CentOS 5 repositories are automatically rebuild after a
spacewalk-server restart, the centos 4 are not..

Do you know why the cache isn't rebuild correctly after restarting
spacewalk?

Nothing wrong in the tascomatic daemon logfile:
TATUS | wrapper  | 2009/10/09 15:23:25 | --> Wrapper Started as Daemon
STATUS | wrapper  | 2009/10/09 15:23:25 | Launching a JVM...
INFO   | jvm 1    | 2009/10/09 15:23:25 | Wrapper (Version 3.2.1)
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2009/10/09 15:23:25 |
INFO   | jvm 1    | 2009/10/09 15:23:29 | Oct 9, 2009 3:23:29 PM
com.mchange.v2.log.MLog <clinit>
INFO   | jvm 1    | 2009/10/09 15:23:29 | INFO: MLog clients using java
1.4+ sta
ndard logging.
INFO   | jvm 1    | 2009/10/09 15:23:30 | Oct 9, 2009 3:23:29 PM
com.mchange.v2.c3p0.C3P0Registry banner
INFO   | jvm 1    | 2009/10/09 15:23:30 | INFO: Initializing c3p0-0.9.0
[built 13-July-2007 10:11:26 -0400; debug? false; trace: 5]
INFO   | jvm 1    | 2009/10/09 15:23:30 | Oct 9, 2009 3:23:30 PM
com.mchange.v2.c3p0.PoolBackedDataSource getPoolManager
INFO   | jvm 1    | 2009/10/09 15:23:30 | INFO: Initializing c3p0
pool... com.mchange.v2.c3p0.PoolBackedDataSource at 44d990 [
connectionPoolDataSource -> com.m
change.v2.c3p0.WrapperConnectionPoolDataSource at 18e18a3 [
acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay ->
1000, autoCommitOnClose -> f
alse, automaticTestTable -> null, breakAfterAcquireFailure -> false,
checkoutTimeout -> 0, connectionTesterClassName ->
com.mchange.v2.c3p0.impl.DefaultConne
ctionTester, factoryClassLocation -> null,
forceIgnoreUnresolvedTransactions -> false, identityToken -> 18e18a3,
idleConnectionTestPeriod -> 300, initialPool
Size -> 5, maxIdleTime -> 300, maxPoolSize -> 20, maxStatements -> 0,
maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource ->
com.mchange.v2.c
3p0.DriverManagerDataSource at 1f98d58 [ description -> null, driverClass
- -> null, factoryClassLocation -> null, identityToken -> 1f98d58, jdbcUrl
- -> jdbc:oracl
e:thin:@devlinux01:1521:xe, properties -> {user=******, password=******}
], preferredTestQuery -> null, propertyCycle -> 300,
testConnectionOnCheckin -> fals
e, testConnectionOnCheckout -> false, usesTraditionalReflectiveProxies
- -> false ], factoryClassLocation -> null, identityToken -> 44d990,
numHelperThreads ->

Can I look somewhere else to find errors or why the centos 4 client
isn't connecting through yum?
If I enable the default CentOS 4 yum repositories , yum works and get
their new packages..

Kind regards,

Michiel

- -------- Original Message --------
Subject: Re: [Spacewalk-list] diffirence between yum and up2date
From: Michiel van Es <michiele at info.nl>
To: spacewalk-list at redhat.com <spacewalk-list at redhat.com>
Date: 09/21/2009 05:16 PM

> 
> 
> -------- 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...
>>>
> <snip>
>> 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
> 
> This folder is not existing on a CentOS 4 machine..
> 
>> 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.
> 
> I got the same when installing swatch from the rpmforge repo:
> 
> [root at stbcmw01 log]# yum search swatch
> Searching Packages:
> Setting up repositories
> spacewalk-client-tools    100% |=========================| 1.9 kB    00:00
> Reading repository metadata in from local files
> primary.xml.gz            100% |=========================| 7.0 kB    00:00
> spacewalk-: ################################################## 33/33
> No Matches found
> [root at stbcmw01 log]# up2date swatch
> 
> Fetching Obsoletes list for channel: centos4...
> 
> Fetching Obsoletes list for channel: rpmforge4...
> ########################################
> 
> 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...
> 
> Fetching rpm headers...
> ########################################
> 
> Name                                    Version        Rel
> ----------------------------------------------------------
> swatch                                  3.1.1          1.el5.rf
>  noarch
> 
> 
> Testing package set / solving RPM inter-dependencies...
> 
> Downloading headers to solve dependencies...
> #######################################
> Downloading headers to solve dependencies...
> #######################################
> Downloading headers to solve dependencies...
> There was a package dependency problem. The message was:
> 
> Unresolvable chain of dependencies:
> perl-Bit-Vector  6.4-2.el5.rf            requires rtld(GNU_HASH)
> swatch  3.1.1-1.el5.rf                   requires perl(Date::Manip)
> 
> 
> The following packages were added to your selection to satisfy dependencies:
> Package                                Required by
> -
> ----------------------------------------------------------------------------
> perl-Bit-Vector-6.4-2.el4.rf.i386       perl-Date-Calc-5.3-9
> 
>               perl(Bit::Vector)
> 
> 
> 
>> If you don't, then something is wrong.  Make sure taskomatic is running.
> 
> Kind regards
> 
>> -Justin
> 
> Michiel
> 
>> ------------------------------------------------------------------------
> 
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrPRIkACgkQSU+5fmlaNkMjywCfdXRIJTb6pDt+1PRlMF2Wdvkv
NyAAn1XosBKyGQbRQmW75Jh+0JMWaun9
=q3ER
-----END PGP SIGNATURE-----