Re: loading drivers at install time
>> Further data points: >> Under the "Boot Options" in the BIOS, I see: >> >> +---+ >> - Boot Option #1 [PATA: SR244W ...] >> - Boot Option #2 [Intel(R) MB RAID] >> - Boot Option #3 [IBA GE Slot 0500 v...] >> - Boot Option #4 [[EFI Shell]] >> +---+ IBA GE Slot 0500 v... - is Preboot eXecution Environment stack on your network controller. [ http://en.wikipedia.org/wiki/Preboot_Execution_Environment ] EFI Shell - is (simple) Extensible Firmware Interface shell (allowing probably for diagnostics/firmware updates ... etc) [ http://en.wikipedia.org/wiki/Extensible_Firmware_Interface ] Jarek -- __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: yum test option?
Hello all. >> >> However, I want to do a manual yum install of a package and >> I don't see a "test" option in the man page, similar to the >> rpm --test option - an option I relied on heavily to keep >> from shooting myself in the foot. >> >> Is there a way to do a "test" with yum? So far google hasn't >> helped, or I'm not looking in the right places. You could use yum-tsflags yum plugin which allows passing arbitary flags to RPM transaction. 1) Install it: yum install yum-tsflags 2) Enable it: in /etc/yum/pluginconf.d/tsflags.conf 3) Example usage: # rpm -q xsane package xsane is not installed # yum --tsflags="test" install xsane ... Is this ok [y/N]: y Downloading Packages: (1/1): xsane-0.92-13.i386 100% |=| 1.3 MB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installed: xsane.i386 0:0.92-13 Complete! # rpm -q xsane package xsane is not installed The above is equivalent to using --test on rpm command line. Best Regards Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: XEN
> Why not try the Virtualization Guide coming with SL5 ;-) You could also try experimental SL(C)4 setup we use here at CERN [if you want to use it on SL(C)4]: base Xen setup: https://twiki.cern.ch/twiki/bin/view/LinuxSupport/XenHowTo virtualization framework: https://twiki.cern.ch/twiki/bin/view/Virtualization/GDVirtualization Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Yum autoupdate: overwriting configuration files
Hi Patrick Jussel wrote: > Hello! First: wrong list: for questions about SL CERN please ask on cern.linux newsgroup... > The last times when yum-autoupdate updated our Scientific Linux Cern 4 > machines both packages "cups" and "postfix" did not continue to run > properly. It seems, that yum-autoupdate overwrites the configuration > files, which is not the preferred way of course (in my opinion). So my > question now is: is this a bug or a feature, and how can I prevent yum > from overwriting configuration files? yum-autoupdate does not overwrite given package conf files: the package does (or doesn;t) it itself. Which config files have been overwritten in your case ? Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: how to reload audio drivers from CLI?
Hello > I just wonder how to reload audio drivers from > the command line? Just execute as root: /sbin/modprobe -r MODULE && /abin/modprobe MODULE To see what the MODULE argument should be check your /etc/modprobe.conf content (most likely this will be snd-card-0) Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: SL5 example site?
Hello all > I'm especially interested in adding installer classes > to anaconda cleanly. It isn't clear how the RHupdates/ directory really > works vs. building a new anaconda rpm. As Connie already pointed out RHUpdates/ works only for NFS installs. However one can make updates.img (in /images for SL5, or in /SL/base/ for SL4 and 3) out of the content of RHUpdates (see /build/scripts/make.updates.img.sh) and then this image is used for any install type. Its content supercedes what is in anaconda, so you will possibly need to create a corresponding directory structure in RHUpdates first. Best Regards Jarek PS: We have an updates.img for SLC4 at: http://linuxsoft.cern.ch/cern/slc45/i386/SL/base/ (as an example ..) __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Installing SL 4.5 on machines with SATA hard disk
Hello. > > Does anybody know any other solution or workaround? > If your system BIOS permits it, change "disk access" mode (can be called differently depending on BIOS manufacturer) to "RAID" or "Native / Legacy Mode IDE" (again, this can be called differently .. ) Cheers Jarek PS: Above works for most (all ?) Intel AHCI chipsets .. depends what you have in your box .. __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: [4.4 also] Re: 5.0 heads up: samba-3.0.25b update seems to need krb5-1.6
> rpm -U --force samba-client-previous.version > samba-server-previous.version samba-common.previous.version rpm -U --oldpackage ... would probably do ... Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: PXE non interactive boot prompt for GPT partition table
[..] > and read (something like) "/de/sdb has some GPT > table, I cant do much with it unless you reformat it. Do it [Yes] [Ignore]". > [..] > Is there a way to say that in the kickstart file so that I'm not > prompted for this at install? Try using: ignoredisk --drives=sdb in your kickstart file (this should work correctly from SL 4.5 on, even if not documented ;-) - for SL 4.4 version it may also work if you do not use clearpart directive in your kickstart file) Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Help! Can not build VSFTPD on my system!
Hello. Looks like (quite common) problem of picking up library for wrong architecture in linker path ... >>> [EMAIL PROTECTED] vsftpd-2.0.5]# make [..] >>> gcc -o vsftpd main.o utility.o prelogin.o ftpcmdio.o postlogin.o >> privsock.o tunables.o ftpdataio.o secbuf.o ls.o postprivparent.o >> logging.o str.o netstr.o sysstr.o strlist.o banner.o filestr.o >> parseconf.o secutil.o ascii.o oneprocess.o twoprocess.o privops.o >> standalone.o hash.o tcpwrap.o ipaddrparse.o access.o features.o >> readwrite.o ssl.o sysutil.o sysdeputil.o -Wl,-s `./vsf_findlibs.sh` >>> /lib/libpam.so.0: could not read symbols: File in wrong format ^ It should link against /lib64/libpam* in your case. (most likely you have /lib in your LD_LIBRARY_PATH ... get rid of it and then it'll link fine: or look at vsf_findlibs.sh to see why it picks up 32bit libraries instead of 64bit ones ...) Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: [5.1] Where to find kstars?
> P.S.: I'm also a bit shocked to learn that yum can find no Amarok > package... Most likely because it does not work nicely with not-the-latest GTK ... I have my private (old) amarok (1.4) rpms for SL(C)4 at: http://cern.ch/~jpolok/amarok/ .. you may give it a try if you do not find newer ... (be aware that on SL(C)4 the GUI - with few thousands song collection - is barely useable ... scrolls .. VEEERY slowly ... (but plays OK) due to old GTK libs ... I guess) Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: apt-get problem
Salamanka A. Serge wrote: I guess this folder should be used: ftp://ftp.scientificlinux.org//linux/scientific/30x but not sure In SL CERN 3.0.8 apt is using slc30x by default although the folder slc308 exists (have a look here http://linuxsoft.cern.ch/cern/ ) , so you may give a try. However be aware that we at CERN have stopped support for SL CERN version 3 (SLC3) in October 2007: in above mentioned repository you will not find anything any updates newer than that ... Jarek
Re: SL45 & cups
Hello all. I wonder whether there's a hidden switch when building rpm to make it work right with z-stream tags. If there is, the CentOS folks haven't found it either... I'm going to check whether TUV's rpm binaries get it right, unless someone beats me to it. unfortunately it is not really consistent: most src rpms use %dist tag which just needs to be defined at build time: the problem is that sometimes the tag is there .. but is not used in build process... The only way we found so far is just grepping on src.rpm name looking for .el4_5 .el4_6 ... etc in %release and then using --define %dist to rpmbuild accordingly ... Cheers Jarek
Re: yum update error SL(C) 4.6
Horton-Smith, Glenn wrote: > Hi. I was getting the same error. It seems to be related to the "Dag" > repository. > (ftp://ftp.scientificlinux.org/linux/extra/dag/redhat/el4/en/$basearch/dag/.) > If I disable that, e.g. by using "--disablerepo dag" in the yum command line > or simply by moving away dag.repo from /etc/yum.repos.d, the error goes away. > > Anyone from the SL team know what the problem is with this repo, which is > after all hosted (or at least mirrored) at scientificlinux.org? Looks like the dag repo metadata was broken last weekend: after next repository resync it should be OK again... Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Many SL users running on ia64 ?
Troy Dawson wrote: > I just wanted to second Martin's words. > We originally had Itanium because a lab or two had some Itanium > clusters, but those went away for whatever reason, and we eventually > dropped support due to nobody wanting it. Indeed, one of the labs being CERN, we still have a CERN version for ia64 available at: http://linuxsoft.cern.ch/cern/slc4X/ (currently this is SLC4.6) .. this receives all the regular updates and will continue to exist for still some time (until SL(C)4 support is stopped at CERN - not anytime soon ;-)) As for the version 5 ... for time being we do not plan to use it in immediate future on ia64 .. so I do not think we will provide it for SL community either ... Best Regards Jarek PS: > > https://www.scientificlinux.org/about/stats/arch.html Our own numbers show only 100-105 ia64 systems running SLC4 (out of which 95 are our own at CERN ..) __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: "4-head" display configuration
Hello. > We have an NVIDIA Quadro NVS 290 graphics adapter. We use NVIDIA Quadro NVS 400 / 440 for quad-view setups: I'm not sure that NVS290 can do this ? (according to: http://www.nvidia.com/page/quadronvs.html: NVS440 - Max Displays/Board = 4 NVS290 - Max Displays/Board = 2 ...) > We have installed the kernel-module-nvidia package, so we have some kind > of driver, but maybe not the best one. We use 96.43.01 nvidia driver at present (but 87 series worked too, with slightly different xorg configs, with "UseDisplayDevice" option AFAIR ..). > So far, we haven't even succeeded in configuring a dual head display. Frankly saying I never got too much luck with nvidia's own config tool , therefore I always did it manually ;-); You may need to change the following: - BusID lines in Device sections (you may see these on your system using /sbin/lspci) - ConnectedMonitor in Device sections (ie if you use DVI connected LCDs that would be "DFP,DFP" rather than "CRT,CRT") The config we use for 4 outputs is as follows: [..] Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" Screen 1 "Screen1" RightOf "Screen0" Screen 2 "Screen2" Below "Screen0" Screen 3 "Screen3" RightOf "Screen2" InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" Option "Clone" "off" Option "Xinerama" "on" EndSection [..] Section "Module" Load "dbe" Load "extmod" SubSection "extmod" Option "omit xfree86-dga" EndSubSection Load "fbdevhw" Load "glx" Load "record" Load "freetype" Load "type1" Load "dri" EndSection [..] Section "Monitor" Identifier "Monitor0" VendorName "Quadview Input 0" ModelName"Monitor 1400x1050" HorizSync31.5 - 90.0 VertRefresh 50.0 - 90.0 #Option "dpms" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Quadview Input 1" ModelName"Monitor 1400x1050" HorizSync31.5 - 90.0 VertRefresh 50.0 - 90.0 #Option "dpms" EndSection Section "Monitor" Identifier "Monitor2" VendorName "Quadview Input 2" ModelName"Monitor 1400x1050" HorizSync31.5 - 90.0 VertRefresh 50.0 - 90.0 #Option "dpms" EndSection Section "Monitor" Identifier "Monitor3" VendorName "Quadview Input 3" ModelName"Monitor 1400x1050" HorizSync31.5 - 90.0 VertRefresh 50.0 - 90.0 #Option "dpms" EndSection [..] Section "Device" Identifier "Videocard0" Driver "nvidia" VendorName "HP" BoardName "NVIDIA Quadro NVS 440 (GPU-0/0)" Option "NoPowerConnectorCheck" BusID "PCI:3:0:0" Option "ConnectedMonitor" "CRT,CRT" EndSection Section "Device" Identifier "Videocard1" Driver "nvidia" VendorName "HP" BoardName "NVIDIA Quadro NVS 440 (GPU-0/1)" Option "NoPowerConnectorCheck" BusID "PCI:3:0:0" Option "ConnectedMonitor" "CRT,CRT" Screen 1 EndSection Section "Device" Identifier "Videocard2" Driver "nvidia" VendorName "HP" BoardName "NVIDIA Quadro NVS 440 (GPU-1/0)" Option "NoPowerConnectorCheck" BusID "PCI:4:0:0" Option "ConnectedMonitor" "CRT,CRT" EndSection Section "Device" Identifier "Videocard3" Driver "nvidia" VendorName "HP" BoardName "NVIDIA Quadro NVS 440 (GPU-1/1)" Option "NoPowerConnectorCheck" BusID "PCI:4:0:0" Option "ConnectedMonitor" "CRT,CRT" Screen 1 EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor"Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes"1400x1050" "1280x1024" "800x600" "640x480" EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Videocard1" Monitor"Monitor1" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes"1400x1050" "1280x1024" "800x600" "640x480" EndSubSection EndSection Section "Screen" Identifier "Screen2" Device "Videocard2" Monitor"Monitor2" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes"1400x1050" "1280x1024" "800x600" "640x480" EndSubSection EndSection Section "Screen" Identifier "Screen3" Device "Vide
Re: hugemem
Hello. > > This leads me to another help request. Someone know how I can get the > .config of default and hugemem kernel? to study the differences? If you have both installed: Look at /boot/config-VERSION-RELEASE Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Scientific Linux & LHC ?
The grid is too, but for all I know some of it may run under XEN or some other emulation, so I suppose it could be SL4 under something else. It usually is SLC4 under SLC4 too (at CERN we added RHEL5 Xen to SLC4) ;-) Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Adding driver to installation
Hi all Not sure how the procedure at Driver Update Program worked for others, but we sucessfully use it now on SL(C)5.2 here at CERN for few drivers (updated e1000e, e1000, ixgbe (with ioatdma) etc) We intend to have it also for other add-on kernel modules (whenever possible ... some modules may not be cross-kernel version compatible due to usage of functions not in stable RHEL 5 kernel ABI ..) .. of course we will still need to produce driver disks for installations - but with the recent driver disk kit from RH this is also easier: not only such driver disk image contains kernel modules but also rpms and yum repository information: as a result during install time updated/add-on driver can be used and after install corresponding rpms are installed on the system (and since these are packaged according to DUP guidelines .. there is no need to upgrade them with each and every kernel upgrade) Sounds like less of work with kernel upgrades, right ? ;-) Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Adding driver to installation
Mark Stodola wrote: It can be found here: http://dup.et.redhat.com/ The documentation for ddiskit is rather sparse. Indeed, but fortunately the whole thing is not that complicated ;-) > I've yet to try the depmod.conf overriding to handle kernel updates when replacing a stock driver. It does work, that's how we ship our replacement e1000(e) and other drivers (just a file in /etc/depmod.d/, containing, for e1000 this: override e1000 * weak-updates/e1000) I'm still looking for a way to roll either the update disk itself or what it generates into the install media so it is hidden from the user altogether. While looking at DUP and digging in anaconda loader sources I've "discovered" something which does not seem to be documented at all , but which may be useful for you...: If you make a driver disk with ddiskit and store it at the root of install initrd.img as dd.img it will be auto-loaded and used by anaconda without any further action needed (ie no dd=.. specifying on command line): quite useful especially for network drivers with PXE installs ... Note: there is one rule to be respected for the above: Even if such driver disk will contain drivers made according to DUP - so kernel-version independent - it MUST be built against the right install kernel version ! (otherwise anaconda will silently skip it ...) Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: SL 4 CERN - glibc update
Nicola Maggi wrote: Hello to everyone, Excuse me in advance if I'm asking here something about Scientific Linux CERN but I wasn't able to find any related mailing list for users who are outside CERN. It the same as for users inside CERN: linux-us...@cern.ch (see on http://cern.ch/linux there is a link for subscription) I have a SL CERN 4.7 installed on a test machine, and I require to run some tests with a c++ library that requires glibc 2.5. My SL has installed this version of glibc packets: glibc 2.3.4-2.41.el4_71 glibc-common 2.3.4-2.41.el4_71 glibc-devel 2.3.4-2.41.el4_71 glibc-headers 2.3.4-2.41.el4_71 glibc-kernheaders 2.3.4-2.41.el4_71 Could anyone help me update those packets? I've tryed yum-update glibc but it seems like the SL4 repository only contains those ones. Generally speaking updating glibc to newer version on a given distribution (like from 2.3.4 to 2.5) is a non-trivial task: your distribution packages rely on 2.3.4 version and may/will not function properly if you upgrade it to 2.5: If you need to test something that requires glibc 2.5 why don't you install SLC5 (or SL5) that contains it instead ? Best Regards Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: SL 4 CERN - glibc update
Hello I read somewere around that it would be possible to build glibc-2.5 in a separate folder and don't let my system use it,just some application?Have you or someone else some info or any hints about were to start searching? You could modify the compat-glibc spec file from RHEL5/SL(C)5 to make it build 2.5 on 4: http://linuxsoft.cern.ch/cern/slc52/SRPMS/compat-glibc-2.3.4-2.26.src.rpm Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: SL 4.x problems with ATI fglrx after kernel-update
Hi all we currently have no real RedHat or CentOS systems running at Aachen. So, we cannot check if the problem with the drivers is "ScientificLinux"-made or a general problem of this kernel version. This seems to be generic problem with the -78.0.22.EL kernel (-89.EL too BTW): we see it as well here at CERN Unfortunately we are not able to find any fix/workaround: so far we tested the catalyst 9.5/9.4/9.3/9.2/9.1/8.8/8.7/ 8.28.8 fglrx driver and none works on SL(C)4 anymore. (Also none of fglrx driver versions we've tested - 9.5/9.4/9.2/8.7 - works on SL(C)5 with kernel -128.1.10.el5) So if anybody on this list got a version of fglrx that works: please let others know... As for unresolved symbols in driver: this is due to picking up wrong fglrx X11 driver version from ATI/AMD package: ie not the one for X11 release that 4 uses: x710 Cheers Jarek PS: We've asked RedHat about and they also do not know which version(s) of fglrx could work on 4/5 ... __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: dual head with ATI Radeon 43xx
Mark Stodola wrote: I run a 3650 on SL5.2 just fine. I don't see any reason why a higher end card on a slightly newer revision wouldn't work, except maybe kernel changes. Unfortunately this is what we seem to see now (2.6.18-128.1.10.el5 kernels and also on SL(C)4 2.6.9-89.EL): ATI drivers producing just black screen ... If anybody gets a working ATI/AMD fglrx driver on fully updated SL(C)4 and/or SL(C)4 (ie all updates, latest kernels) I would be grateful to know what is the exact version used ... Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: GoogleEarthLinux.bin fails to install [ADDITION]
$ sh GoogleEarthLinux.bin Verifying archive integrity...Error in MD5 checksums: 09923ec56a4b8ccbbe77f4fc280e3490 is different from 7e2ee64995f3a4b65373ce81d235cd00 has anyone successfully installed any version of google earth? Yes, just the current one (5... something) - be aware that it will not work with selinux enabled (unless somebody has a selinux policy written for it ?) It seems to me that the problem may be with your system setup: the installer script for calculating md5 sums needs following utilities: sh, head, wc, tr, md5sum, echo and cut (coming from bash and coreutils packages) Verify that your installation of the above is not corrupted: # rpm -V coreutils bash (there should be no output) and verify that /usr/bin/ and /bin/ where above utils can be found are on your PATH # echo $PATH You may also want to verify if your md5sum utility is the system one (and not some wrapper script for example): # which md5sum /usr/bin/md5sum and check if you have an utility called 'md5' (google installer will try to use that one if found) If above still does not help try running GoogleEarthLinux.bin installer using 'sh -x' ... this should show you the exact commands executed .. Cheers Jarek __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: SLC4 64bit no multicore kernel installed
Daniele Benedetti wrote: > Hi all, > I've installed the SLC4 64bit from the standard menu installation using > the network at CERN. > I have a standard cern desktop HP dc-5850 with a AMD Phenom X4. > I discovered that the installed kernel does not support multicore; > this is what I see from /proc/cpuinfo If a non SMP kernel has been installed and made default , it may indicate that your system has multicore disabled in BIOS: Some HP DC 5850 were delivered that way at CERN Please check in the system BIOS the 'multicore' (or VT ? .. sorry don;t remember how the actual option is called .. ) is enabled. Best Regards Jarek PS: Since you are at CERN, and are using CERN version I invite you to use our support line for CERN users: linux.supp...@cern.ch __ --- _ Jaroslaw_Polok ___ CERN - IT/FIO/LA _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Scientific Linux CERN: End of support for ia64 (Itanium II) architecture on 31st of March 2010
Dear Scientific Linux CERN ia64 users. Due to a low demand and very marginal usage of ia64 architecture in Scientific Linux CERN users community we would like to announce that we will stop the support for it on the 31st of March 2010. - No further Scientific Linux CERN 4 (SLC4) and Scientific Linux CERN 5 (SLC5) updates will be provided for ia64 platform after that date. - No future versions of Scientific Linux CERN for ia64 will be released. - Current versions of SLC for ia64 will be removed from our installation service. Existing ia64 SLC4/SLC5 CERN users are encouraged to migrate to Red Hat Enterprise Linux 4/5 systems. Please contact linux.supp...@cern.ch if assistance with this migration process is needed. We would like to thank all ia64 users, especially the CERN Openlab members for the support, feedback and hardware supplied through the past years. linux.supp...@cern.ch
Re: SL and EPEL experiences?
Hi Jim Green wrote: > Hi all > > I'm considering adding the EPEL repository > > http://fedoraproject.org/wiki/EPEL > > to a SL54 network of around 50 machines. Do any of the SL users > here have any experience of EPEL, especially incompatibilities, > problems etc ... We do: For our SL version - SLC(ern) we actually add the EPEL repo by default to our installations: No problems seen so far and no incompatibilities/conflicts: But that is to be expected: EPEL policy is to add only supplementary packages without changing/updating what is provided by the system. (that's to say we also use protectbase yum plugin to make sure that our system repositories take precedence over all others .. just in case and because we ship some packages which are in EPEL too - for historical reasons mostly ...) So far few hundred users are running since few months with this configuration and we haven;t received any complaints/problem reports. Cheers Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: SL and EPEL experiences?
> EPEL really only starts causing problems > when you decide to mix it with Dag/RPMForge as their packages can leapfrog > each other and break depsolving. Indeed, we've seen same problem here and dropped Dag/RPMForge from the list of repositories we propose to SLC5 users: replacing system packages/libraries by newer versions breaks the compatibility between SLC/SL/RHEL/CentoOS ... so in the longer run it was causing us more problems than bringing benefits .. Cheers Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Nvidia woes...
Alan Bartlett wrote: [...] > I don't use nVidia graphics cards and also should mention my > connection to the ELRepo Project "up front" but have you tried using > the kernel independent, kABI tracking kmod packages that the ELRepo > Project provides? [1] We do use some NVIDIA's but mostly with 96xx legacy series driver (however we may start using the 195 current series on our future hardware): So far we use nvidia packages we maintain ourselves but it would be interesting for us to change this situation... Speaking of which I'm little bit confused about nvidia kernel modules and kABI: checking http://dup.et.redhat.com/ and using kABI testing script gives following result on your kmod-nvidia-190.53-1.el5.elrepo.x86_64.rpm, nvidia.ko: ./abi_check.py ./lib/modules/2.6.18-164.el5/extra/nvidia/nvidia.ko Red Hat Enterprise Linux 5 ABI Checker -- ABI Checker version: 1.2 Module:./lib/modules/2.6.18-164.el5/extra/nvidia/nvidia.ko Kernel:2.6.18-194.el5 Whitelist: /usr/src/kernels/2.6.18-194.el5-x86_64/kabi_whitelist WARNING: The following symbols are used by your module WARNING: and are not on the ABI whitelist. symbol: acpi_walk_namespace symbol: agp_bridges symbol: acpi_get_handle symbol: acpi_os_wait_events_complete symbol: acpi_evaluate_object symbol: acpi_bus_get_device symbol: acpi_install_notify_handler symbol: acpi_evaluate_integer symbol: acpi_remove_notify_handler Are you using a different ABI Checker script ? .. since the version 1.2 does not seem to be happy about nvidia kernel modules here Best Regards Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_78_792_0795 _
Re: Machine-parseable errata?
>>> I'm using OCS Inventory to create a database of packages and their versions >>> for my SL machines. I'd like to write a script that goes through the >>> database and flags the ones that are out-of-date, indicating how important >>> an upgrade is. Is there a source of package versions and >>> errata that is easy to parse by machine? Not exactly what you have in mind , but probably could be changed to use data from OCS database instead of collecting data itself: http://pakiti.sourceforge.net/ Cheers Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: HP LaserJet M1212nf MFP
On 05/23/2011 08:33 AM, Zack Yovel wrote: > Anyone know if this model (HP LaserJet M1212nf MFP) can be installed on linux > and > how? Seems that it is supported by hplip project: http://hplipopensource.com/hplip-web/index.html (http://hplipopensource.com/hplip-web/models/laserjet/hp_laserjet_professional_m1212nf_mfp.html) note that you will need to replace the SL included hplip version (1.6.7 on 5 , 3.9.8 on 6) by at least 3.10.4 according to docs on HP site ... see: http://hplipopensource.com/hplip-web/install/manual/distros/redhatenterprise.html Cheers Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Install SL6 on RAID 0 on GA-890GPA-UD3H (chipset: AMD SB850 )
Hello On 05/26/2011 10:28 PM, Orion Poplawski wrote: > On 05/26/2011 07:29 AM, Zack Yovel wrote: >> >> 1. Hyper-V does not support RHEL. The only linux distro it supports is SUSE. > > I'm running a couple of CentOS 5.6 instances under Hyper-V. Horrible clock > drift > issues, but otherwise okay. > You may want to add: divider=10 clocksource=acpi_pm to kernel arguments in /etc/grub.conf to correct the clock drift problem. Best Regards Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: mount.cifs in sl6
mount.cifs and umount.cifs are included in cifs-utils package .. so you should be able to just: # yum install cifs-utils to have these installed on your system. Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: SL6 CERN?
Hello all On 07/19/2011 11:09 AM, Bernhard Linseisen wrote: > For an extensive answer you probably should ask the people at CERN IT > directly, but so far I can tell you: Thank you Bernhard for the answer , very nice summary ! I will just add a little: > About the default RPMs I don't know. Default set of packages for SLC installation differs from base SL or RH / CentOS: One of our users requirement is to be able to easily install a system which provides same package sets and configuration as our centrally managed interactive computing clusters. [ this set changes in between major releases and sometimes also in between minor ones ] > > If it is suitable outside depends what you mean by "suitable". > If "suitable" means "it runs" then I'd say yes. (At least it was like that > when I tried SLC5. I'm sure this is still the case: installation process detects if a given system is on a CERN network (during firstboot launch) and then performs (or not) CERN specific configuration adjustements ( AFS / Kerberos / time servers / sendmail / ... etc ...) > The question is more: Why would you need SLC6 instead of SL6? I couldn;t agree more: as it was already mentioned CERN provides SLC support to CERN users (well, of course if resources and time permits we also respond to outside users, but with lower priority) [ I guess this is similar in case of FNAL and the SLF used there or DESY and SLD variants .. ] Best Regards Jarek [ CERN Linux Support ] __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: SL6.1 MRG/realtime patch - good and bad news
Hello, Since we are "guilty" for these MRG builds let me comment on this too.. *However*, all is not perfect. For the majority of the time, everything is rosy - we've got three big dual-Xeon machines all merrily running 24hours/day. Then, one day, a reboot of the machine brought the system back up with a kernel panic (not syncing: Attempted to kill init!). We see similar problems with some of the systems running MRG kernel-rt here at CERN: in all cases so far these kernel Ooopses do happen on system boot and rebooting system again (sometimes twice) temporarily 'fixes' the situation. I would be interested in seeing more debug output from panics you see, to compare with what we experience... Would be interested in anyone shedding light of exactly what "dracut" is, Here: http://fedoraproject.org/wiki/Dracut - you'll find all information about Best Regards Jarek PS: Please use rather linuxsoft.cern.ch in your MRG repo setup not glitesoft.cern.ch - that one may point to different repositories in the future ... __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: comparison of packages on different repositories
Hello all Please add "SLC 6", the CERN flavour of SL. Contains many additional packages, some only useful at CERN, others generally useful, but avialable only to users inside CERN. Some correction: only small part of packages (alike oracle-instantclient where redistribution restrictions apply) is available to CERN users only, these are in 'cernonly' repository part. All others are available to everybody. Cheers Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Firefox 10 system wide preferences
Hello > I'm not looking for theoretical replies, but rather someone who is _actually_ > doing it and has it working. There must be someone out there who's got this > worked out on SL/CentOS/TUV. We do. with Firefox 10/Thunderbird 10 is is enough to drop files in preferences directories (without altering original ones): these are processed in sort order on startup. /usr/lib64/firefox/defaults/preferences/somefile.js (/usr/lib64/thunderbird/defaults/pref/somefile.js) (of course change lib64 to lib on 32bit platform) Now, unfortunately it does not work for browser startup page, apparently because of: https://bugzilla.redhat.com/show_bug.cgi?id=461880 (yes I know it is an old bug for FF 3.0 , but looking at spec file for FF 10 a workaround for this bug is still applied , which may not be necessary anymore) The workaround used prevents browser home page customization from js preferences: to get rid of it you would need to rebuild firefox disabling/changing it in spec file or repack all/some /usr/lib64/firefox/langpacks/langpack-*.xpi files changing content of chrome/*/locale/branding/browserconfig.properties Cheers Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Firefox 10 system wide preferences
On 03/29/2012 03:51 PM, Jaroslaw Polok wrote: > Hello > >> I'm not looking for theoretical replies, but rather someone who is _actually_ >> doing it and has it working. There must be someone out there who's got this >> worked out on SL/CentOS/TUV. > > We do. > > with Firefox 10/Thunderbird 10 is is enough to drop files in > preferences directories (without altering original ones): these > are processed in sort order on startup. > > /usr/lib64/firefox/defaults/preferences/somefile.js > (/usr/lib64/thunderbird/defaults/pref/somefile.js) > > (of course change lib64 to lib on 32bit platform) > > Now, unfortunately it does not work for browser startup page, > apparently because of: > > https://bugzilla.redhat.com/show_bug.cgi?id=461880 > > (yes I know it is an old bug for FF 3.0 , but looking at > spec file for FF 10 a workaround for this bug is still applied , > which may not be necessary anymore) Sorry, writing faster than processing info ;-): a different workaround but still causing same problem is in place instead. > > The workaround used prevents browser home page customization from js > preferences: > to get rid of it you would need to rebuild firefox disabling/changing it in > spec > file or repack all/some /usr/lib64/firefox/langpacks/langpack-*.xpi files > changing content of chrome/*/locale/branding/browserconfig.properties > Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/ODS _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Red Hat to provide Red Hat Enterprise Linux to CERN
On 16/04/14 18:18, Paul Griffith wrote: Does this have any impact on SL or is it just a slow news day ? http://finance.yahoo.com/news/red-hat-provides-cern-platform-13065.html I would say .. this is old news day .. we have been using RHEL (mostly in the area of databases plus few applications) since RHEL 3 ... So no - no impact on SL whatsoever And for comparison: we run more than 14.000 SLC systems at CERN... Best Regards Jarek
Re: a year later - CERN move to Centos - what are we doing?
If you use CERN CentOS 7 - please contact us at linux.supp...@cern.ch in case you encounter problems, if you use CentOS 7 - please use centos mailing lists... Now CERN Linux el7 comes in and I see the machines installed as 7.1 stay there, no automatic update to 7.2. Odd. Then here, I see same with CentOS7 - no automatic updates by default, no automatic updates to latest point release, 7.1 machines stay at 7.1. (I do not have any SL7 to compare) So I am puzzled by all this. Maybe I should ask google: "is centos7 supposed to self update to latest point release?" In both cases you should get automatic updates to latest release (while using default yum repository definitions), if this is not the case: please report the problem. Then I takes quite a bit of work to get automatic updates to work at all on CentOS7 (CERN el7 seems to be okey): a) The yum.cron package is crazy - each time I need to use yum, I have to wait until it finishes some useless background tasks. Then "yum remove yum.cron" has no effect because all the cron jobs are part of the main yum package. Go figure. b) the CERN yum-autoupdate package, which we use for SL6 updates, depends on a yum plugin not available anywhere (except from a CERN repo) and then actually does not work out of the box because of strange interaction with systemd - only works after a reboot. bb) then it does not send any email about updates - the el6 yum-autoupdate did this, where did this function go?!? again: if you encounter such problem(s) - please report. (Hmm... maybe I should try these auto update scripts from the SL7 repository?) So as they say, 1 step forward, 2 steps back. ... I think this discussion went totally off-topic for the SL mailing list .. Best Regards Jarek
