carsten’s blog

Nachdem Microsoft/Skype anfang August 2014 diverse Skype User – vorallem im Linux Bereich – ausgesperrt hat (Zwang zu neuer Skype Version), hatte ich mich erstmal von Skype verabschiedet. Bei mir lief bis zuletzt Version 2.2.0.35 und ich war damit absolut zufrieden.

Alle neueren Versionen waren nicht mehr mit der SUSE Linux Enterprise 11 Serie zu vereinen, da ein neueres QT verlangt wird. Nachdem meine Skypekontakte kaum dazu zu überreden sind sich für Alternativen zu begeistern habe ich mir dann doch etwas Arbeit gemacht
und ein QT Paket in Version 4.7 erstellt, welches Parallel und ohne weitere Systemauswirkungen installiert
werden kann und es somit ermöglicht die aktuellste Skype Version auch unter SLE 11 zu nutzen.

Hier nun die nötigen Schritte

Repository für QT 4.7 hinzufügen

user@host:~> zypper ar -f http://download.obs.j0ke.net/home:/netmax:/playground/SLE_11_SP3/ home:netmax:playground

qt-4.7 Pakete installieren (wird unter /opt/qt-4.7 installiert)

user@host:~> zypper -n in opt-libqt4-47-32bit opt-libqt4-47-qt3support-32bit opt-libqt4-47-sql-32bit opt-libqt4-47-sql-sqlite-32bit opt-libqt4-47-x11-32bit

Pulseaudio Pakete installieren sofern nicht vorhanden

user@host:~> zypper -n in pulseaudio pulseaudio-module-x11 pulseaudio-module-zeroconf pulseaudio-utilspulseaudio-lang

Aktuelle Skype Version herunter laden und installieren

user@host:~> sudo wget http://www.skype.com/go/getskype-linux-beta-suse -O /root/skype-4.3.0.37-suse.i586.rpm
user@host:~> sudo rpm -ivh /root/skype-4.3.0.37-suse.i586.rpm

Skype Startscript anlegen

user@host:~> mkdir -p ~/bin
user@host:~> cat > ~/bin/skype << EOF
#!/bin/bash
LD_LIBRARY_PATH=/opt/qt-4.7/lib/ /usr/bin/skype
EOF

user@host:~> chmod +x ~/bin/skype

Gegebenenfalls die .desktop Dateien / Applikationslinks auf das neue Script in ~/bin/skype verweisen lassen damit auch Starts per Icon Klick funktionieren.

Während einiger Wartungsarbeiten und einem damit verbundenen Kernelupdate auf die derzeit
für SLES 11 SP2 aktuelle Kernel Version 3.0.80 bin ich auf einen Fehler in Verbindung mit DRBD gestoßen.

Das Update selbst liefert keine neuen drbd kmp Pakete mit, sondern verwendet weiterhin eine Vorgängerversion (8.4.2_3.0.51_0.7.9-0.6.6.4)

Der Fehler äußert sich direkt beim Laden des drbd Moduls mit folgender Meldung:

