LISTSERV - SCIENTIFIC-LINUX-DEVEL Archives

SCIENTIFIC-LINUX-DEVEL Archives

May 2010

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

	LISTSERV Archives
	SCIENTIFIC-LINUX-DEVEL Home
	SCIENTIFIC-LINUX-DEVEL May 2010

	Log In
	Register

	Subscribe or Unsubscribe

	Search Archives
Options:	Use Monospaced Font Show Text Part by Default Show All Mail Headers
Message:	[<< First] [< Prev] [Next >] [Last >>]
Topic:	[<< First] [< Prev] [Next >] [Last >>]
Author:	[<< First] [< Prev] [Next >] [Last >>]
Subject:	Re: Serious yum bug in SL4.x distributions
From:	Valery Mitsyn <[log in to unmask]>
Reply To:	Valery Mitsyn <[log in to unmask]>
Date:	Mon, 10 May 2010 18:59:52 +0400
Content-Type:	TEXT/PLAIN
Parts/Attachments:	TEXT/PLAIN (336 lines)
On Mon, 10 May 2010, Cristina Aiftimiei wrote:

> Hi,
>
> :-(

What version and arch of SL4 you are trying on?

>
> # rm -f /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
> # yum clean all
> Loading "kernel-module" plugin
> Cleaning up Everything
> 0 headers removed
> 0 packages removed
> 51 metadata files removed
> 0 cache files removed
> 1 cache files removed
> # yum update
> Loading "kernel-module" plugin
> Setting up Update Process
> Setting up repositories
> [...]
> jpackage5_generic_free    100% |=========================| 2.3 kB    00:00 
> Reading repository metadata in from local files
> primary.xml.gz            100% |=========================| 2.3 kB    00:00 
> (process:29772): GLib-CRITICAL **: file gtimer.c: line 106 (g_timer_stop): 
> assertion `timer != NULL' failed
>
> (process:29772): GLib-CRITICAL **: file gtimer.c: line 88 (g_timer_destroy): 
> assertion `timer != NULL' failed
> Traceback (most recent call last):
> File "/usr/bin/yum", line 29, in ?
>   yummain.main(sys.argv[1:])
> File "/usr/share/yum-cli/yummain.py", line 97, in main
>   result, resultmsgs = do()
> File "/usr/share/yum-cli/cli.py", line 477, in doCommands
>   return self.updatePkgs()
> File "/usr/share/yum-cli/cli.py", line 955, in updatePkgs
>   self.doRepoSetup()
> File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup
>   self.doSackSetup(thisrepo=thisrepo)
> File "__init__.py", line 260, in doSackSetup
> File "repos.py", line 287, in populateSack
> File "/usr/lib/python2.3/site-packages/yum/sqlitecache.py", line 40, in 
> getPrimary
>   self.repoid))
> TypeError: Can not create index on requires table: near "NOT": syntax error
>
> it's true the pyc was recreated:
> # ll /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
> -rw-r--r--  1 root root 2496 May 10 16:40 
> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
>
> Cris
>
>
> Valery Mitsyn wrote:
>> Hi Cristina,
>> 
>> my fault.
>> if you have already:
>>  - yum-metadata-parser installed
>>  - moved the original sqlitecache.py* to sqlitecache.py*_
>>  - copied new sqlitecache.py* to /usr/lib/python2.3/site-packages/yum/
>> next do
>> rm -f usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
>> thist file will be recompiled on the next yum run.
>>  And finally try to run:
>> yum clean all ; yum update
>> 
>> On Sun, 9 May 2010, Cristina Aiftimiei wrote:
>> 
>>> Hi,
>>> 
>>> just tried all the steps...:-(
>>> but the error changed:
>>> # rpm -Uvh 
>>> http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm 
>>> Retrieving 
>>> http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm 
>>> warning: /var/tmp/rpm-xfer.rv5nfu: V3 DSA signature: NOKEY, key ID 
>>> 443e1821
>>> Preparing...                ########################################### 
>>> [100%]
>>>  1:yum-metadata-parser    ########################################### 
>>> [100%]
>>> # mv /usr/lib/python2.3/site-packages/yum/sqlitecache.py 
>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.py_
>>> # mv /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc 
>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc_
>>> # /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.py 
>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.py
>>> # /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyc 
>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
>>> # /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyo 
>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyo
>>> # yum clean all
>>> Loading "kernel-module" plugin
>>> Cleaning up Everything
>>> 0 headers removed
>>> 0 packages removed
>>> 63 metadata files removed
>>> 0 cache files removed
>>> 13 cache files removed
>>> 
>>> # yum update
>>> .....
>>> jpackage5_generic_free    100% |=========================| 2.3 kB    00:00
>>> Reading repository metadata in from local files
>>> primary.xml.gz            100% |=========================| 2.3 kB    00:00
>>> 
>>> (process:11551): GLib-CRITICAL **: file gtimer.c: line 106 (g_timer_stop): 
>>> assertion `timer != NULL' failed
>>> 
>>> (process:11551): GLib-CRITICAL **: file gtimer.c: line 88 
>>> (g_timer_destroy): assertion `timer != NULL' failed
>>> Traceback (most recent call last):
>>> File "/usr/bin/yum", line 29, in ?
>>>   yummain.main(sys.argv[1:])
>>> File "/usr/share/yum-cli/yummain.py", line 97, in main
>>>   result, resultmsgs = do()
>>> File "/usr/share/yum-cli/cli.py", line 477, in doCommands
>>>   return self.updatePkgs()
>>> File "/usr/share/yum-cli/cli.py", line 955, in updatePkgs
>>>   self.doRepoSetup()
>>> File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup
>>>   self.doSackSetup(thisrepo=thisrepo)
>>> File "__init__.py", line 260, in doSackSetup
>>> File "repos.py", line 287, in populateSack
>>> File "/usr/lib/python2.3/site-packages/sqlitecachec.py", line 40, in 
>>> getPrimary
>>>   self.repoid))
>>> TypeError: Can not create index on requires table: near "NOT": syntax 
>>> error
>>> 
>>> # rpm -qa|grep yum
>>> yum-2.4.3-10.SL
>>> yum-metadata-parser-1.0-8.el4.centos
>>> yum-conf-48-1.SL
>>> 
>>> Cris
>>> 
>>> 
>>> 
>>> Valery Mitsyn wrote:
>>>> On Sun, 9 May 2010, Valery Mitsyn wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> probably this is not very useful for everybody, but
>>>>> it works in this way.
>>>>> 1) install yum-metadata-parser from the CentOS:
>>>>> rpm -Uvh \
>>>>> http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm 
>>>>> 2) move away two files:
>>>>> mv /usr/lib/python2.3/site-packages/yum/sqlitecache.py \
>>>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.py_
>>>>> mv /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc \
>>>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc_
>>>> 
>>>> 2a) copy 3 files:
>>>> /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.py \
>>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.py
>>>> /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyc \
>>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc
>>>> /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyo \
>>>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyo
>>>> 
>>>>> 3) now yum should works with repos:
>>>>> http://mirrors.dotsrc.org/jpackage/5.0/generic/free/
>>>>> http://mirrors.dotsrc.org/jpackage/5.0/generic/non-free/
>>>>> yum clean all
>>>>> yum -y --tsflags=test update
>>>>> 
>>>>> On Fri, 7 May 2010, Valery Mitsyn wrote:
>>>>> 
>>>>>> On Fri, 7 May 2010, Troy Dawson wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> Sorry, but we are concentrating on SL 5.5 right now.
>>>>>>> The one thing I did find before being distracted was that CentOS did 
>>>>>>> several things into their yum that isn't in the standard yum.  But you 
>>>>>>> didn't give the source rpm for them, and I never got enough time to 
>>>>>>> find CentOS's source rpm.  so I'm not sure exactly what they did.
>>>>>> 
>>>>>> Could it be in the yum-metadata-parser rpm which is in
>>>>>> require list of yum in centos?
>>>>>> One can test this case by installing yum-metadata-parser
>>>>>> from centos repo to SL4X.
>>>>>> 
>>>>>>> Their changenotes say something along the lines
>>>>>>> "put in the usual change"
>>>>>>> 
>>>>>>> Troy
>>>>>>> 
>>>>>>> Cristina Aiftimiei wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> is there any news?
>>>>>>>> Sorry to disturb - but we are relly interested in having a solution.
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Cristina
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Troy Dawson wrote:
>>>>>>>>> Peter Sl??ik wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> I believe this list is the right place to report the following yum
>>>>>>>>>> bug, which keeps causing wrinkles to the EGEE community. Apologies 
>>>>>>>>>> for
>>>>>>>>>> the length, my intention is to provide as many details as possible.
>>>>>>>>>> 
>>>>>>>>>> The problems started approx. on April 6, when people from the 
>>>>>>>>>> jpackage
>>>>>>>>>> project changed the digest of their repo's digital signature from 
>>>>>>>>>> SHA
>>>>>>>>>> to SHA1. (I think they just updated their createrepo package, 
>>>>>>>>>> because
>>>>>>>>>> the "repomd.xml" files on my machines contained the text
>>>>>>>>>> "<database_version>9</database_version>" before and
>>>>>>>>>> "<database_version>10</database_version>" after the problem was 
>>>>>>>>>> first
>>>>>>>>>> reported.) Following the change, SL4-based installations refused to
>>>>>>>>>> cooperate, yielding the "[Errno 256] No more mirrors to try" error
>>>>>>>>>> message upon "yum update". (SL5-based machines worked fine.) The 
>>>>>>>>>> issue
>>>>>>>>>> was discussed on the LCG-ROLLOUT list and the discussion later 
>>>>>>>>>> moved
>>>>>>>>>> to jpackage-discuss. People from the jpackage project then decided 
>>>>>>>>>> to
>>>>>>>>>> return to the old SHA digest.
>>>>>>>>>> 
>>>>>>>>>> After going back to SHA, a strange thing happened. For users who 
>>>>>>>>>> did
>>>>>>>>>> not empty their metadata cache inbetween, the "yum update" command
>>>>>>>>>> worked fine. But if they happened to either had run "yum clean all"
>>>>>>>>>> (as was suggested by somebody on the list) or if they started with 
>>>>>>>>>> a
>>>>>>>>>> fresh SL installation, "yum update" failed with the following 
>>>>>>>>>> error:
>>>>>>>>>>
>>>>>>>>>>   File "__init__.py", line 260, in doSackSetup
>>>>>>>>>>   File "repos.py", line 287, in populateSack
>>>>>>>>>>   File "sqlitecache.py", line 96, in getPrimary
>>>>>>>>>>   File "sqlitecache.py", line 89, in _getbase
>>>>>>>>>>   File "sqlitecache.py", line 359, in updateSqliteCache
>>>>>>>>>>   File "sqlitecache.py", line 251, in addPrimary
>>>>>>>>>>   File "sqlitecache.py", line 197, in insertHash
>>>>>>>>>>   File "sqlitecache.py", line 449, in values
>>>>>>>>>>   File "sqlitecache.py", line 441, in __getitem__
>>>>>>>>>>   File "mdparser.py", line 73, in __getitem__
>>>>>>>>>> KeyError: 'sourcerpm'
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Steps to reproduce the problem:
>>>>>>>>>> 
>>>>>>>>>> 1. Create two virtual machines. Install CentOS 4.8 and Scientific
>>>>>>>>>> Linux 4.8 on them.
>>>>>>>>>> 2. Run "yum update" on both. This is just to reduce the number of
>>>>>>>>>> yum's outputs later.
>>>>>>>>>> 3. Download the jpackage repository to /etc/yum.repos.d/
>>>>>>>>>>     http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/3.1/jpackage.repo 
>>>>>>>>>> 4. Run "yum update". This will succeed on CentOS 4.8 and fail on SL 
>>>>>>>>>> 4.8.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> After some investigation, I found a strange thing. Though "yum
>>>>>>>>>> --version" reports "2.4.3" on both platforms, the actual
>>>>>>>>>> implementations differ. Apart from the obvious configuration stuff
>>>>>>>>>> (e.g. cron.d files, /etc/init.d scripts) they differ also in the 
>>>>>>>>>> way
>>>>>>>>>> they handle cache. The following files are actually different:
>>>>>>>>>>
>>>>>>>>>>     config.py
>>>>>>>>>>     depsolve.py
>>>>>>>>>>     repos.py
>>>>>>>>>> 
>>>>>>>>>> The CentOS implementation has also one additional file:
>>>>>>>>>>
>>>>>>>>>>     storagefactory.py.
>>>>>>>>>> 
>>>>>>>>>> Unfortunatelly, I wasn't able to find the actual cause of the 
>>>>>>>>>> error.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> If you need to compare the files without installing the whole
>>>>>>>>>> distributions, please feel free to download the following archives:
>>>>>>>>>>
>>>>>>>>>>     http://petersbytes.net/tmp/yum-2.4.3-4.el4.centos.noarch.rpm
>>>>>>>>>>     http://petersbytes.net/tmp/yum-2.4.3-10.SL.noarch.rpm
>>>>>>>>>> 
>>>>>>>>>> There are two possible conclusions: either the CentOS developers
>>>>>>>>>> messed with the implementation without increasing the version 
>>>>>>>>>> number,
>>>>>>>>>> or the Upstream Vendor issued a new release without increasing the
>>>>>>>>>> version number and Scientific Linux did not catch with them. Either
>>>>>>>>>> way, I think the problem needs to be patched in SL, because I don't
>>>>>>>>>> think that jpackage people will fix the problem on their part -
>>>>>>>>>> they're testing their stuff on CentOS and everything works fine for
>>>>>>>>>> them.
>>>>>>>>>> 
>>>>>>>>>> Best regards,
>>>>>>>>>> 
>>>>>>>>>> Peter Slizik
>>>>>>>>> Hi Peter,
>>>>>>>>> Thanks for the information and the detailed analysis.
>>>>>>>>> I'm looking into this.
>>>>>>>>> I am pretty sure that we did not take any files out of yum 2.4.3. 
>>>>>>>>> We changed a file or two, but never took any out.  I'll look through 
>>>>>>>>> CentOS's yum rpm and see what the difference is and let you know if 
>>>>>>>>> a little bit.
>>>>>>>>> Thanks
>>>>>>>>> Troy
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>
>
>

-- 
Best regards,
  Valery Mitsyn
ATOM RSS1 RSS2
LISTSERV.FNAL.GOV