Re: Two suggestions for the installation process
On 2011-10-17 18:48, Yasha Karant wrote: I am in the process of installing SL 6.1 from the install DVD. Two suggestions: 1. A workaround that will allow installation without an Internet connection for those who chose the DVD that contains the necessary RPMs, albeit not necessarily the latest and greatest. Once installed, and the network is configured, then the usual update mechanism can install the latest and greatest production RPMs for the major release in question (e.g. SL 6). Fortunately, the 5.7 Network Manager interface and data for our residential 802.11 ISP network is close enough to the 6.2 version that I could copy data from a network activated laptop to the laptop upon which the 6.2 installation was being done. It is not that I do not know how to configure to get to the ISP service, but that 2. For a custom package selection, after one hits "next", put up a confirmation box so that one can continue the custom process, rather than moving forward with next -- allowing "back". Most of the installer's development happens in Fedora. Its entire UI is being redesigned right now, so your input may be valuable to them. If you're interested in giving feedback I suggest stopping by the #anaconda IRC channel on Freenode or sending mail to the anaconda-devel mailing list. http://fedoraproject.org/wiki/Anaconda/UX_Redesign http://www.redhat.com/archives/anaconda-devel-list/2011-June/msg00072.html http://blog.linuxgrrl.com/2011/09/26/anacondas-flow/ -- Garrett Holmstrom
Re: Kickstart auto choosing ARCH
On 2011-10-17 14:45, ~Stack~ wrote: On 10/14/2011 08:00 PM, Nico Kadel-Garcia wrote: On Thu, Oct 13, 2011 at 7:51 PM, ~Stack~ wrote: I am attempting to build a group of systems that boot off of PXE and auto-install with a kickstart file. I previously used a bundled package that for certain reasons is no longer applicable to the new system. So I am learning a lot about what happened behind the scenes of the bundled package. This particular stumbling block is: I have a mixed environment of 32bit and 64bit machines. I would like for the kickstart menu to auto-pick 32bit or 64bit. Is this possible? Yes, but it's really *sneaky*. You have to build an OS image, usually a tarball. %pre scripting sets up your fileysstems, you don't actually install *anything* with the normal install procedures, and you can run %post or %post --nochroot scripts to implant details of the hardware and especially network configuration. I did this on over 10,000 Linux servers in one month, along with tools that played 3-card monty to bundle thee relevant configuration files from old systems to new system. It was the *fastest* OS installer I've ever seen, in industry or personal use. Would it be possible for you to give a few more details on how you did this? I think I understand what you are saying but I am a ways off from doing it. If I understand, the %pre setups up the environment, detects the hardware, and then modifies the installer for the proper ARCH. Right? I am having numerous PXE issues crop up and while I am solving most of them just by searching the net, a few still elude me. I do appreciate all the help I am getting. It sounds more like what my current workplace does when setting up systems for QA: create an image of a minimal system, then PXE-boot a minimal OS that fetches the appropriate image and writes it to the disk instead of installing the system package-by-package as usual. I would like to learn about how to do this with anaconda, so please respond to me or the list as well, Nico. -- Garrett Holmstrom
Re: Kickstart auto choosing ARCH
On 2011-10-13 16:51, ~Stack~ wrote: I am attempting to build a group of systems that boot off of PXE and auto-install with a kickstart file. I previously used a bundled package that for certain reasons is no longer applicable to the new system. So I am learning a lot about what happened behind the scenes of the bundled package. This particular stumbling block is: I have a mixed environment of 32bit and 64bit machines. I would like for the kickstart menu to auto-pick 32bit or 64bit. Is this possible? Not with the kickstart alone. The install kernel's architecture must match that of the install tree, so your DHCP server has to supply kernels and boot options that match that of the architecture you want to install. If you set up a pxelinux-based PXE-boot system then you can do things such as display a menu (boot normally, install x86-64, install i386) for a few seconds, skip directly to a chosen action using a hardware address-specific symlink on your TFTP server, or choose an action based on the result of a simple hardware probe. Then you could use the same DHCP range for every system. If your server can supply systems with a "method=http://10.1.1.11/scientificlinux/6.1/$basearch/os"; directive for the correct architecture (whether via different DHCP options or a pxelinux system) then you can use a common kickstart file for both architectures by writing the architecture-specific bits to a file in %pre and %including it in the right place: firewall --enabled --ssh install rootpw --iscrypted mypasswordhash auth --useshadow --passalgo=sha512 # ... reboot %include /tmp/repos %pre basearch=`uname -i` cat << EOF > /tmp/repos url --url="http://10.1.1.11/scientificlinux/6.1/$basearch/os"; repo --name=sl-security --baseurl=http://10.1.1.11/scientificlinux/6.1/$basearch/updates/security EOF %end %packages --nobase openssh-clients %end -- Garrett Holmstrom
Re: DNS/DHCP problems
On 2011-10-05 12:15, Stack Kororā wrote: * I would like a server that serves up DHCP and DNS on a isolated LAN that does *not* have internet connection (one Ethernet cable from servers to giant bank of switches). * There will be three subnets: one is manually assigned 10.1.1.x, the DHCP server will have 10.1.2.x, and the DHCP/TFTPd server will server DHCP on 10.1.3.x. * All hosts should resolve their hostnames (and FQDN's! ) in the DNS regardless of if they are assigned via DHCP, manually, or PXE booted. * I would _really_ like to have a second server that is "failover" in case the first goes down, but I need the first working before I worry about that. I have a minimal 6.1 install with DHCP and BIND DNS. Setting up the DHCP is now pretty easy; I can reinstall the minimal OS and DHCP pretty quick now (it may not be 100% correct but it works). I still have not messed with the PXE booting on the DHCP yet, but I can get a system to receive a DHCP address on the 10.1.2.x network and talk to the systems I manually set on the 10.1.1.x and 10.1.3.x networks. Right now, DNS (using the named service BIND provides) still doesn't work right. The closest I have gotten was by accident. Some how (not sure how as it was an accident) I managed to get the DNS server to work with the DHCP server. So the two systems that were setup to get a 10.1.2.x DHCP addresses could ping each other by hostname only. EG: `ping host1` and `ping host2` would work and it claimed it was resolving to 'host1.project.local' but `ping host1.project.local` would fail as hostname not found. Not only was this by accident, but it was REALLY slow. It was at least 10 seconds from the command being run to the first ping. However, none of the other systems were resolvable and they couldn't resolve the DHCP systems. I restarted the named service and then it all stopped working. I can't ping anyone by host name anymore. I suggest you give some more details about your named and dhcpd configurations. Also remember that if your network is not connected to the Internet at all then you need to run your own root nameserver to make DNS work reliably. -- Garrett Holmstrom
Re: Upgrading from 32bit to 64bit
On 2011-09-23 17:14, Christopher Tooley wrote:
I may have solved this:
I removed /etc/rpm/platform:
rm /etc/rpm/platform
confirmed that rpm recognized that I had x86_64 arch:
rpm -E '%{_arch}'
x86_64
and then reinstalled python:
yum install python.x86_64
After doing a couple more installs of the x86_64 bit versions of some pam and
nss modules I was able to get back to working order. There are probably some
other things that may need to be fixed, but yum update isn't showing a whole
bunch of i386 packages anymore :)
For the record, I did an upgrade with a CD from i386 SL 5.4 to SL 5.7 x86_64.
Upon rebooting, yum would insist I had 386 arch, and the authentication method
I had was failing (it was looking for 64 bit versions of the pam modules and
nss modules).
For the record, note that migrating a system from one arch to another is
completely unsupported and is likely to cause it to behave unpredictably
in the future. That said, congrats for making it work on your system. ;)
--
Garrett Holmstrom
Re: Chrome SELinux problem on SL 6.1 64bit with NFS-mounted home directory
On 2011-09-22 7:21, Kay Diederichs wrote: Dear all, we installed google-chrome-stable-14.0.835.186-101821.x86_64 on both the NFSv4 clients, and the file server of our SL 6.1 cluster. On the NFS clients, Chrome cannot display certain webpages (e.g. the https://docs.google.com/?pli=1#owned-by-me page, nor the user's Google calendar); just the "Aw, snap" page is shown which indicates a problem. I found that "setenforce 0" on the client gets rid of the problem, but disabling SELinux is not an option. Weird enough, there is no proper setroubleshoot message in /var/log/messages on the clients when this occurs. But I find in /var/log/audit/audit.log the following: [root@client ~]# grep chrome /var/log/audit/audit.log | tail -1 type=SYSCALL msg=audit(1316684717.865:39632): arch=c03e syscall=56 success=yes exit=0 a0=6011 a1=0 a2=0 a3=0 items=0 ppid=4628 pid=4629 auid=1110 uid=1110 gid=20 euid=0 suid=0 fsuid=0 egid=20 sgid=20 fsgid=20 tty=(none) ses=4 comm="chrome-sandbox" exe="/opt/google/chrome/chrome-sandbox" subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null) I tried to feed this into audit2allow but get an error message. audit2allow needs the corresponding AVC denial; the SYSCALL message doesn't contain enough information. When searching for denials that happened within the past few minutes I suggest using ``ausearch --success no --start recent''. Its output is suitable for piping to audit2why or audit2allow. -- Garrett Holmstrom
Re: buildsys-macros rpm
On 2011-09-14 18:20, Nico Kadel-Garcia wrote:
And unfortunately, it can be confusing as all get-out for building
SRPM's for multiple releases. Subversion, for example, has different
dependencies in "el5" than in "el6", or in "f14" or later, and working
out the logic for selecting the right options for your OS is a bit of
an adventure when unpredictable and non-major-release "%dist" settings
are used.
Thankfully, when you're building with mock or you're building natively
on nearly anything that isn't el < 6, you can use other macros that are
designed to solve precisely this problem.
%if 0%{?el5}
# SL 5-specific dependency info
%endif
%if 0%{?rhel} >= 6 || 0%{?fedora}
# Bits that apply to both SL 6+ and Fedora
%endif
%if 0%{?suse_version} >= 1140
# Info for openSUSE 11.4+
%endif
%if 0%{?mdkversion} || 0%{?mgaversion}
# (and so forth)
%endif
--
Garrett Holmstrom
Re: buildsys-macros rpm
On 2011-09-13 12:26, Connie Sieh wrote: Note that %dist is defined in this rpm as %dist .el5 which is commonly not what TUV uses for security errata. An example of this is xulrunner-1.9.2.22-1.el5_7.i386.rpm In the above case "%dist .el5_7" was needed. For those who are curious/confused, when upstream build a package against the master branch for a major release (i.e. the one that will be the next point release) the %dist tag is ".el5". When they build a package from a maintenance branch for a given point release (e.g. for security errata) the %dist tag is instead ".el5_X", where X is a non-negative integer, because it builds against an older package set than the master branch. -- Garrett Holmstrom
Re: rpm --whatrequires vs yum
On 2011-09-05 15:27, Andrew Z wrote: On Mon, Sep 5, 2011 at 6:04 PM, Garrett Holmstrom mailto:ho...@physics.umn.edu>> wrote: On 2011-09-05 12:51, Andrew Z wrote: On Mon, Sep 5, 2011 at 3:43 PM, Garrett Holmstrom mailto:ho...@physics.umn.edu> <mailto:ho...@physics.umn.edu <mailto:ho...@physics.umn.edu>>__> wrote: On 2011-09-05 8:16, Andrew Z wrote: i'm not sure why there is a difference in the output of "rpm -q --whatrequires " and "yum remove" The rest of the packages depend on the .so file, not the package name: [5508] gholms@lux ~ % rpm -q --whatrequires 'libxklavier.so.15()(64bit)' libxklavier-4.0-7.el6.x86_64 libgnomekbd-2.28.2-2.el6.x86_64 kdebase-workspace-4.3.4-19.el6.x86_64 gnome-settings-daemon-2.28.2-11.el6.x86_64 control-center-2.28.1-25.el6.x86_64 gdm-2.30.4-21.el6_0.1.x86_64 gnome-applets-2.28.0-7.el6.x86_64 gnome-screensaver-2.28.3-8.____el6.x86_64 -- Garrett Holmstrom --- -- slowly descending into more confusion Garret, can you please run "yum remove libxklavier"? It would be better to just explain what is actually happening. The libxklavier package provides three things: [5610] gholms@lux ~ % rpm -q --provides libxklavier.x86_64 libxklavier.so.15()(64bit) libxklavier = 4.0-7.el6 libxklavier(x86-64) = 4.0-7.el6 The first of these is the library itself, namely /usr/lib64/libxklavier.so.15. rpmbuild automatically adds dependencies of this type to packages that link against shared libraries. The rest are used for things that depend on the package by name. For instance, this includes gnome-applets-2.28.0-7.el6.__x86_64's dependency on "libxklavier >= 4.0". By having yum remove the libxklavier package you remove all three of these, but your rpm query only searched for things that depend on the second. To get an accurate list of what directly depends on a package you must check *everything* that the package provides. [5616] gholms@lux ~ % rpm -q --provides libxklavier.x86_64 | sed 's/=.*//' | xargs rpm -q --whatrequires | sort | uniq control-center-2.28.1-25.el6.__x86_64 gdm-2.30.4-21.el6_0.1.x86_64 gnome-applets-2.28.0-7.el6.__x86_64 gnome-screensaver-2.28.3-8.__el6.x86_64 gnome-settings-daemon-2.28.2-__11.el6.x86_64 kdebase-workspace-4.3.4-19.__el6.x86_64 libgnomekbd-2.28.2-2.el6.x86___64 libxklavier-4.0-7.el6.x86_64 no package requires libxklavier(x86-64) -- Garrett Holmstrom Garrett, i think i'm hang up on the definition of "requires". To me it means "won't work if removed". But with this definition i have problem digesting the difference in "Yum remove" output and your (really cool) one line. That is exactly what "requires" means here. rpm enforces these dependencies by refusing to allow you to remove something when something else depends upon it. Yum knows this, so when you tell yum to remove a package it generally removes everything that depends upon it as well. So if you remove libxklavier.x86_64 then it will also remove everything in the list given by the above rpm query. Everything that depends on *those* packages, then, also gets removed, and so forth. This is what yum means by "removing for dependencies". -- Garrett Holmstrom
Re: rpm --whatrequires vs yum
On 2011-09-05 12:51, Andrew Z wrote: On Mon, Sep 5, 2011 at 3:43 PM, Garrett Holmstrom mailto:ho...@physics.umn.edu>> wrote: On 2011-09-05 8:16, Andrew Z wrote: i'm not sure why there is a difference in the output of "rpm -q --whatrequires " and "yum remove" The rest of the packages depend on the .so file, not the package name: [5508] gholms@lux ~ % rpm -q --whatrequires 'libxklavier.so.15()(64bit)' libxklavier-4.0-7.el6.x86_64 libgnomekbd-2.28.2-2.el6.x86___64 kdebase-workspace-4.3.4-19.__el6.x86_64 gnome-settings-daemon-2.28.2-__11.el6.x86_64 control-center-2.28.1-25.__el6.x86_64 gdm-2.30.4-21.el6_0.1.x86_64 gnome-applets-2.28.0-7.el6.__x86_64 gnome-screensaver-2.28.3-8.__el6.x86_64 -- Garrett Holmstrom --- -- slowly descending into more confusion Garret, can you please run "yum remove libxklavier"? It would be better to just explain what is actually happening. The libxklavier package provides three things: [5610] gholms@lux ~ % rpm -q --provides libxklavier.x86_64 libxklavier.so.15()(64bit) libxklavier = 4.0-7.el6 libxklavier(x86-64) = 4.0-7.el6 The first of these is the library itself, namely /usr/lib64/libxklavier.so.15. rpmbuild automatically adds dependencies of this type to packages that link against shared libraries. The rest are used for things that depend on the package by name. For instance, this includes gnome-applets-2.28.0-7.el6.x86_64's dependency on "libxklavier >= 4.0". By having yum remove the libxklavier package you remove all three of these, but your rpm query only searched for things that depend on the second. To get an accurate list of what directly depends on a package you must check *everything* that the package provides. [5616] gholms@lux ~ % rpm -q --provides libxklavier.x86_64 | sed 's/=.*//' | xargs rpm -q --whatrequires | sort | uniq control-center-2.28.1-25.el6.x86_64 gdm-2.30.4-21.el6_0.1.x86_64 gnome-applets-2.28.0-7.el6.x86_64 gnome-screensaver-2.28.3-8.el6.x86_64 gnome-settings-daemon-2.28.2-11.el6.x86_64 kdebase-workspace-4.3.4-19.el6.x86_64 libgnomekbd-2.28.2-2.el6.x86_64 libxklavier-4.0-7.el6.x86_64 no package requires libxklavier(x86-64) -- Garrett Holmstrom
Re: rpm --whatrequires vs yum
On 2011-09-05 8:16, Andrew Z wrote: i'm not sure why there is a difference in the output of "rpm -q --whatrequires " and "yum remove" The rest of the packages depend on the .so file, not the package name: [5508] gholms@lux ~ % rpm -q --whatrequires 'libxklavier.so.15()(64bit)' libxklavier-4.0-7.el6.x86_64 libgnomekbd-2.28.2-2.el6.x86_64 kdebase-workspace-4.3.4-19.el6.x86_64 gnome-settings-daemon-2.28.2-11.el6.x86_64 1:control-center-2.28.1-25.el6.x86_64 1:gdm-2.30.4-21.el6_0.1.x86_64 1:gnome-applets-2.28.0-7.el6.x86_64 gnome-screensaver-2.28.3-8.el6.x86_64 -- Garrett Holmstrom
Re: SL 6.1 Upgrade Options
On 2011-07-28 12:48, Morten P.D. Stevens wrote: rpm -Uvh http://ftp.scientificlinux.org/linux/scientific/6.1/i386/os/Packages/sl-release-6.1-2.i686.rpm A fun fact: SL 6's version of yum tracks the histories of packages and from where they originate so things like ``yumdb info $packagename'' are possible. But for this to work all package maintenance has to go through yum, which is why running the rpm command above can generate "rpmdb altered outside of yum" complaints later on. Yum can now install packages by URI, so you can just replace the call to rpm with a call to yum: yum install http://ftp.scientificlinux.org/linux/scientific/6.1/i386/os/Packages/sl-release-6.1-2.i686.rpm -- Garrett Holmstrom
Re: Supermicro IPMI watchdog issues.
On 2011-07-19 22:04, Kelsey Cummings wrote: This isn't exactly an scientific linux issue but I hope that folks here may be more likely to be using IPMI then some of the other lists. We have a series of Supermicro systems w/IPMI running RHEL 5.5. We're using IPMI primarily to monitor psu status and for the hardware watchdog support teamed with the watchdog service. 3 or 4 out of 8 identical systems have exhibited hardware watchdog triggered resets for no apparent reason. Best we can tell, despite the OS and hardware being perfectly healthy (no other errors, and the systems work fine after the watchdog is disabled,) the hardware watchdog is triggering a reset on its own, and worse, the boxes do not appear to come back from it. Anyone else seen similar issue or have any input? I have seen it. Under OpenBSD, in fact. I ended up shutting off the hardware watchdog after failing to find a fix. -- Garrett Holmstrom
Re: /dev/floppy
On 2011-06-19 10:27, Yasha Karant wrote: I fully understand that the /dev entries are created at boot time if the driver actually is present (generally, in kernel space, but there are exceptions where a driver crosses between kernel and user space). As it is clear that the driver is present, why is the driver not autoloaded during boot if the hardware is present? The kernel team chose to stop loading the floppy driver automatically due to problems with certain floppy disk controllers. [0] [1] In which file(s) in SL6 does one make the modification to force the existence of /dev/fd0 at each boot? As far as I can tell, SL6 is loading drivers for all of the other physical hardware on the unit. You should be able to create a file in /etc/modprobe.d that makes the floppy driver load automatically when a floppy drive is around, though I have no idea what the syntax for that is. [0] https://bugzilla.redhat.com/show_bug.cgi?id=599127 [1] http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=die-floppy-die.patch -- Garrett Holmstrom
Re: ntfs read/write on SL 6
On 5/22/2011 22:38, Zack Yovel wrote: hi, I'm new to SL, and I want to add ntfs support. I have SL 6 installed on my laptop, and I intend to install it on my desktop also. so: 1. What is the best way to add ntfs support to my running SL laptop? 2. Is there a way to add ntfs support to the desktop as part of the installation proccess? 1. Install ntfs-3g from EPEL. 2. If your goal is to install to a NTFS disk, no. Otherwise you might be able to add the EPEL repository as part of the installation process and select it that way. -- Garrett Holmstrom
Re: aspell dictionaries
On 4/7/2011 10:44, Bluejay Adametz wrote: Upstream seems to have removed aspell dictionaries (e.g. aspell-en) from el6 (they were in el5) which I need for setting up webmin/virtualmin. Looks like there's an aspell-en in epel. http://download.fedora.redhat.com/pub/epel/6/i386/repoview/aspell-en.html That and aspell-sk are the only ones I see there, but maybe that'll help. Upstream replaced aspell with hunspell and recommends that app writers port to it when transitioning to el6. [1] Of course, as you already found, aspell is still available from EPEL. [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Migration_Planning_Guide/sect-Migration_Guide-Package_Changes-Other_Package_Changes.html -- Garrett Holmstrom
Re: sl 6, kernel compile errors
On 3/30/2011 23:56, lee wrote: Hi... Has anyone any idea about this error. im trying to build a kernel module. rpm -qa | grep kernel kernel-firmware-2.6.32-71.18.2.el6.noarch kernel-headers-2.6.32-71.18.2.el6.x86_64 kernel-devel-2.6.32-71.18.2.el6.x86_64 kernel-2.6.32-71.18.2.el6.x86_64 kernel-debug-devel-2.6.32-71.18.2.el6.x86_64 error below is the make errors received... make -j2 CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm -> include/asm-x86 HOSTCC scripts/selinux/mdp/mdp HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/mdp/mdp.c:44:22: error: classmap.h: No such file or directory scripts/selinux/mdp/mdp.c:45:35: error: initial_sid_to_string.h: No such file or directory scripts/selinux/mdp/mdp.c: In function ‘main’: scripts/selinux/mdp/mdp.c:72: error: ‘secclass_map’ undeclared (first use in this function) scripts/selinux/mdp/mdp.c:72: error: (Each undeclared identifier is reported only once scripts/selinux/mdp/mdp.c:72: error: for each function it appears in.) scripts/selinux/mdp/mdp.c:76: error: ‘initial_sid_to_string’ undeclared (first use in this function) make[3]: *** [scripts/selinux/mdp/mdp] Error 1 make[2]: *** [scripts/selinux/mdp] Error 2 make[2]: *** Waiting for unfinished jobs scripts/selinux/genheaders/genheaders.c:13:22: error: classmap.h: No such file or directory scripts/selinux/genheaders/genheaders.c:14:35: error: initial_sid_to_string.h: No such file or directory scripts/selinux/genheaders/genheaders.c: In function ‘main’: scripts/selinux/genheaders/genheaders.c:59: error: ‘secclass_map’ undeclared (first use in this function) scripts/selinux/genheaders/genheaders.c:59: error: (Each undeclared identifier is reported only once scripts/selinux/genheaders/genheaders.c:59: error: for each function it appears in.) scripts/selinux/genheaders/genheaders.c:66: error: ‘initial_sid_to_string’ undeclared (first use in this function) make[3]: *** [scripts/selinux/genheaders/genheaders] Error 1 make[2]: *** [scripts/selinux/genheaders] Error 2 make[1]: *** [scripts/selinux] Error 2 make: *** [scripts] Error 2 https://bugzilla.redhat.com/show_bug.cgi?id=690773 -- Garrett Holmstrom
Re: GDM theme
On 3/17/2011 15:42, Vaclav Mocek wrote: On 03/17/2011 09:21 PM, Chris Tooley wrote: How do I change the theme for GDM in SL6? Not sure, it has been changed in Fedora 12/13 and SL6 uses the same way. If you want to change the background of the login screen, change the file "default.xml" in "/usr/share/backgrounds/"; there is a file "tuv.xml" which is . The rewritten GDM gets its configuration from gconf [1], so if you want to change any settings you should edit the "gdm" user's gconf settings. For instance, if I wanted to disable the login screen's restart buttons I would run this: gconftool-2 --direct --config-source xml:readwrite:/var/lib/gdm/.gconf -s /apps/gdm/simple-greeter/disable_restart_buttons --type bool false Rather than changing the XML files in /usr/share/backgrounds to change the login screen's background you can likewise edit another gconf setting: gconftool-2 --direct --config-source xml:readwrite:/var/lib/gdm/.gconf -s /desktop/gnome/background/picture_filename --type string /path/to/your/preferred/background The commands above are both from memory, so make sure to double-check them before trying them. ;-) [1] http://library.gnome.org/admin/gdm/2.28/configuration.html.en -- Garrett Holmstrom
Re: Debuginfo repositories
On 3/15/2011 12:08, Vaclav Mocek wrote: Another question: does RHEL6 use Presto plugin and delta rpm? Not for RHN repos. -- Garrett Holmstrom
Re: a few questions about SL admin best practises
On 3/14/2011 9:15, Konstantin Olchanski wrote: On Sat, Mar 12, 2011 at 12:06:56AM -0800, Garrett Holmstrom wrote: gholms@luna ~ % mount | grep ext /dev/sda1 on /boot type ext4 (rw) In the LVM way of things, if I connect this disk to another computer, would these /boot partitions collide and prevent the computer from booting? That volume is just a regular partition since /boot can't reside on a LV. -- Garrett Holmstrom
Re: a few questions about SL admin best practises
On 3/11/2011 18:51, Jon Peatfield wrote: I've not checked if it is still the case in EL6 but the default installer for EL4/5 strongly encourages people to always use the same 'VG' name when setting up LVM. IMHO this is a pain because if people follow that pattern then if/when a disk is moved to another machine (e.g. temporarily for diagnostics) the VG names on the disks clash. While there are ways round that problem it (seems to me) best to avoid it by allocating unique names for the VGs (we base them on the hostname and purpose e.g. system VG in 'fox' might be FoxSys0 - the mixed case is on purpose so they can't clash with other dev entries...) Also the LV names that the installer suggests are just plain stupid. I much prefer to name them after the purpose - they don't need to be unique so I usually use the name of the mountpoint (or root for / and swap for swap). Thankfully, when I last checked, anaconda added the system's hostname to the recommended VG name, making the default much more sane. gholms@luna ~ % mount | grep ext /dev/mapper/vg_luna-lv_root on / type ext4 (rw) /dev/sda1 on /boot type ext4 (rw) /dev/mapper/vg_luna-lv_home on /home type ext4 (rw) -- Garrett Holmstrom
Re: yum.conf ownership in SL6
On 3/11/2011 1:34, Stephan Wiesand wrote: You're not the only one, I found this extremely irritating as we use puppet to manage yum config. yum.conf is marked %config(noreplace). Once modified, updates won't overwrite it. This. Since you have a configuration manager you can just overwrite the file with that and be done with it. No need to rebuild any packages at all. Thanks for better mirroring upstream, SL people. :) -- Garrett Holmstrom
Re: SL6: Wrong baseurl for atrpms repo - renders yum unusable
On 3/4/2011 17:06, Jon Peatfield wrote: On Fri, 4 Mar 2011, Maciej Puzio wrote: Files /etc/yum.repos.d/atrpms.repo, atrpms-testing.repo and atrpms-bleeding.repo from package atrpms-repo-6-4.el6.x86_64 contain wrong baseurls: baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/stable baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/testing baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/bleeding Variable $releasever expands to "6.0", while atrpms keeps packages in directories el6-i386 and el6-x86_64 - that is, without ".0". As a result, ... I've never understood why yum doesn't provide a $majorreleasever variable as well as $releasever - for those repos where you want to have a single tree for each major release (but not for the point releases) and don't expect people to edit the .repo files. I *think* it would be an easy change to yum's config.py (where yumvars['releasever'] gets set). Perhaps it would be better to have a syntax in the .conf files to allow variables/values to be defined which will be expanded in .repo files (you can already use YUM0-YUM9 environment variables but those are horrid names). Yum 3.2.28 already has this type of feature. If you drop a file in /etc/yum/vars/ you can access the first line of its contents like a shell variable. For example, if you run ``echo 6 > /etc/yum/vars/majorreleasever'' then you can do exactly what you described. So rather than implementing it yourself it might be worth asking upstream to backport the code that already exists. Yum has no concept of a major or minor release; it just grabs the version of your sl-release package. AFAIK, SL is the only distro among its siblings that changes this version with every point release, so it is the only one on which the usual $releasever scheme breaks. -- Garrett Holmstrom
Re: Hyper-V Synthetic drivers on SL6
On 3/3/2011 14:18, Dave Capone wrote: I am not sure if I am missing something, but that link does not seem to point to a CentPlus kernel release that has the synthetic drivers enabled. It might not be enabled in that kernel either. If that is the case then your best bet is probably to compile your own kernel. -- Garrett Holmstrom
Re: Messing with the kernel (Was: Hyper-V Synthetic drivers on SL6)
On 3/3/2011 13:47, Brett Viren wrote: With the recent change in Red Hat's business tactics, messing with the kernel apparently just got more difficult: http://www.h-online.com/open/news/item/Controversy-surrounds-Red-Hat-s-obfuscated-source-code-release-1200554.html Or, maybe, now we should just consider Red Hat's kernels to come "pre-messed". -Brett. PS: my guess is that RH will not continue with this silly behavior. They should really know better. When I asked my account rep about this immediately after 6.0's release in November he responded (with typographical errors included), "There is work going on for kernel source browser but now ETA available for it." -- Garrett Holmstrom
Re: SL policy on errata that came out with the 5.6 release
On 1/13/2011 23:18, Urs Beyerle wrote: On 01/14/2011 07:49 AM, Garrett Holmstrom wrote: On 1/13/2011 9:29, Troy Dawson wrote: Morten P.D. Stevens wrote: Which release has the higher priority? SL 6.0 or SL 5.6? SL 6.0 has higher priority. My apologies if I'm missing something, but why does SL 6 get priority when SL 5 is the only one of the two with a production install base? What do you mean with "production install base"? SL6.0 will be based on RHEL 6 (6.0) SL5.6 will be based on RHEL 5 Update 6 (5.6) I meant that there are no production systems running SL 6 because there has yet to be a stable release. Thanks for your explanation, Troy. -- Garrett Holmstrom
Re: SL policy on errata that came out with the 5.6 release
On 1/13/2011 9:29, Troy Dawson wrote: Morten P.D. Stevens wrote: Which release has the higher priority? SL 6.0 or SL 5.6? SL 6.0 has higher priority. My apologies if I'm missing something, but why does SL 6 get priority when SL 5 is the only one of the two with a production install base? -- Garrett Holmstrom
Re: SL6 Alpha 1: dkms & yum-conf-epel ?
On 12/6/2010 8:55, Troy Dawson wrote: So, for SL6 is was planning on taking the blah-release from the various compatible repositories (epel, rpmforge, atrpms, elrepo) and putting them into the release, without any changes if possible. I see both pro's and con's with this. What is the point of duplicating release packages from other repositories when people are going to point yum or anaconda at them anyway? For instance, when one adds EPEL to a kickstart epel-release is installed automatically as part of the base group. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
SL 6 source repo name
To our friendly neighborhood SL developers... :-) When you folks get to that point in the process, could you please give SL's yum repositories for source packages a -source suffix rather than a -srpms suffix so one can download sources with the ``yumdownloader --source'' command? Thanks, Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: mirroring SL5
On 9/23/2010 3:56, Arnau Bria wrote: 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. SL's documentation just concerns what protocol you use to pull packages from other mirrors, not what you do with the stuff you download afterwards. If you're running a private mirror you should ideally download them with rsync to transfer less data. What you do with your mirror after that is up to you. To meed SL's mirroring guidelines you should just set cobbler to mirror with rsync. Note that it is rarely necessary for cobbler to run createrepo on rsync'ed repos since the mirror you're syncing from should already have good metadata. You can make cobbler skip the createrepo step by adding "--help" or an invalid option to the repo's createrepo_flags and you should still get a perfectly valid mirror without burning lots of CPU time re-hashing every package. If you are running a public mirror, some distributions will require you to *not* run createrepo so repodata remain consistent across all mirrors. I am not sure whether this is the case for SL or not. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: installing x86_64 first, then i386
On 9/18/2010 6:09, Arnau Bria wrote: Ok, so I'll use best for basic install/update and all for group install. Note that SL 5's installer uses the "all" policy, so after installation you would have to go back and prune out the i386 packages that you don't want. This should change to "best" in SL 6, which will at last make a default x86_64 install have no ix86 packages. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: installing x86_64 first, then i386
Arnau Bria wrote: 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". Like the man page says, when multilib_policy is set to "best" it will only install x86_64 when both versions are available but neither is installed. Since you already seem to have dpm.x86_64 installed, yum has nothing to do in your first test since you told it to only install the best arch available. When you made multilib_policy default back to "all" it noticed that the i386 version was not installed and offered to install it for you. is it a problem in group's creation? No. 2.-) Who may I configure yum so it install x86_64 packages always, and only i386 if needed or specified? Set multilib_policy to "best" and yum will install ix86 packages only when x86_64 versions are unavailable. You cannot specify which package architecture to install in a yum group, so you must instead install the ix86 versions yourself when both are available to yum while multilib_policy is set that way. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: ROOT on SL 4 and SL 5
On 8/24/2010 12:56 PM, Stephan Wiesand wrote: a minute after your mail, I received the announcement of Fedora 14 alpha - and it's supposed to come with ROOT. No clue who packaged it, but that src.rpm is probably a reasonable starting point. FWIW, Fedora's source RPMs [0] build on el5. Its maintainer applied for EL-5 and EL-6 branches, so perhaps if you mentioned it [1] he would build it for EPEL so everyone can use it. [0] http://koji.fedoraproject.org/koji/packageinfo?packageID=10727 [1] http://bugz.fedoraproject.org/root -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: SL release number
Franchisseur Robert wrote: -- Le (On) 2010-08-07 +0200 à (at) 13:41:11 grigory rybkin écrivit (wrote): -- Hello, As for the origianl question, lsb_release takes the version from /etc/redhat-release, which is provided by package sl-release (version 5.5 for SL 5.5). To see its info rpm -qf /etc/redhat-release -i Yes thanks, but my question was 'how to install yum-conf-5x ?' # yum shell erase yum-conf install yum-conf-5x run -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Note - Firefox 3.6 comming today for SL5
Akemi Yagi wrote: I wonder how the recent announcement of temporary closure of the 64-bit flash development would affect 64-bit firefox users: Either use the 32-bit flash-plugin with nspluginwrapper or use gnash. We're doing the former.
Re: Statistical Analysis of Strom Data
Larry Linder wrote: There is an R package for x86_64 EL5 on the "R" web site. There are a number of test suites available to make sure it is working correctly. SL adds R to its base repositories. Most everyone else gets it from EPEL. Either way you can most likely grab it from a repository you already use rather than getting it from somewhere else. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: version 5.5 install
On 24 May 2010, at 17:20, Pom Sailasuta wrote: > I would like to install Sc-Linux version 5.5 on my desktop which is a dual > boot system (Fedora core 2 and Win XP, hard drive capacity is 280GB, which I > think is dying). > I would like to do this on my new 800GB hard disk currently empty and mounted > on /dev/sbd with 3 partitions, first parition is for linux, second is for > swap and third covers the entire disk. > Ultimately, if this works out, I will remove my old 280GB drive and only use > the new 800GB drive, no dual boot this time, just linux. > > I would apprecaite any suggestion on how to do this. > I can not removed the old drive and just simply use this 800GB drive because > my Dell Optiplex GX620 does not have option for boot from CD or DVD, > I have only two options either hard drive or USB CD ROM. In this scenario I usually download the installer's kernel and initramfs, put them in /boot, add a GRUB entry for them, and boot from the hard drive. It will ask you for a URI for the installation tree, at which point you can point it to an appropriate place on a SL mirror. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: bug found in nfs v4 client - fixed in SL5
On 5/5/2010 8:34, Troy Dawson wrote: On 05/05/2010 01:18 AM, Doug Benjamin wrote: Does anyone have any information on RHEL 6 release date? My guess for the release date of RHEL6 is October or November. But others might have their ideas. RHEL 4 spent roughly 5.5 months in beta before its release. For RHEL 5 this was roughly six months.
Re: editor for ".sqlite" files
On 1 May 2010, at 20:09, g wrote: > i would like to edit/look at sqlite database files as used by mozilla > programs, firefox and thunderbird. > > i ran a search with yumex looking for an editor for ".sqlite" files and > found nothing described as an sqlite editor. > > am i mis-perceiving how such files are edited, or, is there nothing > available for sl5.x, or are sqlite files edited with a backend? Programs usually use the SQLite library to manage sqlite files. You might want to try using the "sqlite" utility, which provides a SQL command line interface to sqlite files. You could also have a look at the SQLite Manager add-on for Firefox.
Re: [OT] Re: xorg-x11-fonts-ISO8859-1-75dpi breaks when using rpm
On 4/29/2010 2:43, Faye Gibbins wrote: Well yes and no. I can, of course, use yum if I wanted. I'm a sys admin after all. However the way we configure our machines means that in essence yum is not available to be used to the installation of any rpms. On 28/04/10 16:57, Garrett Holmstrom wrote: Is the problem that you can't use yum at all or that you just can't use yum for a specific set of rpms? If it's the second then you could always try ``yum localinstall'' so yum can sort out the dependencies that *are* in SL's repos. ``yumdownloader --resolve'' will look at the packages you have installed on a system and download not only the package you ask for, but also any dependencies it lacks. You can then install them (hopefully all at once) with rpm.
Re: [OT] Re: xorg-x11-fonts-ISO8859-1-75dpi breaks when using rpm
On 4/27/2010 9:36, Tim Edwards wrote: On 27/04/10 16:16, Faye Gibbins wrote: Yes but we use the mdp devolved layer and I've asked if their repos are yum enabled and they say no. So unless my LM say's I can create a yum archive I'm not sure what else I can do. Can you get them to agree to at least temporarily let you use yum against the official Scientificlinux repos on the web? If not you're out of luck unfortunately. We used to have no access to yum repositories from our DMZ machines and it was very painful getting something installed with just rpm. One tip though, assuming you have a machine with a working yum (your desktop maybe?), is to do a 'yum whatprovides mkfontdir', where mkfontdir is what it complains is missing. That way you can see exactly which RPM is needed. Is the problem that you can't use yum at all or that you just can't use yum for a specific set of rpms? If it's the second then you could always try ``yum localinstall'' so yum can sort out the dependencies that *are* in SL's repos.
Fwd: Migrate Centos->Scientific Linux
(forwarding to the list) Begin forwarded message: > From: "Brunner, Brian T." > Date: 20 April 2010 14:49:35 CDT > Subject: RE: Migrate Centos->Scientific Linux > > > Needed:--to enable X and mouse (without which I have a command-line-only > system) > Have:system under upgrade RH7.3 (ancient) to Centos5.4 (boots new > kernel, yum works) > Trouble:-Making the loadable kernel module for the Nvidia GF6800 Xtreme > Tried:---Downloading from www.nvidia.com the kernel module build package > 195.36.15-pkg1.run > > Stumble:-Can't build nvidia 2.6 package against previously-installed 2.4 > kernel sources (D'Oh) and > > Stumble:-I don't have 2.6.18-164.15.1.el5.centos.plus (currently > installed kernel) sources that build (make->no rule to make > main/init.o). 2.6.18-164.15.1.el5 sources don't build either. > > It's obvious to me I have a solvable problem, is the nature/cure for the > problem obvious to anybody here?
Re: Migrate Centos->Scientific Linux
On 4/19/2010 8:54, Pablo Cavero wrote: What do you need migrate?? The Kernels, and Driver controlers are so close to Red Hat EL5, that the step from Centos to SL, will be Clean. You don't need recompiling the programs or applications, only if you have Kernel modules, you need rebuilt this, and this is all. The Plataforms are so close, that you may think in this like an update, and move your system from your Centos to SL5.4 with out problems. Do you use the CentOS Plus kernel? If you do, you will probably have to attempt to grab the right kernel module packages for the functionality you use that upstream's kernel doesn't provide. Beyond kernel modules you most likely won't encounter any problems migrating. In my experience the biggest problems one might run into are a few RPM file conflicts (for example, SL's yum RPM having a different set of files than CentOS's) and repo mixing issues depending on what third-party repos you set up. Now of course yum immediately makes you aware of the former, and the latter would happen regardless of distribution. Any problems SL itself would cause would likely arise from one the many subtle changes SL makes to its package set [1, 2]. I don't mean to sound like it will be difficult, because most of the time it really isn't, though I'm curious as to why one would migrate to SL from CentOS. [1] http://www.scientificlinux.org/distributions/5x/features/added [2] http://www.scientificlinux.org/distributions/5x/features/changed
Re: Nit regarding web file serving
On 3/31/2010 2:16, Dr Andrew C Aitchison wrote: On Tue, 30 Mar 2010, Robert E. Blair wrote: I have been lately quite annoyed by the fact that sometimes (not always) the new versions of powerpoint files (.pptx ones) do not cause openoffice to come up. You often need to save the file and then open it locally. It just dawned on my why. Many (ours included) web servers do not have pptx in the /etc/mime.types file so the files are not properly labeled as powerpoint. I believe that adding the following to the /etc/mime.types file of our web servers will fix it: change: application/vnd.ms-powerpoint ppt instead it should read: application/vnd.ms-powerpoint ppt pptx Similar changes are needed for doc->doc docx and for xls->xls xlsx Without this the web server identifies the files as binary and a browser that respects this simply allows you to download and not to open the file. It would be great if TUV would incorporate this into future releases of the mailcap rpm. You just set your server to use the wrong MIME types. The correct types for MSOOXML files are (apologies for any wrapping): application/vnd.openxmlformats-officedocument.presentationml.presentation pptx application/vnd.openxmlformats-officedocument.presentationml.slide sldx application/vnd.openxmlformats-officedocument.presentationml.slideshow ppsx application/vnd.openxmlformats-officedocument.presentationml.template potx application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx application/vnd.openxmlformats-officedocument.spreadsheetml.templatexltx application/vnd.openxmlformats-officedocument.wordprocessingml.document docx application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx I do agree, this should definitely be fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=578519 I hadn't realized that OpenOffice.org 2.x supported those formats. I wonder whether they made that change when they released OpenOffice.org 3.1 https://rhn.redhat.com/errata/RHBA-2010-0274.html (and/or RH Enterprise Linux 5.5) ? It was part of OO.o's 3.0 release, so one would certainly expect said support to be there. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Please consider addition of gnuplot42
On 3/26/2010 4:54, Steve Traylen wrote: Again if the EPEL review ever gets processed I will release and maintain that at a higher release. https://bugzilla.redhat.com/show_bug.cgi?id=570318 I recommend taking a look at the IUS Community Project site [1], whose entire purpose is to provide newer, side-by-side installable versions of commonly-used programs. You might have more success over there. [1] http://iuscommunity.org/ -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Which version support?
On 3/25/2010 14:00, Urs Beyerle wrote: If you have less or equal 4 GB of RAM, I would go with i386 instead of x86_64. Because of browser plugins (flash, java) and javaws. While I can't say anything about javaws, the 64-bit Flash plugin from Adobe and the 64-bit OpenJDK from SL worked just fine for me. If your Firefox profile has gotten used to Sun's JDK then it's trained to look in the wrong place for Java stuff, but it seems that new profiles don't appear to suffer from this problem. YMMV. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Please consider addition of gnuplot42
On 3/25/2010 14:43, Steve Traylen wrote: On Thu, Mar 25, 2010 at 8:36 PM, Troy Dawson wrote: OK, first problem. This requires wxGTK, which is not in Scientific Linux. Is that an important part? Can it be removed as a dependancy? Do we want to also put that into SL? Doh, I never thought to check that it actually built on SL without EPEL. Will get back to you. Adding your own copy of wxGTK instead of using EPEL's will create a nightmare for anyone who wants to use both your gnuplot42 package and anything in EPEL that depends on wxGTK. If it doesn't cause any significant problems, please consider just disabling the bits of gnuplot that rely on wxGTK so the dependency goes away. Or people could simply bite the bullet and use two packages from EPEL if gnuplot42 is that important to them. Less duplication between repositories means a reduced chance of dependency solving problems for the whole distribution. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: SL5.4 and Asus eee S101 netbook
William Lutter wrote: I've installed SL5.4 on an ASUS eee S101 netbook that my lab has purchased. Reviews say Fedora 10 and Ubuntu 9.10 work "flawlessly" (Ubuntu). http://www.newegg.com/Product/Product.aspx?Item=N82E16834220595 I usually use SL, so I've installed 5.4. lscpi indicates that the ethernet controler is Atheros (AR8121 ...) and wireless is atheros (AR928X). There are no "atheros" entries in the other card adaptor lists in the network configuration submenus. So, neither the ethernet card nor wireless adaptors are recognized? The README file from downloading atheros driver from madwifi shows latest download is 2/08. README says lspci should show it as "unknown" and a 0x168x vendor ID. lspci -v indicates both ethernet (8324) and wireless (1a3b:1067) are unknown devices. I'm guessing madwifi is not going to not work. Looks like I need special software. For lab usage, I don't need networking. It would be nice to update software etc. I'd install ubuntu if it gave me networking capability and which is not available via current RHEL5 SL distro. ath9k is included in 5.5's kernel. If you're feeling adventurous you can grab the sources for the beta and compile them yourself. Or you can wait a while for SL 5.5's release. http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.5.b1/html/Release_Notes/#id3488732 -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: fuse in SL 5.3
Troy Dawson wrote: Wayne Betts wrote: Something funny seems to be going on with fuse and the packages in the repositories for SL 5.3. The fuse package in the base repo (at least on the mirror I use) is version 5:2.6.3-1.SL. (That "5:" is an epoch number, right?) In any case, yum won't update to the package in the sl-security repo, which is version 2.7.4-8.el5. Also, there are no kernel-module-fuse-2.6.18-164* packages in the sl-security repository, which seems like an omission. Can someone either help me understand what's going on, or fix the sl-security repository with a "later" version of fuse and kernel modules for the various kernel errata levels above 2.16.18-128-*? -Wayne Betts STAR Computing Support at BNL First off, the kernel module. That is now in the kernel so there is no need for kernel-module rpm's. As for the epoch number on our version of fuse. That was introduced by Paul Rombouts back in 2006. I am not sure why, but since this same rpm was also used for fedora, and it mentions livna, I am suspecting that some other repository (livna, EPEL, dag, I don't know) already had an epoch in it. Now that SL has pulled the custom fuse-libs package from its repos so upstream's can go there instead, newly-installed systems get the right version as long as your base repo is at least version 5.4. But as you're seeing, existing systems with the old package have all the new updates masked by the old package's epoch. This cannot be fixed at the repo level without renaming or adding an epoch to the fuse-libs package every time it has an update for the rest of SL 5's lifetime. The easiest solution to the yum update problem is to: * Update your base repo to 5.4 so yum doesn't see the epoch'd package * Run ``yum downgrade fuse-libs'' on all affected systems Luckily this is a one-time fix that doesn't affect newly-installed systems. Unless, of course, your base repo is not yet updated to at least 5.4, in which case the problem will continue to show up on all of your SL 5 systems until you stop using the old base repo. I hope that helps! -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
pirut from fastbugs pulls in rhn
Hi folks, The new version of pirut (1.3.28-17.el5 from sl-fastbugs) hasn't had its dependency on rhn-setup-gnome commented out, so all of our desktops now have rhn installed. It might be good to fix that in the repos unless the change to using the version from upstream was intentional. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: SL and EPEL experiences?
On Jan 27, 2010, at 18:45, Michael Mansour wrote: > The main thing > that annoys me about EPEL is their refusal to add a repo tag on > their packages, that is, for an RPMforge package (or any other repo > like ATrpms, and the myriads of others) I always know their packages > from the package name eg: > > perl-Mail-DKIM-0.37-1.el5.rf.noarch > > That "rf" tells me it's from RPMforge. ATRpms is "at", other repo's > have their own tags. Packages I build personally have my own tags. > > With EPEL you have little idea what you used from their repo as > their package naming is no different to Red Hat's package naming. > Scanning for the RPM info (-qi) is little help as that's also > non-conclusive. > > If you want some history on this you can web search for discussion's > between Dag/RPMforge and EPEL maintainers on this topic. > > I like to strictly maintain servers I manage. No single repo will > supply every package I need, so for me, it's imperative I know which > 3rd party packages I use from which repo. When that is clouded by > not properly tagging package filenames then the many servers that > I manage become less manageable in my view an trouble-shooting bugs > and problems becomes that much harder. There are many ways you can deal with that: * Use ``yum list —-showduplicates $pkgname'' to find out where a package could have originated. * If you just use the binary packages directly from EPEL, inspect their build hosts or GPG signatures. * If you build the binary packages yourself, set the value of %dist to something more to your liking when you build them. * Place packages in subdirectories that correspond to where they came from. createrepo recurses into directories, after all. I once wrote a script that prints which packages are signed by each GPG key on the system. I could dig it out if you would find it helpful. Recent versions of yum keep track of what repositories each package comes from. Hopefully that feature will make it into 6.0. Hope that helps! -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: repoview change for errata area's
Troy Dawson wrote: I got it from the repoview site and built it myself. I had been having problems with 0.5.2 (I forget the error, I could dig it up if you want) and thought I would try the latest version. This got rid of the error, after I install python-hashlib. If people want to use it, I could put it up into contrib or testing. I like it. I've found I like the templates better than are in 0.5.2. Why not just use the one that's already in EPEL? -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: yum/wget do not work
Andrew Stallard wrote: http://rpm.livna.org/repo/5.4/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found redhat-release-5Server-5.4.0.3 centos-release-5-4.el5 sl-release-5.4-1 See the difference? It turns out that this problem is due to SL's differing from upstream in a fairly big way: SL changes the version of the sl-release RPM for every point release, whereas upstream changes only the release number of its release package. Hence the value of $releasever will change on SL for every point release, which breaks repo configurations. I mentioned this to the Livna maintainers and they added a bunch of symlinks so it quits breaking for SL 5.3 and up. Try it again - it should work now. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: yum/wget do not work
Andrew Stallard wrote: I can not use rpm/wget at all. Every time I try I get a bunch or erros li ke this: Loaded plugins: kernel-module http://rpm.livna.org/repo/5.4/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found Trying other mirror. http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/repo/5.4/i386/ repodat a/repomd.xml: [Errno 14] HTTP Error 404: Not Found Trying other mirror. ftp://mirrors.tummy.com/pub/rpm.livna.org/repo/5.4/i386/repodata/repomd.x ml: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. Trying other mirror. http://wftp.tu-chemnitz.de/pub/linux/livna/repo/5.4/i386/repodata/repomd. xml: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: livna. Please verify its path and try again Your Livna URI is broken because $releasever expands to 5.4, not 5 like their site expects. If you need libdvdcss you could get it from the dag repo; that repo seems to be the standard in SL. Either that or you need to update your livna.repo file. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: kernel >= 2.6.20 in SL5
From: "Jim Green" Date: Wednesday, December 16, 2009 9:59 AM > I'm trying to set up an SL5 client for a kerberos/LDAP/NFS4 server. I' m > getting > a kernel panic on the client in certain situations (writing to a file > which I do not > own but do have group write permissions) and from the oops I think that > this > is a kernel bug fixed in 2.6.20. Sadly, yum shows me only 2.6.18 kerne ls > and > the problem persists on the most recent (2.6.18-164.6.1.el15) > > So to my question : How can one install a kernel >= 2.6.20 on SL5 ? > I couldn't find SL rpms/srpms and googling for the experience of others > wanting to do this turns up little useful info. The right way to fix this problem would be to file a bug against the kern el package so upstream can backport a fix. They add bugfixes and new featur es by patching the same kernel version so the release can keep the same vers ion throughout its lifetime while still remaining useful. I once got curious and tried compiling and running a newer Fedora kernel on my RHEL system, and while I got it to work, running a newer kernel versio n is generally a very bad idea because the rest of the system is built with the assumption that it's running under Linux 2.6.18. You would likely be shooting yourself in the foot. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Why sl-srpms Instead of sl-source?
Troy Dawson wrote: Garrett Holmstrom wrote: Yumdownloader relies on repository names ending in -source to tell whether or not it should enable them when one runs ``yumdownloader --source $package'' to grab the source for an rpm. But unlike most repositories, SL's source repository is called "sl-srpms" instead of "sl-source", so the program doesn't work correctly for anything in the SL base repositories. Is there some historical reason for SL's strange naming scheme? Is it something that can change in a later release like 6.x? I had no idea that naming the repository had any impact on any part of yum. It's sorta a bad hack in my opinion. I would think that it would actually look at the rpm's in question. That being said, I have no problem renaming the source repositories. Was it historic. Yes. We said to ourselves "What should we name the repository for the source rpms?" "Well, they are always in a directory called SRPMS, let call it srpms." "But we should distinguish it so they know it's the Scientific Linux source rpms." "OK, then let's call it sl-srpms" And there you have your historic moment. :) I've never actually used yum and the source rpms. Does yum have any way of knowing that something is a src.rpm or not ... other than a repostory name? (I've looked in the man page and I'm not seeing anything) Yum recognizes a source rpm when it appears in a repository, but source repositories are always disabled because it is silly to download repo data for source repositories when sources are so rarely needed. Since they are disabled, yum has no idea what packages are there because it has no repo data for them. So when yumdownloader is asked to download a source rpm it has two choices: it can enable every repository on the system, which uses a lot of extra time, memory, and bandwidth, and then try to find the source rpm it is looking for; or it can enable only some of the repositories based on what information it does have, which usually means names. I agree, it is a sort of hack, but it is a necessary one that prevents yum from having to do a whole lot of extra work that can add minutes to the command's run time. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Why sl-srpms Instead of sl-source?
Yumdownloader relies on repository names ending in -source to tell whether or not it should enable them when one runs ``yumdownloader --source $package'' to grab the source for an rpm. But unlike most repositories, SL's source repository is called "sl-srpms" instead of "sl-source", so the program doesn't work correctly for anything in the SL base repositories. Is there some historical reason for SL's strange naming scheme? Is it something that can change in a later release like 6.x?
