[Spacewalk-list] diffirence between yum and up2date

Wed Oct 14 08:33:22 UTC 2009

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

help help help ;)

- -------- 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: 10/09/2009 04:11 PM

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

_______________________________________________
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

iEYEARECAAYFAkrVjNIACgkQSU+5fmlaNkMXngCgpJ+HFfolWnX593Zy5kTJwwTs
SpYAn3wHGaTKvMP1m+gPOoLquz0tV3od
=akbE
-----END PGP SIGNATURE-----