On Mon, 20 Dec 2010, Ken Schumacher wrote:
> On Dec 20, 2010, at 3:37 PM, Stephen John Smoogen wrote:
>
>> On Mon, Dec 20, 2010 at 12:44, Ken Schumacher <[log in to unmask]> wrot=
> e:
>>> Stephen,
>>> =20
>>> The node was originally installed with the LTS 4.4 release (Wilson=
> ). Until recently, we have been running daily yum updates against th=
> e node, so all the necessary errata and security updates have been ap=
> plied. Being a cluster head node, we can't jump the node up to a 5.x=
> release without proper planning and scheduling of downtime, etc. Ou=
> r user base expects the release to remain stable, so such upgrades ar=
> e carefully considered.
>> =20
>> Well I thought that applying all the updates would bring the system=
> to
>> 4.8 but I realize that Scientific Linux does keep old releases aliv=
> e.
>
> The statement that I am running 4.4 is based on the contents of /etc/=
> redhat-release. =20
>
> [root@jpsi1 kschu]# cat /etc/redhat-release
> Scientific Linux Fermi LTS release 4.4 (Wilson)
>
> [root@jpsi1 kschu]# cat /etc/yum.conf
> [main]
> cachedir=3D/var/cache/yum
> logfile=3D/var/log/yum.log
> pluginpath=3D/usr/lib/yum-plugins/
> debuglevel=3D2
> distroverpkg=3Dredhat-release
> tolerant=3D1
> exactarch=3D1
> plugins=3D1
>
>> What does 'rpm -Va --nofiles' tell you?
>
> [root@jpsi1 kschu]# rpm -Va --nofiles
> Unsatisfied dependencies for srvadmin-isvc-5.5.0-328.i386: srvadmin-s=
> yscheck =3D 5.5.0, libncurses.so.5
> Unsatisfied dependencies for srvadmin-deng-5.5.0-328.i386: srvadmin-s=
> yscheck =3D 5.5.0
> Unsatisfied dependencies for srvadmin-omacore-5.5.0-328.i386: srvadmi=
> n-syscheck =3D 5.5.0, libncurses.so.5
> Unsatisfied dependencies for mgmtst-racadm-5.5.0-364.i386: srvadmin-r=
> acadm5
> /var/tmp/rpm-tmp.28596: line 851: IntegrateWithGNOME: command not fou=
> nd
> Unsatisfied dependencies for mgmtst-racadm-5.5.0-364.i386: srvadmin-r=
> acadm5
> Unsatisfied dependencies for openipmi-33.13.RHEL4-1dkms.noarch: dkms =
>> =3D 2.0.9.3
> Unsatisfied dependencies for srvadmin-omauth-5.5.0-328.rhel4.i386: sr=
> vadmin-syscheck =3D 5.5.0
> Unsatisfied dependencies for delldset-1.7.0-119.i386: libbz2.so.1, li=
> bcrypto.so.4, libncursesw.so.5, libreadline.so.4, libssl.so.4, libsys=
> fs.so.1
>
>
>> How do you get the repodata for the systems (local mirror or remote=
> one)?
>
> [root@jpsi1 kschu]# yum clean all
> Loading "kernel-module" plugin
> Cleaning up Everything
> 0 headers removed
> 0 packages removed
> 7 metadata files removed
> 0 cache files removed
> 1 cache files removed
>
> [root@jpsi1 kschu]# cd /etc/yum.repos.d/
>
> [root@jpsi1 yum.repos.d]# grep enabled=3D1 *.repo
> fermi-errata.repo:enabled=3D1
> fermi.repo:enabled=3D1
> sl.repo:enabled=3D1
>
>
>> Can you try updating 1-2 packages directly? or does even yum list g=
> ive
>> you a 2GB process?
>
> Simply doing a 'yum list' runs up memory consumption. I ran the foll=
> owing for 90 CPU seconds and 'top' reports that the yum process consu=
> med 3 GB of memory. I used 'kill -15' to terminate the process.
>
> [root@jpsi1 yum.repos.d]# time yum -d 5 list yum
> Loading "kernel-module" plugin
> Yum Version: 2.4.3
> COMMAND: yum -d 5=20
> Installroot: /
> Ext Commands:
> yum
> Setting up repositories
> Baseurl(s) for repo: ['ftp://linux1.fnal.gov/linux/lts42/x86_64/sites=
> /Fermi/errata/Fermi/RPMS/', 'ftp://linux.fnal.gov/linux/lts42/x86_64/=
> sites/Fermi/errata/Fermi/RPMS/']
> fermi-errata 1.9 k=
> B 00:00=20
> Baseurl(s) for repo: ['ftp://linux1.fnal.gov/linux/lts42/x86_64/SL/RP=
> MS/', 'ftp://linux.fnal.gov/linux/lts42/x86_64/SL/RPMS/']
> sl-base 100% |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| 1.1 kB 00:00 =20
> Baseurl(s) for repo: ['ftp://linux1.fnal.gov/linux/lts42/x86_64/sites=
> /Fermi/Updates/', 'ftp://linux.fnal.gov/linux/lts42/x86_64/sites/Ferm=
> i/Updates/']
> fermi-base 1.1 k=
> B 00:00=20
> Reading repository metadata in from local files
> Setting up Package Sacks
> primary.xml.gz 1.4 M=
> B 00:00=20
> Terminated
>
> real=091m39.494s
> user=091m34.095s
> sys=090m5.039s
>
>
> Stephen, I appreciate your questions and your looking at this. I'm =
> hopeful that all the detail in this e-mail thread may help one of us =
> (or someone else on the mailing list) see where the problem may be.
>
> Ken S.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Ken Schumacher <[log in to unmask]> (o) 630-840-4579 (f) 630-840-3109
> Computing Div/HPC LQCD Group Loc: WH8E http://www.usqcd.org/fnal=
> /
> Fermi National Accelerator Lab; PO Box 500 MS 120 Batavia, IL 60510-0=
> 500
>
Since you state that you have other SLF 4.4 systems that do not have this
problem so what is the difference between them?
Does rpm have similar issues?
-connie
|