[ 154.173134] events: mcg drbd: 3
[ 154.174916] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 154.174927] IP: [] cleanup_module+0xb0/0x150 [drbd]
[ 154.174949] PGD 7927f8067 PUD 7a0a83067 PMD 0
[ 154.174954] Oops: 0000 [#1] SMP
[ 154.174959] CPU 7
[ 154.174960] Modules linked in: drbd(+) crc32c libcrc32c ip6table_filter ip6_tables iptable_filter ip_tables x_tables nbd usbbk netbk blkbk blkback_pagemap blktap xenbus_be gntdev evtchn mpt2sas scsi_transport_sas raid_class mptctl mptbase ipmi_devintf ipmi_si ipmi_msghandler dell_rbu(X) bridge 8021q garp stp llc bonding microcode fuse loop dm_mod joydev bnx2 usbhid hid sg ses enclosure sr_mod 8250_pnp ipv6 ipv6_lib pcspkr tpm_tis tpm tpm_bios i2c_piix4 i2c_core dcdbas(X) k10temp domctl 8250 serial_core rtc_cmos serio_raw button acpi_power_meter ohci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh_emc scsi_dh xenblk cdrom xennet edd ext3 mbcache jbd fan processor ata_generic pata_atiixp ahci libahci libata megaraid_sas scsi_mod thermal thermal_sys hwmon
[ 154.175039] Supported: Yes, External
[ 154.175041]
[ 154.175044] Pid: 12110, comm: modprobe Tainted: G X 3.0.80-0.5-xen #1 Dell Inc. PowerEdge R515/03X0MN
[ 154.175050] RIP: e030:[] [] cleanup_module+0xb0/0x150 [drbd]
[ 154.175064] RSP: e02b:ffff88079e8efef8 EFLAGS: 00010203
[ 154.175066] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 154.175069] RDX: fffffffffffffff8 RSI: ffff88079e8eff0c RDI: ffffffffa04fe600
[ 154.175072] RBP: ffff88079e8eff0c R08: 0000000000000000 R09: 0000000800040008
[ 154.175075] R10: 0000000100030008 R11: 0000001800010006 R12: ffffffffa0508000
[ 154.175078] R13: 0000000000000000 R14: 0000000000623230 R15: 0000000000000000
[ 154.175084] FS: 00007f92fdf3a700(0000) GS:ffff8807c14e0000(0000) knlGS:0000000000000000
[ 154.175088] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 154.175090] CR2: 0000000000000000 CR3: 00000007a793c000 CR4: 0000000000000660
[ 154.175094] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 154.175097] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 154.175100] Process modprobe (pid: 12110, threadinfo ffff88079e8ee000, task ffff880792438580)
[ 154.175103] Stack:
[ 154.175105] 0000000000000000 ffffffffa04d8f05 0000000000000000 00000000fffffff4
[ 154.175110] 0000000000081dd8 ffffffffa0508085 ffffffffa04fe240 ffffffff8000403b
[ 154.175115] 0000000000000000 ffffffffa04fe240 0000000000081dd8 00007f92fdeb7000
[ 154.175121] Call Trace:
[ 154.175158] [] init_module+0x85/0x1000 [drbd]
[ 154.175177] [] do_one_initcall+0x3b/0x190
[ 154.175185] [] sys_init_module+0xcf/0x240
[ 154.175192] [] system_call_fastpath+0x16/0x1b
[ 154.175201] [<00007f92fda9635a>] 0x7f92fda96359
[ 154.175204] Code: 24 14 01 48 89 ee 48 c7 c7 00 e6 4f a0 e8 69 80 d3 df 48 85 c0 48 89 c3 75 b1 48 8b 05 ba 59 02 00 48 8d 50 f8 48 3d 20 e6 4f a0
[ 154.175228] 8b 4a 08 74 5b 48 8d 59 f8 eb 07 0f 1f 40 00 48 89 f3 48 8b
[ 154.175241] RIP [] cleanup_module+0xb0/0x150 [drbd]
[ 154.175253] RSP
[ 154.175255] CR2: 0000000000000000
[ 154.175258] —[ end trace ae9d139fe656969d ]—
[ 171.660668] IPMI System Interface driver.
[ 171.660720] ipmi_si: probing via SMBIOS
[ 171.660724] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 0
[ 171.660727] ipmi_si: Adding SMBIOS-specified kcs state machine
[ 171.660733] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca8, slave address 0x20, irq 0
[ 172.742032] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20)
[ 172.742111] ipmi_si ipmi_si.0: IPMI kcs interface initialized

Ich habe den Fehler dann direkt (19.06.2013) als Servicerequest bei Novell gemeldet, heute am 21.06.2013 wurde mir ein PTF bereit gestellt der das Problem behebt.
Zwischenzeitlich hatte ich ein Kerneldowngrade auf die Version 3.0.74-0.6.10.1 durchgeführt, damit meine Systeme wieder einwandfrei arbeiten.

Ursache des ganzen war folgendes:

It is because of a silent change in KABI for xen.
Which requires the drbd module to be re-compiled against the actual
kernel. Also we have found and fixed the NULL pointer dereference possibility
in drbd code.

Öffentlich soll der Fix im laufe der KW26 werden, sofern nichts größeres dazwischen kommt.

Update 25.06.2013:
Der Vorabfix wurde heute von SUSE zurück gezogen und ein komplettes Kernel Update angekündigt, da die KABI
Änderungen wohl umfangreicher ausfallen. Nach dem Update soll das alte drbd Kernel Modul wieder kompatibel sein.

Update 05.07.2013:
Ein neues Kernelupdate (SUSE-SU-2013:1151-1 / Version 3.0.80-0.7.1) wurde released, welches das Problem nun final löst.

Bei M-Net läuft bereits seit geraumer Zeit ein IPv6 Testbetrieb an
dem man freiwillig teilnehmen kann. Support gibt es dafür allerdings
bisher nicht. Hilfe findet man allerdings im Forum.

Ich selbst habe einen Linux Router mit SLES 11 SP1 an dem ein
Standard DSL Modem hängt. Die Einwahl erfolgt mittels pppd und
pppoe und wurde initial über yast konfiguriert. In dem Router
befinden sich mehrere Netzwerkschnittstellen (eth0 – eth5) wovon ich mittels
Bridge Konfiguration eth0 – eth4 zu einem Interface br0 zusammengefasst habe.
Das DSL Modem selbst hängt an eth5. Bei der Einwahl über ppp wird dsl0 erzeugt.

Für die Nutzung von IPv6 über den ppp0 Link sind einige Anpassungen
am System nötig.

• Loginname anpassen
• Installation von wide-dhcpv6 und radvd

Der erste Punkt ist sehr einfach umzusetzen, dazu wird
in der Datei /etc/sysconfig/network/provides/provider0
in der Zeile USERNAME der Teil nach dem ‘@’ Symbol mit
“v6.mnet-online.de” ersetzt und in der Datei /etc/ppp/peers/pppoe diese Zeileangehängt.

+ipv6 ipv6cp-use-ipaddr

