-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 help help help ;)
- -------- Original Message -------- Subject: Re: [Spacewalk-list] diffirence between yum and up2date From: Michiel van Es <[email protected]> To: [email protected] <[email protected]> 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.poolbackeddatasou...@44d990 [ > connectionPoolDataSource -> com.m > change.v2.c3p0.wrapperconnectionpooldatasou...@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.drivermanagerdatasou...@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 <[email protected]> > To: [email protected] <[email protected]> > Date: 09/21/2009 05:16 PM > > >> -------- Original Message -------- >> Subject: [Spacewalk-list] diffirence between yum and up2date >> From: Justin Sherrill <[email protected]> >> To: [email protected] <[email protected]> >> 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: >>>> >>>> [r...@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 >>>> [r...@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: > >> [r...@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 >> [r...@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 >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/spacewalk-list > _______________________________________________ Spacewalk-list mailing list [email protected] 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----- _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
