Well, we’ve been discussing our swap partitioning the last few days at work, and I finally got around to implementing it. Again, it proved to be kinda hard, basically because AutoYAST decides to do things differently. Read More
Tag: SLES10
SLES10 not installing boot loader in MBR
Well, as I mentioned in my earlier post, I had some trouble during the week. I was having issues with SLES10 installations not finishing during the bootloader installation phase. After trying out different flavors (as in 10SP2 x64/x86, …), and not having any luck with this, I went searching on Google as a last effort try. Guess what, yet again Google helped me out!
It was pretty simple. Putting /dev/cciss/c0d0 into /boot/grub/device.map as (hd0) made the grub-installer finish. Now, figuring out how to transfer those information during the installation proved difficult. I was just about to give up, while reading through the AutoYAST documentation, when it struck me. There is even an extra chapter for this stuff, so simply putting the following into my profile solved my issues:
|
1 2 3 4 5 6 7 8 |
<bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/cciss/c0d0</linux> </device_map_entry> </device_map> </bootloader> |
Configuring nagios-plugins-zypper
Since I’m running check_zypper via nrpe (which in turn runs as nobody), I need to set up sudo. In order for the plugin to work, we need to add the following line to /etc/sudoers (by means of visudo):
|
1 |
nobody ALL = NOPASSWD: /usr/bin/zypper sl, /usr/bin/zypper --non-interactive --no-gpg-checks --terse list-updates |
(Keep in mind this needs to be a single line …)
Creating a custom RPM repository for SMT
I spent some time yesterday figuring out ways on how to assign custom (as in self-built) RPMs to a installation using SMT. First you obviously need a “external” repository, that can be integrated into the SMT.
So we need to create repository someplace, where the SMT can go and grab it. I ain’t gonna cover the sharing part, since that is your job! I’m just gonna cover the steps on how to create the custom repository and how to integrate it into the SMT.
|
1 2 3 4 5 6 7 |
mkdir -p /srv/www/htdocs/custom-rpms/sles10-addons/rpm/{i586,x86_64,src} # copy some RPMs into the respective arch directories cd /srv/www/htdocs/custom-rpms/sles10-addons/ createrepo -o $PWD . gpg --genkey gpg -a --detach-sign --default-key <keyid> repodata/repomd.xml gpg -a --export <keyid> > repodata/repomd.xml.key |
That’s it, you just created a RPM-repository which you could use with YaST/zypper … But since you already invested time into getting SMT up and running, you might want to assign this repository based on the product that is being installed.
Say we have RPMs for SLES10 SP1/SP2/SP3 in this repository for the architectures i586 and x86_64. First you would take a look at the output of smt-list-products and get the ID for the products/architecture you want to assign this to. But since we’re lazy, you could just use this:
|
1 2 3 4 5 6 |
smt-setup-custom-repos $( for i in $( smt-list-products -f csv | egrep "SUSE-Linux-Enterprise-Server.*(i(.*)86|x86_64)" | cut -d, -f1 | sed 's,",,g' ); do echo -n "--productid $i "; done ) --name 'SLE10-Addons' --description 'Additional RPMs not part of SLES10 (i586/x86_64)' --exturl 'http://smt.home.barfoo.org/custom-rpms/sle-10-addons' |
And likewise for SLES11:
|
1 2 3 4 5 6 |
smt-setup-custom-repos $( for i in $( smt-list-products -f csv | egrep "SUSE_SLES.*(i(.*)86|x86_64)" | cut -d, -f1 | sed 's,",,g' ); do echo -n "--productid $i "; done ) --name 'SLE11-Addons' --description 'Additional RPMs not part of SLES11 (i586/x86_64)' --exturl 'http://smt.home.barfoo.org/custom-rpms/sle-11-addons/' |
Now, after smt-mirror has been executed the next time (either by yourself or via the predefined crontab entry), SMT is able to assign this repository to clients. While this isn’t completely true — SMT is able to assign this custom catalog before running smt-mirror, but it just doesn’t make sense, since it doesn’t contain any data — it still works.
Now, once you install the next SLES10/SLES11 (hopefully you enabled suseRegister, that actually gathers the channels), SMT will assign this “update channel” (jesus, why does Novell use so many words for the same damn thing ?), on top of all the others, to your system.
The only trouble with this is, that if you want to install packages from this repository during setup, it’s not gonna work. That’s because YaST (or AutoYaST) first install packages, preps the environment and after prebooting the new system, then runs suseRegister/customer_center … Screwed. Again.
Guess the only way is to add the original repository (no need to automatically assign this, since we can’t install during setup) into the add-ons section of my AutoYaST file.
Loooong time
It’s been very quiet around here, I’ve been rather busy with my real life. During that busy time, a lot of things happened. I switched jobs starting on October 1st, I’m now working in Karlsruhe (as compared to the 870km northern Greifswald). It may sound far, but it’s actually quite pleasant. You know, I was born down here (well not exactly here — 70 kilometers afar) and I still had the feeling that this is my home.
My tasks haven’t changed that much, I’m still doing
- VMware Virtual Infrastructure (as compared to vSphere)
- IBM Storage / Brocade SAN (was IBM Storage / Cisco SAN)
- Storage Virtualisation Controller (we were just buying that before I left)
- SUSE Linux Enterprise Server 10/11 – Deployment and Management (is pretty much the same as before)
What I don’t do any longer is Windows. That is, per se not completely right, since Virtual Center only runs on Windows boxen, but pretty much my whole work focuses on Linux and Storage. It’s as I argumented in the the interview a step ahead, since I’m specializing myself into a certain direction (whether or not that works out — I can’t tell yet. Time is gonna tell me that).
In my first week I spent some time getting to know the co-workers, working my head into the SVC (I already had a somewhat theroretical — and practical — insight, but not deep enough to actually make do with it). Next on my list is the AutoYaST environment for SLES-boxen / Kickstart for ESX(i), which (hopefully) enables us to standardize server installations using common schemas and partitions layout.
Also on the list is building a two-node test environment for the SVC so we don’t break the live environment with some tests we might be doing. Next on the list is some accouting to bring the settlements for the resource utilization based on vCPU/vMem upon a solid, up to date foundation.
New vmware-tools-kmp
Disclaimer: I don’t take any responsibility for faults within the software, I just provide the RPM’s! Feel free to ask me about stuff concerning these RPM’s, but I ain’t accountable if your stuff goes kaboom! Oh, and those RPM’s aren’t recommended or supported by VMware!
Since we recently upgraded our VMware Infrastructure to VMware vSphere, I finally had a chance to refresh the RPM’s for the KMP for 2.6.16.60-0.39.3-0.1 and 2.6.27.21-0.1. You can find the source RPM here.
- vmware-tools-kmp-bigsmp (SLES10: i586)
- vmware-tools-kmp-debug (SLES10: i586/x86_64; SLES11: i586/x86_64)
- vmware-tools-kmp-default (SLES10: i586/x86_64; SLES11: i586/x86_64)
- vmware-tools-kmp-kdump (SLES10: i586/x86_64)
- vmware-tools-kmp-kdumppae (SLES10: i586)
- vmware-tools-kmp-pae (SLES11: i586)
- vmware-tools-kmp-smp (SLES10: i586/x86_64)
- vmware-tools-kmp-trace (SLES11: i586/x86_64)
- vmware-tools-kmp-vmi (SLES10: i586; SLES11: i586)
- vmware-tools-kmp-vmipae (SLES10: i586)
- vmware-tools-kmp-xen (SLES10: i586/x86_64; SLES11: i586/x86_64)
- vmware-tools-kmp-xenpae (SLES10: i586)
Just a heads-up: while the modules itself work, VMware did something to the init-script which prevents it to load the modules unless you run vmware-config-tools.pl. I’m still in the process of sorting that out.
Novell KMP: vmware-tools-kmp and ibm-lin_tape-kmp
Disclaimer: I don’t take any responsibility for faults within the software, I just provide the RPM’s! Feel free to ask me about stuff concerning these RPM’s, but I ain’t accountable if your stuff goes kaboom … Oh, and those RPM’s aren’t recommended or supported by Novell or IBM!
After working with the novell-kmp solution, I think it’s actually rather easy to create a “Kernel Module Package“. In the end, I created two additional KMP’s, one for the tools component of the VMware-Tools shipped with VMware ESX, and another for the lin_tape SCSI driver, used by our IBM TS3400 as well as the IBM TS7530.
Some parts (especially the build system used within the VMware kernel modules) took some figuring out/playing around, but I actually got it working. Now each time I update the VMware-Tools I just need to install the new RPM, tada! No need for a fully fledged build environment on every box.
SUSE Linux Enterprise Server 10:
- ibm-lin_tape-1.24.0_2.6.16.60_0.37_f594963d-0.1 (i586, x86_64,
SRPM)- ibm-lin_tape-kmp-bigsmp (i586)
- ibm-lin_tape-kmp-debug (i586, x86_64)
- ibm-lin_tape-kmp-default (i586, x86_64)
- ibm-lin_tape-kmp-kdump (i586, x86_64)
- ibm-lin_tape-kmp-kdumppae (i586)
- ibm-lin_tape-kmp-smp (i586, x86_64)
- ibm-lin_tape-kmp-vmi (i586)
- ibm-lin_tape-kmp-vmipae (i586)
- vmware-tools-kmp-3.5.0_153875_2.6.16.60_0.37_f594963d-0.1 (
SRPM)- vmware-tools-kmp-bigsmp (i586)
- vmware-tools-kmp-debug (i586, x86_64)
- vmware-tools-kmp-default (i586, x86_64)
- vmware-tools-kmp-kdump (i586, x86_64)
- vmware-tools-kmp-kdumppae (i586)
- vmware-tools-kmp-smp (i586, x86_64)
- vmware-tools-kmp-vmi (i586)
- vmware-tools-kmp-vmipae (i586)
- vmware-tools-kmp-xen (i586, x86_64)
- vmware-tools-kmp-xenpae (i586)
SUSE Linux Enterprise Server 11:
- ibm-lin_tape-1.24.0_2.6.27.21_0.1-0.1 (i586, x86_64,
SRPM)- ibm-lin_tape-kmp-debug (i586, x86_64)
- ibm-lin_tape-kmp-default (i586, x86_64)
- ibm-lin_tape-kmp-pae (i586)
- ibm-lin_tape-kmp-trace (i586)
- ibm-lin_tape-kmp-vm (i586, x86_64)
- vmware-tools-kmp-3.5.0_153875_2.6.27.21_0.1-0.1 (
SRPM)- vmware-tools-kmp-debug (i586, x86_64)
- vmware-tools-kmp-default (i586, x86_64)
- vmware-tools-kmp-pae (i586)
- vmware-tools-kmp-trace (i586, x86_64)
- vmware-tools-kmp-vmi (i586)
- vmware-tools-kmp-xen (i586, x86_64)
Novell KMP: Useable version of ibm-rdac-ds4000
After some more tinkering, a lot more looking at the macros in /usr/lib/rpm/rpm-suse-kernel-module-subpackage and /usr/lib/rpm/suse_macros, I think I finally have a usable RPM’ified version of IBM’s Multipathing driver ready for use.
There is still one major annoyance left: each time you install a new ibm-rdac-ds4000-kmp RPM, you also need to reinstall the corresponding ibm-rdac-ds4000-initrd package, as the macros in /usr/lib/rpm don’t allow for custom %post or %postun.
As mentioned before, I’m gonna send them to LSI/IBM for review, and maybe, MAYBE they are actually gonna make use of that.
Without further delay, here’s the list of packages. Just a short explanation: you need mppUtil-%version, in order to install the ibm-rdac-ds4000-kmp.
- mppUtil-09.03.0C05.0030-0.2 (i586, x86_64,
SRPM) - ibm-rdac-kmp-09.03.0C05.0030_2.6.16.60_0.37_f594963d-0.2 (SRPM)
- ibm-rdac-kmp-bigsmp (i586)
- ibm-rdac-kmp-debug (i586, x86_64)
- ibm-rdac-kmp-default (i586, x86_64)
- ibm-rdac-kmp-kdump (i586, x86_64)
- ibm-rdac-kmp-kdumppae (i586)
- ibm-rdac-kmp-smp (i586, x86_64)
- ibm-rdac-kmp-vmi (i586)
- ibm-rdac-kmp-vmipae (i586)
- ibm-rdac-ds4000-initrd-09.03.0C05.0030_2.6.16.60_0.37_f594963d-0.2
- ibm-rdac-initrd-bigsmp (i586)
- ibm-rdac-initrd-debug (i586, x86_64)
- ibm-rdac-initrd-default (i586, x86_64)
- ibm-rdac-initrd-kdump (i586, x86_64)
- ibm-rdac-initrd-kdumppae (i586)
- ibm-rdac-initrd-smp (i586, x86_64)
- ibm-rdac-initrd-vmi (i586)
- ibm-rdac-initrd-vmipae (i586)
This package should be usable with System Storage DS4000 as well as System Storage DS3000 (they use the exact same source code).
I also know, that this solution isn’t really perfect. I’ve been looking at the %triggerin/%triggerun macros, but right now I can’t draw up a scenario (an easy one at that) to successfully use triggers in this situation. Only idea coming up looks like this:
- Put the triggers into ibm-rdac-ds4000
- When installing the kernel module packages,
write the kernelversion/-flavor into a temporary file(impossible, since the macros don’t let you influence %post), and then let the trigger create/update the MPP initrd
If anyone knows a better solution (as in easier, without the writing to a separate file), I’m all ears.
Novell KMP: KMP’ing IBM’s RDAC driver
Well, after yesterday’s lesson about getting the IBM RDAC to install for a not-yet-running kernel, I decided to take it a step further. Novell does have some documentation about KMP’s, which is actually rather good, especially the guide written by Andreas Grünbacher.
After a short tinkering, I got it actually working. I was kinda surprised, at how easily it actually is. One problem I still have to deal with, is modifying the %post, to generate the mpp-initrd image. For now, the KMP only contains the default %post, which updates the modules.* stuff.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
Name: ibm-rdac License: GPL Group: System/Kernel Summary: IBM Multipathing driver for DS4000 disk subsystems. Version: 09.03.0C05.0030 Release: 0.1 Source0: rdac-LINUX-%version-source.tar.gz BuildRequires: kernel-source kernel-syms BuildRoot: %{_tmppath}/%{name}-%{version}-build Requires(post): mppUtil-%{version}, module-init-tools Requires(preun): module-init-tools Requires(postun): module-init-tools %suse_kernel_module_package um %description This is the Engenio Linux RDAC Driver Package for IBM DS4000 Storage Subsystems. %package KMP Group: System/Kernel Summary: IBM Multipathing driver for DS4000 disk subsystems. %description KMP This is the Engenio Linux RDAC Driver Package for IBM DS4000 Storage Subsystems. %prep %setup -n linuxrdac-%{version} set -- * mkdir source mv "$@" source/ mkdir obj %build export EXTRA_CFLAGS='-DVERSION="%version"' for flavor in %flavors_to_build; do rm -rf obj/$flavor cp -r source obj/$flavor make -C /usr/src/linux-obj/%_target_cpu/$flavor modules M=$PWD/obj/$flavor done %install export INSTALL_MOD_PATH=$RPM_BUILD_ROOT export INSTALL_MOD_DIR=updates for flavor in %flavors_to_build; do make -C /usr/src/linux-obj/%_target_cpu/$flavor modules_install M=$PWD/obj/$flavor done %changelog * Thu May 07 2009 - 09.03.0C05.0030-0.1 - Initial package. |
Now, I’m kinda asking myself, why don’t more vendors submit their drivers to Novell in form of KMP’s … Anyway, I’m gonna send mine the LSI/IBM way, maybe they’ll pick it up …
IBM RDAC: Installing the driver for a (not yet) running version
Well, kernel updates on our Linux servers running IBM’s RDAC driver (developed by LSI) is a real pest .. especially if you have to reboot the box two times in order to install the drivers/initrd correctly.
So I sat down and looked at the Makefile. Turns out, it just needs four tweaks in order to be working with a different kernel version (which you have to pass using environment variables to make).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
--- linuxrdac-09.03.0C05.0030.orig/Makefile +++ linuxrdac-09.03.0C05.0030/Makefile @@ -25,7 +25,10 @@ # ####################################################################### -OS_VER := $(shell uname -r) +ifeq ("$(OS_VER)","") + OS_VER := $(shell uname -r) +endif + HOST_TYPE := $(shell uname -m) IS_SMP := $(shell (uname -v | grep -c "SMP")) # Kernel Distribution (either REDHAT or SUSE) @@ -170,7 +173,7 @@ copyrpmfiles : moduledep : @echo "Generating module dependencies..." - @/sbin/depmod $(uname -r) + @/sbin/depmod $(OS_VER) setupfiles : @install -o root -g root -m 0500 -D Makefile $(DEST_DIR)/opt/mpp/makefile.saved @@ -190,7 +193,7 @@ setupfiles : rm devicemapping; fi setupdriver: - @/opt/mpp/setupDriver.$(DIST) + @/opt/mpp/setupDriver.$(DIST) $(OS_VER) @if [ -f /etc/SuSE-release ]; then /sbin/insserv /etc/init.d/mpp; else @@ -266,7 +269,7 @@ uninstall_doer: @echo "The mpp RAMdisk image mpp-$(OS_VER).img has been removed. You may want to remove it from your boot loader config file." @if test ! -s /var/mpp/devicemapping ; then rm -rf /var/mpp/; fi @echo "Generating module dependencies..." - @/sbin/depmod $(uname -r) + @/sbin/depmod $(OS_VER) LINUX_RDAC_DIR := $(shell pwd) |
After that, a simple make KERNEL_OBJ=/lib/modules/2.6.16.60-0.37_f594963d-smp/build OS_VER=2.6.16.60-0.37_f594963d-smp install correctly installs the modules in /lib/modules, rebuilds the correct modules dependencies and builds the correct initrd image.