Der zweite Teil ist auf SLES11 etwas problematischer gewesen,
da es kein wide-dhcpv6 Paket gab. Das Standard dhcpv6 Paket
funktioniert leider nicht, es ist zwar von der Konfiguration
her ähnlich hat aber nicht den Umfang den wide-dhcpv6 bereit
stellt.

Ich habe daher ein eigenes wide-dhcpv6 Paket erstellt, welche
nun zum Einsatz kommt. Das Paket befindet sich in server:network
Repository. Das Repository wie folgt hinzufügen:

zypper ar -f http://download.obs.j0ke.net/server:/network/SLE_11_SP1/ server:network

Die Pakete im Anschluss wie folgt installieren:

zypper in wide-dhcpv6 radvd

Sollte das Paket dhcpv6 bereits installiert sein, muss die Deinstallation dieses Pakets
bestätigt werden.

Nach der Installation werden für beide Dienste Konfigurationsdateien angelegt:

/etc/dhcp6c.conf

#
# See dhcp6c.conf(5) man page for details.
#

interface dsl0 {
        send ia-pd 0;
        send rapid-commit;
        script "/usr/bin/dhcp6c-state";
        request domain-name-servers;
};

id-assoc pd 0 {
        prefix-interface lo {
                sla-id 0;
                sla-len 8;
        };
        prefix-interface br0 {
                sla-id 1;
                sla-len 8;
        };
};

/etc/radvd.conf

interface br0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix ::/64 {
                AdvOnLink on;
                AdvAutonomous on;
        };
};

Zudem ein kleines Shellscript was vom dhcp6c ausgefürht wird:
/usr/bin/dhcp6c-state

#!/bin/bash
sleep 10
/etc/init.d/radvd restart 2>&1 >/dev/null

Auf meinem Router habe ich zur Überwachung der DSL Verbindung
ein weiteres Shellscript mitlaufen, welches prüft ob dsl0 aktiv
ist und andernfalls die DSL Verbindung herstellt. Zeitgleich
werden darin auch der dhcp6c gestartet und die Defaultroute
für IPv6 gesetzt.

/usr/local/bin/keepalive.ppp

#!/bin/sh
# restart the ppp connection whenever it goes down
export PATH=/bin:/usr/bin:/sbin:/usr/sbin
export LOG="logger -p daemon.notice -t `basename $0`[$$]"

$LOG "Monitoring PPP connection"
while [ 1 ]
do

        if `ifconfig | grep -q ^dsl0`
        then
                $LOG "PPP connection ok"
        else
                $LOG "Starting pppoed"
                # set dsl modem interface to up state
                ifconfig eth5 up
                # set dsl0 to off to be sure it's really off
                ifdown dsl0
                # start dsl0 connection
                ifup dsl0
                sleep 10
                # run dhcp6 client on dsl0 interface
                killall -9 dhcp6c 2>/dev/null
                dhcp6c -c /etc/dhcp6c.conf -p /var/run/dhcp6c.pid dsl0
                # set IPv6 default route to dsl0 interface
                ip -6 ro add default dev dsl0
        fi

        sleep 30
done

Das hier gezeigte Script wird beim Booten des Systems von einem init-Script
aufgerufen. Diese script so aus:

/etc/init.d/keepalive.init

#!/bin/sh
# keepalive.ppp wrapper startup script

### BEGIN INIT INFO
# Provides: keepalive.init
# Required-Start: $network $remote_fs sshd
# Required-Stop: $network $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start the keepalive.ppp script
### END INIT INFO
. /etc/rc.status
# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_failed        set local and overall rc status to failed
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status    

# First reset status of this service
rc_reset
case "$1" in
        start)
                if [ -z "`find /proc -lname "/usr/local/bin/keepalive.ppp" 2>/dev/null |awk -F/ '{print $3}'`" ]; then
                        echo "starting keepalive.ppp..."
                        /usr/local/bin/keepalive.ppp &
                else
                        echo "keepalive.ppp is already running"
                        rc_failed
                fi
                        rc_status -v
        ;;
        stop)
                echo "stopping keepalive.ppp"
                PID=`find /proc -lname "/usr/local/bin/keepalive.ppp" 2>/dev/null |awk -F/ '{print $3}'`
                if [ -n "$PID" ]; then
                        kill -9 $PID
                else
                        rc_failed
                fi
                rc_status -v
        ;;

        status)
                PID=`find /proc -lname "/usr/local/bin/keepalive.ppp" 2>/dev/null |awk -F/ '{print $3}'`
                if [ -n "$PID" ]; then
                        echo "keepalive.ppp status: "
                else
                        echo "keepalive.ppp status: "
                        rc_failed
                fi
                rc_status -v
        ;;

        *)
                echo "Usage: $0 < start | stop | status >"
        ;;
esac
rc_exit

Das init-Script kann mit folgendem Befehl für den Startvorgang dauerhaft aktiviert werden:

chkconfig keepalive.init on

