trying to understand some dependencies
Hi all, I've installed SL4 x86_64 in a couple of hosts doing exactly the same (using kickstart then configuring them with puppet, which install some additional packages, but same in both hosts). After complete install I noticed that one host has 3 packages more than the other: diff td006.pic.es.out td007.pic.es.out 8a9 > ati-fglrx-8.18.6.1-0.SL.3.x86_64 416a418 > libmng-1.0.8-1.x86_64 576a579 > qt-3.3.3-16.el4.x86_64 I've looked for dependency tree and seems that ati-fglrx needs qt and qt libmng: [r...@td007 ~]# yum deplist ati-fglrx|grep qt dependency: libqt-mt.so.3()(64bit) provider: qt.x86_64 1:3.3.3-16.el4 provider: qt.x86_64 1:3.3.3-13.RHEL4 [r...@td007 ~]# yum deplist qt|grep libmng dependency: libmng.so.1()(64bit) provider: libmng.x86_64 1.0.8-1 dependency: libmng.so.1 provider: libmng.i386 1.0.8-1 dependency: libmng.so.1 provider: libmng.i386 1.0.8-1 dependency: libmng.so.1()(64bit) provider: libmng.x86_64 1.0.8-1 So the question is, who installed ati-fglrx and why... So I did a yum deplist of all packages installed in the host with more packages, and saw that some packages (redhat-lsb, xorg-x11-libs.x86_64, xorg-x11-Mesa-libGLU.i386) require libGL.so.1 which is provided by: dependency: libGL.so.1 provider: nvidia-x11-drv96-32bit.x86_64 96.43.07-1.0 provider: nvidia-glx.x86_64 1.0.7676-0.SL.2 provider: nvidia-x11-drv-32bit.x86_64 180.22-1.1.sl4 provider: nvidia-x11-drv96-32bit.x86_64 96.43.07-1.1.sl4 provider: nvidia-x11-drv173-32bit.x86_64 173.14.18-1.0 provider: nvidia-x11-drv71-32bit.x86_64 71.86.04-1.0 provider: nvidia-x11-drv-32bit.x86_64 180.22-1.0 provider: nvidia-x11-drv71-32bit.x86_64 71.86.04-1.1.sl4 provider: nvidia-x11-drv173-32bit.x86_64 173.14.18-1.1.sl4 provider: ati-fglrx.x86_64 8.18.6.1-0.SL.3 provider: nvidia-x11-drv100-32bit.x86_64 100.14.19-1.1.sl4 provider: nvidia-x11-drv100-32bit.x86_64 100.14.19-1.0 provider: dkms-nvidia-x11-drv-32bit.x86_64 180.51-1.nodist.rf provider: nvidia-x11-drv-32bit.x86_64 173.08-1.beta.el4.rf provider: nvidia-x11-drv.x86_64 1.0.9755-1.nodist.rf provider: nvidia-x11-drv-96xx.x86_64 1.0.9631-1.nodist.rf provider: nvidia-x11-drv.x86_64 1.0.9746-1.nodist.rf provider: xorg-x11-Mesa-libGL.i386 6.8.2-1.EL.52 so, I understand that in order to get libGL.so.1 installed yum must install all packages listed in above output. Am I right? so, the problem is that the node with less packages missed the install of ati-fglrx for some unkown reason, am I right? obviuolsy one node has 4 files less, the ones belonging to ati-fglrx. [r...@td007 ~]# locate libGL.so.1|sort /usr/lib64/ati-fglrx/libGL.so.1 /usr/lib64/ati-fglrx/libGL.so.1.2 /usr/lib64/libGL.so.1 /usr/lib/ati-fglrx/libGL.so.1 /usr/lib/ati-fglrx/libGL.so.1.2 /usr/lib/libGL.so.1 /usr/X11R6/lib64/libGL.so.1 /usr/X11R6/lib64/libGL.so.1.2 /usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 [r...@td006 ~]# locate libGL.so.1|sort /usr/lib64/libGL.so.1 /usr/lib/libGL.so.1 /usr/X11R6/lib64/libGL.so.1 /usr/X11R6/lib64/libGL.so.1.2 /usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 TIA, Arnau
Re: trying to understand some dependencies
On Fri, 19 Jun 2009 10:27:15 -0500 Troy Dawson wrote: Hi Troy, [...] > > So the question is, who installed ati-fglrx and why... > > > > My guess > puppet > Why? > Because puppet can work on generalities. You can say that you want > the driver for your video card, and it can figure out the correct > driver. Well, these are the packages (related to libGL) that I install with puppet: xorg-x11-devel.i386/x86_64 xorg-x11-Mesa-libGL.i386/x86_64 xorg-x11-Mesa-libGLU.i386/x86_4 they provide libGL, but those packages not explain (for me) why ati-fglrx is installed. Maybe, if they're not installed yet, yum solves dependency with ati-fglrx. does it make sense to you? [...] > > so, I understand that in order to get libGL.so.1 installed yum must > > install all packages listed in above output. Am I right? > > > > No, on this point you are wrong. > The dependancy is libGL.so.1, and *any* of the "provider" packages > can supply that package. It only has to install one of those > packages. If your repositories were just plain SL, it would be > xorg-x11-Mesa-libGL. But since you have (it looks like) sl-contrib > and dag enabled, it can pick whichever one it feels is right. Ok, so now some questions about yum algorithm come to my mind: 1.-) Every time that yum has to install a package that needs libGL (for this example) does it try to install a package that provithes that library? or it only sees that libGL is already installled and install the desired package? 2.-) fist time that yum knows that needs libGL, how does it take the decission on which package from all that provides libGl has to install? for example: host A: package A needs libGl, it installs ati-glrx first and solves dependency, and later, puppet installs xorg-x11-Mesa-libGL that also solves the problem. host B: package A needs libGL but as xorg-x11-Mesa-libGL is already installed, it does not need ati-glrx. am I saying something senseless? any link to yum internal? thanks for your reply Troy. > Troy Arnau
Re: trying to understand some dependencies
On Mon, 22 Jun 2009 11:29:35 -0500 Troy Dawson wrote: Hi Troy, [...] > If you are trying to track down what program installed the file, here > is where to look. > > Did it get installed during the initial install? > /root/install.log nop. > Did it get installed by puppet after the install? Yes. > ?? I really have no idea where to look, ask you local puppet expert ?? But puppet does use yum. So, I ask about yum, cause puppet only says what packages yum must install. Maybe the order on which packages are installed is important. Puppet conf don't care about that right now. > Did yum install it after the install? > /var/log/yum.log Yes, but I don't know how to know what package installs it. For example, yum.og from 2 hosts: Jun 18 16:24:58 Installed: freetype.i386 2.1.9-10.el4.7 Jun 18 16:24:58 Installed: expat.i386 1.95.7-4 Jun 18 16:24:58 Installed: libmng.x86_64 1.0.8-1 Jun 18 16:25:00 Installed: fontconfig.i386 2.2.3-13.el4 Jun 18 16:25:01 Installed: qt.x86_64 1:3.3.3-16.el4 Jun 18 16:25:02 Installed: xorg-x11-libs.i386 6.8.2-1.EL.52 Jun 18 16:25:04 Installed: ati-fglrx.x86_64 8.18.6.1-0.SL.3 Jun 18 16:25:04 Installed: xorg-x11-deprecated-libs.i386 6.8.2-1.EL.52 Jun 18 16:25:05 Installed: openmotif.i386 2.2.3-10.2.el4 Jun 18 16:22:36 Installed: freetype.i386 2.1.9-10.el4.7 Jun 18 16:22:36 Installed: expat.i386 1.95.7-4 Jun 18 16:22:38 Installed: fontconfig.i386 2.2.3-13.el4 Jun 18 16:22:38 Installed: xorg-x11-Mesa-libGL.i386 6.8.2-1.EL.52 Jun 18 16:22:39 Installed: xorg-x11-libs.i386 6.8.2-1.EL.52 Jun 18 16:22:43 Installed: popt.i386 1.9.1-26_nonptl Jun 18 16:22:47 Installed: sysstat.x86_64 5.0.5-19.el4 Jun 18 16:22:50 Installed: xorg-x11-deprecated-libs.i386 6.8.2-1.EL.52 Jun 18 16:22:51 Installed: openmotif.i386 2.2.3-10.2.el4 from expat there're diffenrces, one host installed fontconfig and the other libng before fontconifg. Is the order in yum log relevant? so, I'm trying to find out why these differences? > I am snipping the rest of the email ... just because I currently > don't have time to answer it right now, and I figured I'd get this > much out right not. Sorry Troy, did not get last sentnece. thanks for your reply. > Troy Arnau
yum group installed but yum does not know it
Hi all, I'm on # cat /etc/redhat-release Scientific Linux SL release 5.2 (Boron) and I'd like to install some yum groups. So I do yum groupinstall $group and works fine for some: # yum grouplist Loaded plugins: kernel-module Setting up Group Process Installed Groups: Development Libraries Editors Legacy Software Development Mail Server Network Servers PostgreSQL Database System Tools XFS Yum Utilities glite-WN (production - x86_64) But Development Tools seems to not be installed: Available Groups: Administration Tools Authoring and Publishing Cluster Storage Clustering DNS Name Server Development Tools [...] So, I try to install it: # yum groupinstall 'Development Tools' Loaded plugins: kernel-module Excluding Packages from dag Finished Setting up Group Process Package flex-2.5.4a-41.fc6.x86_64 already installed and latest version Package gcc-4.1.2-42.el5.x86_64 already installed and latest version Package redhat-rpm-config-8.0.45-24.el5.noarch already installed and latest version Package strace-4.5.16-1.el5.1.x86_64 already installed and latest version [...] Package cscope-15.5-15.1.el5_3.1.x86_64 already installed and latest version No packages in any requested group available to install or update and the group is still under Avaliable Groups Any one could help me to understand why this group does not appear as installed? TIA, Arnau
arch not showed when doing rpm -qa on SL 5.3
Hi all, I'd like to see package's arch when doing rpm -qa. I though it was not possible, but when talking to other admin he sent me this output: > [r...@wn060 ~]# rpm -qa | grep compat-gcc-34 > compat-gcc-34-g77-3.4.6-4.x86_64 > compat-gcc-34-c++-3.4.6-4.x86_64 > compat-gcc-34-3.4.6-4.x86_64 > [r...@wn060 ~]# rpm --version > RPM version 4.4.2.3 > [r...@wn060 ~]# yum --version > 3.2.19 > [r...@wn060 ~]# cat /etc/redhat-release > Scientific Linux SL release 5.3 (Boron) He does not know why he see that output. Now I'm on SL 5.3 but rpm does not show package arch: # rpm -qa|grep compat-gcc-34 compat-gcc-34-g77-3.4.6-4 compat-gcc-34-3.4.6-4 compat-gcc-34-3.4.6-4 compat-gcc-34-g77-3.4.6-4 compat-gcc-34-c++-3.4.6-4 compat-gcc-34-c++-3.4.6-4 And I have same versions as him: [r...@td006 ~]# rpm --version RPM version 4.4.2.3 [r...@td006 ~]# yum --version 3.2.19 # cat /etc/redhat-release Scientific Linux SL release 5.3 (Boron) Anyone could help to get that output? rpm should do it with no other options specified... The reason for that is that we use puppet for configuring our nodes, and it uses rpm for querying packages installed. If rpm does not answer with arch rpm does not know if the package is 386 or 64 bits TIA, Arnau
Re: arch not showed when doing rpm -qa on SL 5.3
On Tue, 20 Oct 2009 09:57:01 -0500 (CDT) Connie Sieh wrote: > Arnau, Hi connie, > yum install SL_rpm_show_arch Wow... > This will install a rpm that enables this. Many thanks! > -Connie Sieh Arnau
numpy and python-numpy installation problem
Hi all, I'm on SL5.3 : # cat /etc/redhat-release Scientific Linux SL release 5.3 (Boron) trying to install numpy and python-numpy, but seems that both versions available are in conflict: # yum list '*numpy*' Loaded plugins: kernel-module Excluding Packages from dag Finished Installed Packages numpy.x86_64 1.2.1-1 installed Available Packages python-numpy.x86_64 1.0.1-1.el5.rf dag # yum install python-numpy.x86_64 [...] ---> Package python-numpy.x86_64 0:1.0.1-1.el5.rf set to be updated --> Finished Dependency Resolution Beginning Kernel Module Plugin Finished Kernel Module Plugin Dependencies Resolved [..] Installing: python-numpy x86_64 1.0.1-1.el5.rf dag 2.5 M Transaction Summary Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 2.5 M Is this ok [y/N]: y Downloading Packages: python-numpy-1.0.1-1.el5.rf.x86_64.rpm | 2.5 MB 00:00 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Check Error: file /usr/bin/f2py from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 file /usr/lib64/python2.4/site-packages/numpy/COMPATIBILITY from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 file /usr/lib64/python2.4/site-packages/numpy/DEV_README.txt from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 file /usr/lib64/python2.4/site-packages/numpy/README.txt from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 file /usr/lib64/python2.4/site-packages/numpy/THANKS.txt from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 file /usr/lib64/python2.4/site-packages/numpy/__config__.py from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 file /usr/lib64/python2.4/site-packages/numpy/__config__.pyc from install of python-numpy-1.0.1-1.el5.rf.x86_64 conflicts with file from package numpy-1.2.1-1.x86_64 [...] If I try to get packages from http://download.opensuse.org/repositories/home:/ashigabou/RHEL_5/x86_64/ (comes form http://www.scipy.org/Installing_SciPy/Linux) and try localinstall, I get more complex deps problems. Anyone has been able to install both packages? Any tip on how to solve this? TIA, Arnau
Re: numpy and python-numpy installation problem
On Wed, 18 Nov 2009 10:13:50 -0600 Troy Dawson wrote: > Hi, Hi Troy, > I thought numpy and python-numpy were a different name for the same > program. Am I wrong? No idea :-) > Why do you want to install both packages? some users told me that they need some extra packages installed in our WNs, and numpy python-numpy where in that list. As I saw both in our repos I also though there were diff packages. > I don't know who wrote scipy's instructions, but they aren't correct > for Scientific Linux. > We have both scipy and numpy in Scientific Linux 5.3 and above. > The instructions for installing scipy > >yum install scipy Yep, no problem with scipy, and other packages in their list, only problems with numpy python-numpy... going to try without python-numpy, and see if it works for them. > Troy Thanks Troy! Arnau
Re: 'supervising' in process list
Think you're refering to: http://supervisord.org/ http://linux.die.net/man/3/supervisor HTH, Arnau On Thu, Mar 4, 2010 at 1:54 PM, Tim Edwards wrote: > I've asked the syslog-ng mailing list but got no response here. I'm not > sure if this is something related to syslog or a general thing but can > someone explain to me what the 'supervising syslog-ng' process is doing, > and where (what package or sub-system) it comes from? > > root 18622 1 0 08:53 ?00:00:00 supervising syslog-ng > > root 18623 18622 0 08:53 ?00:00:00 > /opt/syslog-ng/sbin/syslog-ng --no-caps > > Thanks > > Tim Edwards >
/dev/null perms modification
Hi all, has anyone had problems with /dev/null perms modification? Sometimes I find /dev/null with rw-r-r instead of crw-rw-rw in some nodes. I don't know who/what can do it and the purpose of doing so, but if it happens, systems becomes unstable. I'd like to hear some other people experience on that cause I'm really lost. *I see no info about in in dmesg/messgaes. TIA, Arnau
numpy / python-numpy and scipy
Hi all, I've looking for list archives but I didn't find the link. Sorry in advance if someone already asked about this. I find some strange dependency resolution on our nodes (sl5.3). When I try to install numpy I get the error: #yum -y install numpy [...] Package numpy is obsoleted by python-numeric, trying to install python-numeric-23.1-0.2.el5.rf.x86_64 instead Package matching python-numeric-23.1-0.2.el5.rf.x86_64 already installed. Checking for update. [...] but when I install scipy numpy gets installed. # rpm -qR scipy|grep numpy numpy I don't understand why numpy and not python-numpy ... Anyone could give an explanation on this? what package is the one that must be installed? (python-numpy I guess). TIA, Arnau
Re: numpy / python-numpy and scipy
Hi again, I forgot to mention that a host with numpy installed cannot install python-numopy, so I have to remove numpy with rpm -e --nodeps and then install python-numy. This is a problem when dealing with automatic installation (if pythin-numoy is installed before acipy, ok, but if not, then node has diff packages installed). Cheers, Arnau
Re: numpy / python-numpy and scipy
On Thu, 5 Aug 2010 12:56:40 +0100 (BST) Dr Andrew C Aitchison wrote: > On Thu, 5 Aug 2010, Arnau Bria wrote: [...] > Hmm. I have a newer python-numeric (not python-numpy): I have same pacakge installed: # rpmquery -i python-numeric Name: python-numeric Relocations: (not relocatable) Version : 23.7 Vendor: Scientific Linux Release : 2.2.2 Build Date: Sun 08 Apr 2007 12:08:22 AM CEST [...] > # rpmquery -i python-numeric > Name: python-numeric Relocations: (not > relocatable) Version : 23.7 Vendor: > Scientific Linux Release : 2.2.2 Build [...] but it not fit scipy dependencies. Removeing python-numpy removes scipy and pyfits # yum -y remove python-numpy Loaded plugins: kernel-module Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package python-numpy.x86_64 0:1.0.1-1.el5.rf set to be erased --> Processing Dependency: numpy for package: scipy --> Processing Dependency: numpy for package: pyfits --> Running transaction check ---> Package pyfits.noarch 0:1.3-4.el5 set to be erased ---> Package scipy.x86_64 0:0.6.0-6.el5 set to be erased --> Finished Dependency Resolution [...] python-numeric still installed: # rpm -qa|grep python-numeric python-numeric-23.7-2.2.2.x86_64 (I remove scipy too) install scipy again # yum install scipy pyfits Loaded plugins: kernel-module Excluding Packages from dag Finished Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package pyfits.noarch 0:1.3-4.el5 set to be updated --> Processing Dependency: numpy for package: pyfits ---> Package scipy.x86_64 0:0.6.0-6.el5 set to be updated --> Running transaction check ---> Package numpy.x86_64 0:1.2.1-1 set to be updated --> Finished Dependency Resolution numpy is there again :-) > > I see that your package python-numeric-23.1-0.2.el5.rf.x86_64 > has rf in the releae. Is it from rpmforge ? Seems that comes from dag: python-numpy.x86_64 1.0.1-1.el5.rf dag http://linuxsoft.cern.ch/dag/redhat/el5/en/x86_64/RPMS.dag/python-numpy-1.0.1-1.el5.rf.x86_64.rpm *we use local repo replica, but the package is in official dag repo. Thanks for your rpely, Arnau
Re: numpy / python-numpy and scipy
On Fri, 6 Aug 2010 03:54:51 +0100 (BST) Jon Peatfield wrote: > On Thu, 5 Aug 2010, Arnau Bria wrote: Hi, [...] > > but it not fit scipy dependencies. > > I *think* that scipy still uses Numpy not Numeric interfaces, though > I may have this backwards... > > > Removeing python-numpy removes scipy and pyfits > > There is no 'python-numpy' package in the sl5 standard repos, since > at least sl52 there has been a 'numpy' package which was version > 1.0.4 in sl52 and 1.2.1 in sl53 and later. > > [ We used to build numpy/scipy packages long long ago, which is why I > half remember this ] it comes from dag repo. Not sure what package installs it. Maybe an other dag package: from yum log: [...] Aug 03 16:46:18 Installed: lapack-3.0-37.el5.x86_64 Aug 03 16:46:18 Installed: compat-libf2c-34-3.4.6-4.x86_64 Aug 03 16:46:20 Installed: python-numpy-1.0.1-1.el5.rf.x86_64 Aug 03 16:46:21 Installed: suitesparse-3.1.0-1.el5.x86_64 Aug 03 16:46:23 Installed: scipy-0.6.0-6.el5.x86_64 [...] > > # yum install scipy pyfits > > Loaded plugins: kernel-module > > Excluding Packages from dag > > Finished > > Setting up Install Process > > Resolving Dependencies > > --> Running transaction check > > ---> Package pyfits.noarch 0:1.3-4.el5 set to be updated > > --> Processing Dependency: numpy for package: pyfits > > ---> Package scipy.x86_64 0:0.6.0-6.el5 set to be updated > > --> Running transaction check > > ---> Package numpy.x86_64 0:1.2.1-1 set to be updated > > --> Finished Dependency Resolution > > > > numpy is there again :-) > > Yes, scipy depends on numpy (not python-numeric or python-numpy)... > > I think the confusion is that you had installed a python-numpy which > provides the feature numpy, which scipy wants so unless you have > numpy installed removing python-numpy will need to remove anything > that depends on it (including scipy)... yes, but, if pythion-numpy provides numpy, why yum does not install pyhtonj-numpy which is the recommeneded one? > >> I see that your package python-numeric-23.1-0.2.el5.rf.x86_64 > >> has rf in the releae. Is it from rpmforge ? > > > > Seems that comes from dag: > > python-numpy.x86_64 1.0.1-1.el5.rf dag > > > > http://linuxsoft.cern.ch/dag/redhat/el5/en/x86_64/RPMS.dag/python-numpy-1.0.1-1.el5.rf.x86_64.rpm > > > > *we use local repo replica, but the package is in official dag repo. > > You mention python-numpy when the question was about > python-numeric :-) no, Andrew asked about pythion-numeric. From his reply: "I see that your package python-numeric-23.1-0.2.el5.rf.x86_64 has rf in the releae. Is it from rpmforge ? " > I'd suggest removing the python-numpy and any rf/dag versions of > python-numeric from your repos and do the tests with just the sl5 > repos enabled... I do need dag. removing it my question about numpy feature won't be answered. *Probably with only SL5 repos I won't have this problem cause only one package will server numpy feature. > -- Jon Thanks for your reply, Arnau
Re: numpy / python-numpy and scipy
On Fri, Aug 6, 2010 at 11:39 PM, Jon Peatfield < j.s.peatfi...@damtp.cam.ac.uk> wrote: > On Fri, 6 Aug 2010, Arnau Bria wrote: > > But your _answer_ mentioned python-numpy NOT python-numeric: > Wops, you're right!! I mixed names at some point and got confused from then!!! So my previosu mails were completly wrong! Sorry !!! > I'd suggest removing the python-numpy and any rf/dag versions of >>> python-numeric from your repos and do the tests with just the sl5 >>> repos enabled... >>> >> >> I do need dag. removing it my question about numpy feature won't be >> answered. >> >> *Probably with only SL5 repos I won't have this problem cause only one >> package will server numpy feature. >> > > > But the sl5 repo contains numpy - and it seems to be newer than the version > in python-numpy anyway. > > The sl5 numpy package is a newer version so should be preferred but the > name isn't the same. > > What does: > > rpm -q --whatrequires python-numpy > > report on your machines? > [r...@td132 ~]# rpm -q --whatrequires python-numpy no package requires python-numpy > If you can't remove these (obsolete) packages from your repos then the > package clashes will > do you mean removing python-numpy from dag? yep, that is possible. so this will solve numpy/python-numpy issue. On the other hand, scipy requires old numpy, despite it's obsolte by python-numeric. ok, clear now. sorry about the confusion on MY OWN question :-S Troy, should the sl5 numpy package provide a python-numpy feature and > obsolete/conflict python-numpy to avoid this problem for people who have > this dag version present in their active repos? (or perhaps ask dag to > remove python-numpy) > > -- Jon > Cheers, Arnau
installing x86_64 first, then i386
Hi all, I've added a i386 repo to my x86_64 nodes and I'm seeing that, when installing the node, yum sometimes installs many i386 packages and sometimes not. So, I'd like to set yum to install always x86_64 and then i386 (if needed or specified). Reading yum.conf man I saw : multilib_policy Can be set to ’all’ or ’best’. All means install all possible arches for any package you want to install. Therefore yum install foo will install foo.i386 and foo.x86_64 on x86_64, if it is available. Best means install the best arch for this platform, only. so seems that is the param I want. Yum tries to install x86_64 but if I specify foo.i386 it will install foo.i386 too. But then I noticed a strange behaviour (bug? feature?) when installing groups of packages. If multilib_policy is set to best, i386 packages from the group are not installed: # grep multilib_policy /etc/yum.conf multilib_policy=best # yum groupinstall glite-WN [] No packages in any requested group available to install or update # grep multilib_policy /etc/yum.conf #multilib_policy=best # yum groupinstall glite-WN [...] Dependencies Resolved Package Arch Version Repository Size Installing: dpm i386 1.7.4-7sec.sl5 gLite-WN-3.2-updates 3.9 M dpm-develi386 1.7.4-7sec.sl5 gLite-WN-3.2-updates 609 k dpm-libs i386 [...] so here comes some questions: 1.-) I'm not a "yum group" expert, but a group is a list of packages to be installed, so, why is yum bypassing i386 packages? Cause I can install all missing packages "by hand". is it a problem in group's creation? 2.-) Who may I configure yum so it install x86_64 packages always, and only i386 if needed or specified? Many thanks in advance, Arnau
Re: installing x86_64 first, then i386
On Fri, 17 Sep 2010 11:55:09 + g g wrote: > On 09/17/2010 09:24 AM, Arnau Bria wrote: Hi g, > i am not totally sure about this, but after going thru a lot of > problems with fedora 12 and 'repos', this may be reasonable answer. > > you need to structure your 'sl.repo.local' or what ever you call it to > have structure similar to what standard 'sl.repo' has. our local repos are SL/SLC replicas. SO they have same structure. > baseurl=http://ftp.scientificlinux.org/linux/scientific/54/$basearch/SL notice that there are some i386/noarch packages under that repo. Thanks for your reply, Arnau
Re: installing x86_64 first, then i386
On Fri, 17 Sep 2010 12:39:18 -0500 Troy Dawson wrote: > Hi Arnau, Hi Troy, > The problem is with groups, and as far as I know, has not been > resolved. There is no way to add arches to packages in a group. > So when you do group installs, it is going to follow the > multilib_policy. Thnks, clear now. * Opening comps file answered my question. As you say, no arch specified so multilib_policy does its job. :-( > If the policy is set to "best", and there is a > package for both i386 and x86_64, then it is going to pick the x86_64 > one and ignore the other. If the policy is set to "all" then it is > going to install both the i386 and x86_64. Ok, so I'll use best for basic install/update and all for group install. > That might be fixed in SL6, or maybe with a yum plugin, but I haven't > seen it yet. > Troy Thanks for your reply Troy, Cheers, Arnau
Re: installing x86_64 first, then i386
On Fri, 17 Sep 2010 11:00:58 -0500 Garrett Holmstrom wrote: thanks for your reply. Cheers, Arnau
disabling /tmp cleaning after reboot
Hi all, may I disable /tmp cleaning after reboot? If yes, could some one tell me what file do I have to modify? I see some hardcoded /tmp/* removals in /etc/rc.sysinit. *I don't find any clue on google. TIA, Arnau
SL5 update policy
Hi all, I'm looking for SL5 update policy, but only found the policy for errata: https://www.scientificlinux.org/documentation/faq/errata >From last Troy mail about kernel update: We plan on pushing this out next week with our usual weekly updates. September 28, 2010 So, is it every Thursday? TIA, Arnau
mirroring SL5
Hi all, SL5 documentation recommends ftp and rsync for mirronring the distribution. But I don't find mrepo and why it is not recommended. We're curretly using mrepo and preparing to move to cobbler (where we can select a new method). So, could someone explain me why mrepo is bad (or not recommended)? Many thanks in advance, Arnau
Re: mirroring SL5
On Thu, 23 Sep 2010 09:48:21 +0100 (BST) Dr Andrew C Aitchison wrote: Hi, > I'd never heard of mrepo or cobbler, but > I think you are working at a different level from the SL docs. Yep. > The SL doc recommends ftp and especially rsync as ways of > *transferring* updates from the master to the mirror. > > A quick look at the instructions for mrepo or cobbler suggests > that they are tools for serving mirrored data and that they can > both use rsync to collect updates from the master. Exactly. Maybe my question was not clear enough. My question was: why SL recommends "low level" tools and not "advanced" ones? Is there any problem with mrepo (which also does a cretearepo) ? Is a simple rsync/ftp the best way for doing the mirror? We're using mrepo (with createrepo) and we're moving to cobbler (a higher level tool for repos/distro/install...) and we can sleect a new way for mirroring distros. So, if mrpeo (with its createrepo, blah, blah...) is not recommmended, we're on time to change to pure rsync/ftp. Sorry if I did not ask my question propertly in my first mail. Cheers, Arnau
Re: mirroring SL5
On Thu, 23 Sep 2010 08:55:42 -0500 Troy Dawson wrote: > Hi, Hi, [...] > mrepo and cobbler are not true mirrors. [...] Thanks for the explanation. > So, in summary. You can use whatever program you want to pull > packages down. Both mrepo and cobbler can use rsync, so I would > suggest that. But I'm not going to document how to use either mrepo > or cobbler. For that you will need to look at those programs > documentation. I did not expect that. I only was wondering why other "mirror" tools where not mentioned in that wiki. After your explanation my question is answered. > Troy Thanks, Arnau
iotop & CONFIG_TASK_DELAY_ACCT
Hi all, I'd like to install & run iotop in my SL5 & SL4 boxes. Seems that I won't be able to run it in sl4 as it requires python 2.4. As it's not part of SL5 release I've downloaded it from it's site (http://guichaz.free.fr/iotop/) and tried to run it like ./iotop.py but it inmediatly complains about : CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO % grepping that at /boot/config-2.6.18-194.26.1.el5 seems that the option is enabled by default in our current kernel: # uname -r 2.6.18-194.26.1.el5 # grep TASK_DELAY_ACCT config-2.6.18-194.26.1.el5 CONFIG_TASK_DELAY_ACCT=y same happens with other mandatory kernel options: # grep CONFIG_TASKSTATS config-2.6.18-194.26.1.el5 CONFIG_TASKSTATS=y # grep TASK_IO_ACCOUNTING config-2.6.18-194.26.1.el5 CONFIG_TASK_IO_ACCOUNTING=y # grep CONFIG_VM_EVENT_COUNTERS config-2.6.18-194.26.1.el5 CONFIG_VM_EVENT_COUNTERS=y so, at this point I'm a bit confused and not sure if the problem is at app or I'm assuming something wrong with kernel's conf file. So, I'd like to ask other admin if someone is running that application in a sl5 box? if yes, any trick at installation time? TIA, Arnau
differences bewteen SL5 and SL6
Hi all, we have some (testing) SL6 installations and we're seeing that some things have changed between SL5 and SL6. I've read http://www.scientificlinux.org/distributions/6x/features/differences and found the yum.conf issue we faced, but now we've found that sendmail is not the default mail server, now it's postfix. So, I'm wondering if someone has some more detailed document about SL5/SL6 (or maybe this is RH5/RH6 related) differences. Many thanks in advance, Cheers, Arnau
Re: differences bewteen SL5 and SL6
On Tue, 13 Dec 2011 09:39:20 -0600 (CST) Connie Sieh wrote: HI, > > So, I'm wondering if someone has some more detailed document about > > SL5/SL6 (or maybe this is RH5/RH6 related) differences. > > The sendmail vs postfix is a RH5/RH6 difference. thanks. for the record. curriegrad2004 also sent me a link to: http://www.redhat.com/rhel/server/details/ it's not complete but I'm near. thanks to both for your replies. Cheers, Arnau
sl-release-6.1-2.src.rpm: md5sum problem
Hi all, When trying to install sl-release-6.1.2.src I get the errro: # rpm -Uhv http://ftp1.scientificlinux.org/linux/scientific/6.1/SRPMS/sl6-changed/sl-release-6.1-2.src.rpm Retrieving http://ftp1.scientificlinux.org/linux/scientific/6.1/SRPMS/sl6-changed/sl-release-6.1-2.src.rpm warning: /var/tmp/rpm-xfer.CEgdx0: Header V4 DSA signature: NOKEY, key ID 192a7d7d 1:sl-release ### [100%] error: unpacking of archive failed on file /usr/src/redhat/SOURCES/sl-release-6.1.tar.gz;4f3ce5a0: cpio: MD5 sum mismatch is there any problem with this package? Cheers, Arnau
Re: sl-release-6.1-2.src.rpm: md5sum problem
On Thu, 16 Feb 2012 05:09:53 -0800 Akemi Yagi wrote: Hi, > I suppose you are running the command on SL 5.x. Try using the --nomd5 > flag for rpm. Oh, did not know that is was a rleases releated issue. Thansk a lot! > Akemi Arnau
rsyslog not working after receiving HUP signal
Hi all,
I've some SL 6.3 hosts and I'm noticing that some of them have some
problems with rsyslog. After they rotate its logs, and they recieve HUP
signal, I hvae no more info in messages log file:
# cat /etc/logrotate.d/syslog
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null ||
true
endscript
}
# date
Mon Dec 17 09:28:07 CET 2012
# tail /var/log/messages
Dec 16 03:38:01 coresrv05 xinetd[23755]: EXIT: rsync status=0 pid=6355
duration=0(sec)
Dec 16 03:39:57 coresrv05 RTTEST: The actual HTTP_HOST (172.17.16.27) does NOT
match the configured WebDomain (rt-test.linux.crg.es). Perhaps you should
Set($WebDomain, '172.17.16.27'); in RT_SiteConfig.pm, otherwise your internal
links may be broken. (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:1193)
Dec 17 09:23:07 coresrv05 kernel: Kernel logging (proc) stopped.
Dec 17 09:23:07 coresrv05 rsyslogd: [origin software="rsyslogd"
swVersion="5.8.10" x-pid="1236" x-info="http://www.rsyslog.com";] exiting on
signal 15.
[...]
Now I'm running syslog in debug mode, but I find no useful information
(at least, I do not understand it as useful :-) ).
A reboot leaves syslog working fine.
Anyone has seen this before? any advice?
TIA,
Cheers,
Arnau
openmpi compilation options
Hi all, I'd like to know if openmpi (1.5.4-1.el6) provided by SL6.3 was compiled with the option: --with-sge I don't know where I should look for it, so, apart from the reply, if someone could tell me how to do it in the future I'll really appreciate it! TIA, Arnau
Re: [SCIENTIFIC-LINUX-USERS] openmpi compilation options
On Fri, 11 Jan 2013 08:55:31 -0600 Pat Riehecky wrote: Hi Pat, > Your best bet is to check the source rpm for compile options. Ok, I though I could get that in other way. > Pat Cheers, Arnau