Sobald die DSL Verbindunzg per ‘/etc/init.d/keepalive.init start’ gestartet wird sollten im Anschluss auf den lokalen Netzwerkschnittstellen lo0 (loopback) und br0 (interne LAN Bridge) IPv6 Adressen zu sehen sein. Bei M-Net beginnen diese mit “2001:a60:”. Damit der Linux Rechner IPv6 auch von und zum internen Netz weiter leitet muss IPv6 Forwarding aktiv sein.

Dazu wird “net.ipv6.conf.all.forwarding=1” in /etc/sysctl.conf eingetragen. Damit IPv6 forwarding sofort aktiv ist kann man es per Hand mit diesem Befehl aktivieren:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

Abschließend kann ich nur empfehlen, das jeder der IPv6 einrichtet sich mit einer entsprechenden Firewall ausrüstet,.da jeder PC im Netzwerk mittels einer automatisch zugewiesenen IPv6 Adresse von überall im Internet direkt erreichbar und somit auch direkt angreifbar ist.

Die letzten zwei abende habe ich damit verbracht einen merkwürdigen Fehler auf einem SLES11 System zu finden auf dem eine Asterisk Telefonanlage (1.6.2.x) mit chan_lcr läuft. Über eine HFC ISDN Karte und dazu gehörigem mISDN Treiber werden eingehende ISDN Anrufe auf SIP gebridged.
Seit dem neuesten Kernel Update kamen die Anrufe zwar noch durch, es läutet, man konnte abheben und die Verbindung war da, aber eine Sprachverbindung war nicht möglich (in beide Richtungen).
Nach langem Suchen inklusive Austausch von ISDN Kabel und HFC Karte blieb am Ende nur noch der Kernel übrig.

Im Changelog des Kernels bin ich über folgenden Eintrag gestolpert, der unter Umständen für dieses Verhalten verantwortlich ist.

* Mo Jan 17 2011 jeffm@suse.com
– patches.fixes/misdn-add-support-for-group-membership-check:
mISDN: Add support for group membership check (bnc#564423).

Dieser Eintrag brachte mich dann zu folgenden Commit

Mit diesem Patch wird ein neuer Modulparameter zu mISDN_core hinzugefügt welcher vermutlich in meiner Umgebung extra gesetzt werden muss:

parm:           gid:Unix group for accessing misdn socket (default 0) (uint)

Ich habe vorerst ein Kerneldowngrade durchgeführt, damit die Produktivität des Systems nicht weiter leidet, werde den Parameter aber noch ausprobieren.

Update: 27.03.2011

Ich hatte nun Gelegenheit den gid Parameter von mISDN_core zu testen. Mein lcr bzw. asterisk selbst läuft als Benutzer asterisk mit gid 330. Ich habe also gid=330 an modprobe mISDN_core als Parameter übergeben. Danach lcr und asterisk wieder gestartet. Alles funktioniert nun auch mit dem neuen Kernel wieder.

Seitdem wir bei InterNetX in den neueren Servermodellen in den Bereichen
wo bisher SAS6iR verbaut wurden nun auch die H200 Raidcontroller benutzen,
blieb immer wieder der Eindruck hängen das diese z.T. langsamer sind als ihre
Vorgänger. Eigentlich sollte es genau andersrum sein, denn der H200 ist
ein 6G und der SAS6iR nur ein 3G Controller.

Wie sich nun herausgestellt hat, wird beim H200 der Cache, der angeschlossenen
Festplatten deaktiviert. Dies war vor einigen Jahren auch schon beim SAS5i
Controller der Fall und konnte bis zum SAS6iR mittels dem Tool ‘lsiutil’
von Linux aus konfiguriert werden. Beim SAS6iR war der Cache allerdings
von Haus aus aktiviert, somit war dort keine Anpassung nötig.

Beim H200 funktioniert ‘lsiutil’ leider nicht mehr. Es gibt derzeit nur eine
mir bekannte Lösung die aus meiner Sicht noch etwas viel “Overhead” mit sich bringt.

Vorab wird geprüft, welchen Status der Cache hat, dazu schaut man in der Ausgabe
von ‘dmesg’ oder in /var/log/boot.log und sucht dort am besten nach “Write cache”

Finden sollte man mindestens einen Eintrag der wie folgt aussieht (Cache ist aus):

sd 0:1:0:0: [sda] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA

Sollte der Eintrag in etwa so aussehen, dist der Cache bereits an:

sd 0:1:0:0: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA

Um den Cache zu aktivieren benötigen wir OMSA (Open Manage Server Administrator) von DELL.
Dieser kann entweder direkt auf dem Server installiert werden oder mittels einer Live CD gebootet werden.

Nach der Installation auf dem Server sollte dieser Entweder neu gestartet werden
oder man muß die nötigen Dienste per Hand starten:

# modprobe ipmi_devintf
# modprobe ipmi_si
# /etc/init.d/dataeng start
# /etc/init.d/dsm_om_shrsvc start
# /etc/init.d/dsm_om_connsvc start

Der Cache kann dann entweder über das OMSA Webinterface https://<server-ip>:1311/ oder
per Console aktiviert werden.

Um die IDs von Controller & virtueller Disk zu bekommen nutzt man die folgenden Kommandos:

# omreport storage controller

Controller  PERC H200 Adapter (Slot 1)

Controllers
ID                                            : 0
Status                                        : Ok
Name                                          : PERC H200 Adapter
Slot ID                                       : PCI Slot 1
State                                         : Ready
Firmware Version                              : 07.01.33.00
Minimum Required Firmware Version             : Not Applicable
Driver Version                                : 04.100.01.03
Minimum Required Driver Version               : Not Applicable
Storport Driver Version                       : Not Applicable
Minimum Required Storport Driver Version      : Not Applicable
Number of Connectors                          : 2
Rebuild Rate                                  : 50%
BGI Rate                                      : 50%
Check Consistency Rate                        : 50%
Reconstruct Rate                              : Not Applicable
Alarm State                                   : Not Applicable
Cluster Mode                                  : Not Applicable
SCSI Initiator ID                             : Not Applicable
Cache Memory Size                             : Not Applicable
Patrol Read Mode                              : Not Applicable
Patrol Read State                             : Not Applicable
Patrol Read Rate                              : Not Applicable
Patrol Read Iterations                        : Not Applicable
Abort Check Consistency on Error              : Not Applicable
Allow Revertible Hot Spare and Replace Member : Not Applicable
Load Balance                                  : Not Applicable
Auto Replace Member on Predictive Failure     : Not Applicable
Redundant Path view                           : Not Applicable
CacheCade Capable                             : Not Applicable
Persistent Hot Spare                          : Not Applicable
Encryption Capable                            : Not Applicable
Encryption Key Present                        : Not Applicable
Encryption Mode                               : Not Applicable
Spin Down Unconfigured Drives                 : Not Applicable
Spin Down Hot Spares                          : Not Applicable

# omreport storage vdisk

List of Virtual Disks in the System

Controller PERC H200 Adapter (Slot 1)
ID                  : 0
Status              : Ok
Name                : Virtual Disk 0
State               : Ready
Encrypted           : Not Applicable
Layout              : RAID-1
Size                : 232.25 GB (249376538624 bytes)
Device Name         : /dev/sda
Bus Protocol        : SATA
Media               : HDD
Read Policy         : Not Applicable
Write Policy        : Not Applicable
Cache Policy        : Not Applicable
Stripe Element Size : 64 KB
Disk Cache Policy   : Disabled

Der Cache kann nun mit folgendem Befehl aktiviert werden.

# omconfig storage vdisk action=changepolicy controller=0 vdisk=0 diskcachepolicy=enabled

Nach nochmaligem Ausführen von ‘omreport storage vdisk’ wird der Wert ‘Disk Cache Policy’
auf ‘Enabled’ stehen. Der Cache ist sofort aktiv, es wird kein Neustart benötigt.

Es gibt noch eine weiteres Tool was direkt von LSI stammt, was aber keine Funktion
zum Einschalten des Caches hat (sas2ircu).

Diese Woche habe ich mir endlich mein neues Notebook gegönnt. Bisher hatte
ich ein HP nx8220 15″ Notebook was innerhalb von 4 Jahren drei mal
den gleichen Defekt hatte (Mainboard Fehler, kein Power-On oder kein WLAN).
Zum Glück konnten zwei dieser Defekte innerhalb der Garantiezeit repariert werden.
Leider häuften sich die Berichte zu diesem Modell im Netz, die genau
mein Fehlerbild wieder spiegelten. Das ganze ist nun zum Glück Geschichte
und ist natürlich in die Auswahl für das neue Notebook mit eingeflossen.

– kein HP mehr (auch beruflich habe ich hier sehr schlechte Erfahrungen mache müssen)
– unbedingt mit Garantieverlängerung kaufen

Weitere Kriterien für das neue Notebook waren:

– standard Tastaturlayout
– mattes Display
– SSD Festplatte
– niedriges Gewicht
– lange Akkulaufzeit
– möglichst viele integrierte Netzschnittstellen (LAN,WLAN,Bluetooth,UMTS)
– hohe Auflösung im Verhältnis zur Bild diagonale

Daraus habe ich mich für das Lenovo Thinkpad X201 Bundle NUSREGE entschieden,
bei dem zum eigentlichen Notebook auch eine Dockingstation mit integriertem
DVD Brenner mitgeliefert wird.
Die technischen Details des Notebooks im Überblick:

– Intel Core i5-520M(2,4GHz)
– 4GB RAM
– 128GB SSD SAMSUNG
– 12,1″ Display 1280×800 LCI
– Intel HD Graphics
– Intel 802.11agn Wireless
– WWAN
– Bluetooth
– Modem
– 1Gb Ethernet
– Ultranav
– Secure Chip
– Fingerprint Reader
– Camera
– 9c Li-Ion
– Windows 7 Pro64

Da ich nun kein wirklicher Freund von Windows bin war der erste Schritt
nach dem auspacken, ein Backup der bestehenden Daten in ein Image (falls
man es später irgendwann doch mal brauchen sollte). Ok, es war
nicht ganz der erste Schritt, ich habe mir erst mal die mitgelieferte
Lenovo Managementsoftware angesehen. Diese erlaubt es sehr komfortabel
alle Treiber und Firmwareupdates für das Gerät auf einen Schlag herunterzuladen
und zu installieren. Daher habe ich erst alle verfügbaren Updates inkl.
BIOS Update eingespielt. Im Anschluss wurde das Backup mittels CloneZilla
erstellt und auf meinem lokalen NAS gespeichert.

Als neues Betriebssystem hatte ich mir SuSE Linux Enterprise Desktop 11 SP1
ausgesucht. Bei der Basishardware hatte ich keine Bedenken was die Treiberunterstützung
angeht. Lediglich UMTS & Fingerprint stellten sich nach der Installation
als etwas problematisch heraus.

Die Installation habe ich mittels eines vorbereiteten Autoyast Profils
durchgeführt, welches ich zuvor schon für andere Desktopinstallationen
vorbereitet hatte.
Die Installation lief reibungslos durch, allerdings startete der X Server
nach der Installation nicht. Den gleichen Fehler hatte ich bereits
bei einer früheren Installation festgestellt und damit konnte dieser
schnell behoben werden. Die Fehlermeldung dazu war:

kdm[5974]: X server “-br” cannot be executed

Diese Meldung deutet auf eine unvollständiges Kommando hin, was aus
nicht definierten Variablen hervorgeht.
Die Lösung dazu ist sehr einfach, in der Datei /usr/share/kde4/config/kdm/config/kdmrc
die während der Installation angelegt wird sind die meisten Parameter
auskommentiert. Die beiden wichtigsten muss man einfach nur ein kommentieren:

ServerArgsLocal=-nolisten tcp
ServerCmd=/usr/bin/X

Danach kann der X Server mittels ‘/etc/init.d/xdm start’ normal
gestartet werden.

Eine weitere kleine Hürde war die Soundausgabe. In Skype wurde
bei den Audiogeräten nur “Pulseaudio” zur Auswahl angeboten, damit
war es mir nicht möglich ein eingeschlossenes USB Headset direkt
auszuwählen. Unter KDE4 kann dies über Phonon in den KDE Systemeinstellungen -> Multimedia
normaler Weise direkt fest konfiguriert werden, allerdings hatte
das erstens keine Auswirkung auf Skype und zweites gab es den
Nebeneffekt das z.B. Flashvideos in Firefox manchmal ohne Ton
abgespielt wurden. Die Lösung dafür ist auch relativ einfach.
Man öffnet eine root Konsole und deinstalliert pulseaudio.

zypper remove pulseaudio

Zypper bittet dafür um Bestätigung und listet eine Reihe von
weiteren pulseaudio Unterpaketen auf, die ebenfalls deinstalliert werden.

Nach einem Neustart/Neulogin können in Skype die gewohnten
Audiogeräte ausgewählt werden.
Um Phonon noch um das xine Audiobackend zu erweitern und
auch andere Multimedia Applikationen zur Verfügung zu haben
(z.B. Mplayer & VLC) habe ich einige Packman Pakete für SuSE Linux Enterprise 11 SP1
in meine Buildservice rekompiliert. Das daraus erstellte Repository
habe ich einfach in Yast eingetragen und die nötigen Pakete
phonon-backend-xine, vlc und MPlayer installiert. Fragen
nach einem Anbieterwechsel habe ich natürlich bestätigt.

Eine etwas größere Herausforderung war der Fingerprint Leser.
Hierzu gibt es im Netz zum Glück schon eingie Berichte, Patches
und diverse Software die eine Nutzung ermöglichen. Allerdings
waren diese zum Release von SLES/SLED11 noch nicht verfügbar bzw.
im aktuellen Entwicklungsstadium. In openSUSE 11.3 sollten
alle relevanten Pakete von Haus aus enthalten sein und
somit dürfte die Hardware dort von Haus aus funktionieren.

Ich habe mich also daran gemacht die nötigen Pakete auf SLES/SLED11
zurück zu portieren. Dazu habe ich ebenfalls ein Repository in
meinem Buildservice angelegt.
Dort sind neben einer neueren libusb auch eine aktuelle libfprint
enthalten und das Paket pam_fprint. Nach der Installation dieser Pakete
habe ich nur noch die Datei /etc/pam.d/common-auth um die Zeile
für pam_fprint erweitert.

auth required pam_env.so
auth sufficient pam_fprint.so
auth required pam_unix2.so

Mittels pam_fprint_enroll kann man den eigenen Fingerprint einlesen.
Dies muß als Benutzer root durchgeführt werden, da das Tool schreibende
Rechte auf den Fingerprint Leser benötigt. Die eingescannten
Fingerprints können einfach auf einen beliebigen Nutzeraccount
übertragen werden. Dazu muß der Ordner .fprint im Homeverzeichnis
des Benutzers root in das gewünschte Homeverzeichnis umkopiert werden
(Rechte auf den neuen Benutzer anpassen nicht vergessen).

Bei grafischen Logins (KDM, Screensaver) wird eine Meldung angezeigt
die um Scan des Fingers bittet und bestätigt werden muß. Sobald
der Scan erwartet wird, leuchtet am Fingerprint Sensor die grüne LED.

Bei Programmen die z.B. mittels KDESU gestartet werden (z.B. Yast)
kommt leider keine Meldung die zum Scan auffordert, allerdings
leuchtet auch hier die grüne LED des Sensors. Daher kann
man einfach “blind” scannen und dann startet das Programm.
Bei mehrfach fehlgeschlagenem Scan erscheint die übliche Passwortabfrage.

Die wohl größte Tüftelei war das UMTS Modem in Gang zu bekommen.
Auch hierzu gibt es diverse Erfahrungsberichte und Anleitungen im Netz
die mir sehr geholfen haben. Das verbaute UMTS Modem ist von Qualcomm Inc., die Ausgabe von ‘lsusb’

Bus 002 Device 010: ID 05c6:9204 Qualcomm, Inc.

Wichtig ist hier die ID des Gerätes, diese wird sich später leicht
ändern sobald Treiber und Firmware geladen sind.
Leider liegen bei SLES/SLED11 weder der passende Treiber noch Firmware
Dateien bei. Allerdings gibt es für den Kernel passende Patches
und einen extra Firmwareloader mit denen die Nutzung möglich wird.
Die Patches für den Kernel habe ich auf das Originalkernelmodul
angewendet und in einem Kernelmodulpaket bereitgestellt.

Neben dem Kernelmodul ist im gleichen Repository
auch die Firmware inkl. Loader hinterlegt. Der Loader läd
mittels udev Regel beim booten die Firmwares sobald der angepasste
Treiber “qcserial” geladen wird. Sobald dieser aktiv ist erscheint
in ‘dmesg’ folgende Ausgabe:

qcserial 2-1.4:1.2: Qualcomm USB modem converter detected
usb 2-1.4: Qualcomm USB modem converter now attached to ttyUSB0

Zudem ändert sich die Geräte ID in der Ausgabe von ‘lsusb’

Bus 002 Device 010: ID 05c6:9205 Qualcomm, Inc.

Hier ist zu sehen das sich die letzte Stelle der ID von 4 auf 5 geändert
hat. Das deutet darauf hin das die Firmware ordnungsgemäß
geladen wurde. Bisher konnte ich allerdings noch keinen Einwahltest
durchführen, da mir aktuell noch eine SIM fehlt.

Als letztes habe ich noch einige Optimierungen/Anpassungen für die SSD vorgenommen. Dazu gehören neben tmpfs Einträgen in der Datei /etc/fstab auch die Anpassung des Standard Schedulers für die Festplattennutzung.

tmpfs                   /tmp            tmpfs           size=25%,noexec,nosuid  0       0
/tmp                    /var/tmp        auto            rw,bind,noexec,nosuid   0       0

Die Anpassung des Schedulers findet in /boot/grub/menu.lst statt, dabei werden die Parameter des Kernels um folgenden ergänzt.

elevator=noop

Zur Laufzeit kann diese Änderung mit folgendem Befehl durchgeführt werden.

echo noop >  /sys/block/sda/queue/scheduler

Andernfalls tut es auch ein reboot des Systems.

Soweit läuft das neue Notebook nun absolut einwandfrei, auch
das an- und abdocken funktioniert prima. An der Dockingstation habe
ich zusätzlich einen 24″ Samsung LCD Monitor angeschlossen
der beim Andocken automatisch erkannt wird und konfiguriert werden
kann. Auch die integrierte LAN Schnittstelle und USB Ports
werden automatisch benutzt.

Gestern habe ich von Novell einen aktualisierten Kernel bekommen in dem der CIFS Bug
behoben ist. Der Kernel hat, zumindesst vorübergehend (bis zum finalen release),
die Version 2.6.32.13-0.5.1.1726.0.PTF-default.

Im changelog findet sich folgender Eintrag:

– patches.fixes/cifs-fix-vfs-busy-inode-errors: Revert the commit that fixes
page refcount leak which is not required but causes hangs (bnc#627518).

Der neue Kernel ist noch nicht öffentlich verfügbar, die Änderung wird
aber aller vorrausicht nacht so in den Hauptkernel und somit das nächste
Update einfließen.

Update (13.09.2010 21:13):

Das offizielle Update des Kernels wurde heute frei geben, neben diversen Sicherheitsfixes wurden auch einige Bugs beseitigt.

Details dazu gibt es hier

Bei einem Kernelupdate eines SLES 10 SP3 Gastsystems auf einem SLES 11 SP1 XEN Host
kam es bei mir, während der letzten Kernelupdates in den DomUs vor,
das ich erst von PV auf HVM und nun wieder auf PV wechseln mußte
damit die virtuellen Maschinen wieder booten konnten.

Das erste Update war von 2.6.16.60-0.62.1 auf 2.6.16.60-0.66.1
und dann kam das heutige auf die Version 2.6.16.60-0.67.1

Nach dem einspielen des letzten Updates kamen meine DomUs nicht mehr hoch.
Ein ‘xm list’ zeigte einen normalen status. Ein Versuch die Console der VM
zu öffnen mittels ‘xm console <domain>’ wurde mit folgendem Fehler abgebrochen:

xenconsole: Could not read tty from store: No such file or directory

Ein neustart des xend und auch ein reboot des gesamten Hostsystems hat
nicht geholfen, da mein erster Verdacht in Richtung xenconsoled ging hatte
ich dies zuerst versucht. Leider bis hierher vergebens.

Dann erinnerte ich mich das ich beim Kernelupdate davor auf HVM wechseln
mußte damit meine DomUs wieder hoch kamen. Also war der nächste Schritt
diese Umstellung rückgängig zu machen.
Das ganze klappte auf Anhieb und alle VMs laufen nun wieder paravirtualisiert.

Anfang dieser Woche ist mir nach der Neuinstallation einer Workstation bzw. beim updaten vorhandener Systeme ein Kernel BUG im CIFS Treiber untergekommen.

Bei gemounteten Freigaben unseres Samba Servers kommt es beim Lesen oder Schreiben (Verzeichnislisting funktionert – “ls -al”) auf die Freigabe zu einem Lockup, welcher sich im Systemlog wie folgt darstellt.

Aug 10 12:26:03 linux-l4nm kernel: [  213.425273] BUG: Bad page state in process cp  pfn:694cc
Aug 10 12:26:03 linux-l4nm kernel: [  213.425276] page:ffffea0001708ca0 flags:0020000000000010 count:0 mapcount:0 mapping:ffff880069c62ea8 index:e
Aug 10 12:26:03 linux-l4nm kernel: [  213.425279] Pid: 3289, comm: cp Tainted: G    B   W  X 2.6.32.13-0.5-default #1
Aug 10 12:26:03 linux-l4nm kernel: [  213.425281] Call Trace:
Aug 10 12:26:03 linux-l4nm kernel: [  213.425286]  [<ffffffff810061dc>] dump_trace+0x6c/0x2d0
Aug 10 12:26:03 linux-l4nm kernel: [  213.425291]  [<ffffffff81394848>] dump_stack+0x69/0x71
Aug 10 12:26:03 linux-l4nm kernel: [  213.425296]  [<ffffffff810b9343>] bad_page+0xe3/0x170
Aug 10 12:26:03 linux-l4nm kernel: [  213.425300]  [<ffffffff810bc729>] __pagevec_free+0x39/0x50
Aug 10 12:26:04 linux-l4nm kernel: [  213.425305]  [<ffffffff810bf65a>] release_pages+0x1fa/0x250
Aug 10 12:26:04 linux-l4nm kernel: [  213.425311]  [<ffffffff810bf890>] ____pagevec_lru_add+0x1e0/0x200
Aug 10 12:26:04 linux-l4nm kernel: [  213.425320]  [<ffffffffa04c06fc>] cifs_readpages+0x3dc/0x4d0 [cifs]
Aug 10 12:26:04 linux-l4nm kernel: [  213.425335]  [<ffffffff810be83a>] __do_page_cache_readahead+0x14a/0x220
Aug 10 12:26:04 linux-l4nm kernel: [  213.425340]  [<ffffffff810be92c>] ra_submit+0x1c/0x30
Aug 10 12:26:04 linux-l4nm kernel: [  213.425345]  [<ffffffff810b5a5e>] do_generic_file_read+0x33e/0x460
Aug 10 12:26:04 linux-l4nm kernel: [  213.425350]  [<ffffffff810b6296>] generic_file_aio_read+0xd6/0x1f0
Aug 10 12:26:04 linux-l4nm kernel: [  213.425355]  [<ffffffff810fc7e3>] do_sync_read+0xe3/0x130
Aug 10 12:26:04 linux-l4nm kernel: [  213.425360]  [<ffffffff810fcf87>] vfs_read+0xc7/0x130
Aug 10 12:26:04 linux-l4nm kernel: [  213.425365]  [<ffffffff810fd0f3>] sys_read+0x53/0xa0
Aug 10 12:26:04 linux-l4nm kernel: [  213.425370]  [<ffffffff81002f7b>] system_call_fastpath+0x16/0x1b
Aug 10 12:26:04 linux-l4nm kernel: [  213.425376]  [<00007f05e409df30>] 0x7f05e409df30

Ich habe dazu bei Novell einen Service Request geöffnet welcher, derzeit vom Engineering bearbeitet wird und vorraussichtlich mit einem neuen Kernelupdate gefixt wird.

Gestern hat Novell das Service Pack 1 für SUSE Linux Enterprise 11 offiziell zugänglich gemacht. Sowohl neue ISO Images als auch die nötigen Updatepakete werden verteilt.

Die neue Version bringt neben XEN 4.0 nun auch KVM mit und läuft mit einem aktualisierten Kernel 2.6.32.

Die wichtigsten Links im Netz:
Novell Announcement
How to update