Elitebook 8530p, Gentoo, Funtoo - Teil 2
Es hat mir einfach keine Ruhe gelassen ;-) Wie kürzlich berichtet, hat Gentoo Linux ja soweit funktioniert mit dem HP Elitebook 8530p. Nur leider war mit der ATI Radeon HD 3650 (R635) kein Blumentopf zu gewinnen. Nun gut, also nochmal ran an die Büchse...
Zunächst war klar, die Komponenten da drin sind ziemlich neu für Linux-Verhältnisse. Es musste also das Neueste vom Neuen an Software und Treiber her. Also hab ich nicht Gentoo sondern Funtoo installiert ;-) Funtoo stammt von Daniel Robbins und das war der Gentoo-Gründer. Die Unterschiede zwischen Funtoo und Gentoo sind nicht so riesig. Zum einen wird dort der Portage-Tree in einem Git-Repository verwaltet. Das merkt man hauptsächlich bei einem emerge aber auch nur optisch soz. Der zweite große Unterschied ist, das die Pakete aus dem unstable Zweig kommen - also genau das was wir hier brauchen ;-) Die Unterschiede bei der Installation findet ihr im o.g. Link zu Funtoo.
Im Bios sollte man zunächst die Option System Configuration -> Device Configuration -> FAN Always on while on AC Power ausschalten. Gebootet habe ich zunächst wieder mit Sabayon-Linux 4.1. Im Prinzip tut es aber jede Distribution die einen neueren Kernel hat z.B. auch die auf Gentoo basierende System Rescue CD. Sabayon habe ich mit den Parametern acpi=off gestartet (siehe auch hier). Ohne den, hängt sich die Installation relativ schnell weg. ACPI auszuschalten, ist i.d.R. keine so gute Idee, zumal man dann auch nur einen Prozessor hat, aber für die Grundinstallation tut's das. Wenn gebootet, geht man wie im Funtoo/Gentoo-Handbuch beschrieben vor, bis man zu der Stelle kommt, wo man den Kernel kompiliert. Da wir ja im unstable-Zweig sind, erhalten wir automatisch die neuesten gentoo-sources und das ist gerade jetzt aktuell der Kernel 2.6.29. Und nur zur Beruhigung: Damit läuft auch ACPI wunderbar ;-) Die .config für den Kernel habe ich nicht selbst erstellt, sondern habe mir vertrauensvoll die Konfiguration (in diesem Fall für x86_64 bzw. amd64 / [Update 20100419: Die Kernel-Sourcen befinden sich inzwischen hier im GIT] [Update 20120209: Die Quellen haben sich wieder geändern: Man findet sie jetzt u.a. hier .]gezogen, die Sabayon mit ihrem Kernel 2.6.27 verwendet. Die kopiert man nach /usr/src/linux/.config und erzeugt sich dann mit genkernel --menuconfig --oldconfig all einen Kernel. Es wird vorher noch das Kernelmenü aufgerufen, wo man noch eigene Einstellungen vornehmen kann, aber ich würde da erst später rumspielen. Die Sabayon-Jünger machen da einen guten Job. Die /boot/grub/grub.conf sieht dann bei mir so aus:
default 0
timeout 30
title Gentoo 2.6.29
root (hd0,0)
kernel /boot/kernel-genkernel-x86_64-2.6.29-gentoo root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda2 udev vga=791
initrd /boot/initramfs-genkernel-x86_64-2.6.29-gentoo
real_root müsst ihr natürlich anpassen, wenn / bei euch wo anderes liegt. Wenn man dann die restliche Installationsprozedur abgeschlossen hat, kann man booten. Aktuell erscheint dann nicht zweimal der beliebte Tux sondern zwei tasmanische Teufel ;-)
Soweit so gut. Bevor man sich nun die radeonhd-Treiber für die ATI 3650 (R635) installiert, muss man noch die /etc/make.conf anpassen. Die sieht bei mir so aus:
ACCEPT_KEYWORDS="~amd64"
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -O2 -msse4.1 -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j3"
GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ "
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="acl cups gdbm gpm libg++ nptl nptlonly unicode aac apache2 acpi alsa arts bash-completion bluetooth bmp bzip2 cdparanoia clamav curl cairocdr crypt dbus dv dvb dvd dvdr dvdread eds encode esd ethereal exif expat evo faad fam firefox ffmpeg flac gcj gd glitz gnutls gif gnome gpm gstreamer gtk hal ieee1394 imagemagick jpeg kde kerberos lirc lm_sensors mad mikmod matroska mbox mp3 mjpeg mono mpeg multilib nas ncurses ogg opengl oss pdf png posix postgres python qt3 qt3support quicktime readline ruby samba sasl scanner sdl spell sse2 ssl streamzap svg tcpd theora tidy tiff tiff truetype usb v4l vcd vorbis wifi win32codecs wmf wxwindows xine xinerama unicode X xml xmms xvid xv zlib"
# KDE
LINGUAS="en de"
# X11
VIDEO_CARDS="radeon radeonhd"
INPUT_DEVICES="keyboard mouse evdev synaptics"
Wichtig ist, das man radeon UND radeonhd bei den VIDEO_CARDS angibt! Die CFlags bekommt man ja üblicherweise hier. Dann installiert man sich den radeonhd-Treiber. Aktuell ist das x11-drivers/xf86-video-radeonhd-1.2.4. Das installiert dann einen ganzen Rattenschwanz an Paketen hinterher u.a. natürlich den xorg-server. Wenn das passiert ist, kann man sich mal eine xorg.conf erstellen mit xorgcfg z.B. Für den Laptop hier sieht die xorg.conf bei mir so aus:
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
EndSection
Section "Files"
ModulePath "/usr/lib64/xorg/modules"
FontPath "/usr/share/fonts/misc/"
FontPath "/usr/share/fonts/TTF/"
FontPath "/usr/share/fonts/OTF"
FontPath "/usr/share/fonts/Type1/"
FontPath "/usr/share/fonts/100dpi/"
FontPath "/usr/share/fonts/75dpi/"
EndSection
Section "Module"
Load "freetype"
Load "glx"
Load "record"
Load "xtrap"
Load "extmod"
Load "dri"
Load "dbe"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "NoAccel" # [<bool>]
#Option "AccelMethod" # [<str>]
#Option "offscreensize" # [<str>]
#Option "SWcursor" # [<bool>]
#Option "ignoreconnector" # [<str>]
#Option "forcereduced" # [<bool>]
#Option "forcedpi" # <i>
#Option "useconfiguredmonitor" # [<bool>]
#Option "HPD" # <str>
#Option "NoRandr" # [<bool>]
#Option "RROutputOrder" # [<str>]
#Option "DRI" # [<bool>]
#Option "TVMode" # [<str>]
#Option "ScaleType" # [<str>]
#Option "UseAtomBIOS" # [<bool>]
#Option "AtomBIOS" # [<str>]
#Option "UnverifiedFeatures" # [<bool>]
#Option "Audio" # [<bool>]
#Option "HDMI" # [<str>]
#Option "COHERENT" # [<str>]
Identifier "Card0"
Driver "radeonhd"
Option "AccelMethod" "exa"
Option "DRI" "On"
VendorName "ATI Technologies Inc"
BoardName "Mobility Radeon HD 3650"
BusID "PCI:1:0:0"
EndSection
Section "Extensions"
Option "Composite" "On"
EndSection
Section "ServerFlags"
Option "AIGLX" "On"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
Für den ersten Test sollte man aber erstmal folgende Optionen weglassen (dazu gleich mehr):
Option "AccelMethod" "exa"
Option "DRI" "On"
Section "Extensions"
Option "Composite" "On"
EndSection
Section "ServerFlags"
Option "AIGLX" "On"
EndSection
Dann kann man mal xterm starten und es sollten dann hoffentlich drei Shell-Fenster erscheinen mit dem unendlich geilen twm-Windowmanager ;-) Wenn das tut, dann kann man z.B. KDE 4.2 installieren mit emerge -av kde-meta. Man wird aber aktuell feststellen, das beim Fenster verschieben z.B. nicht gerade der Punk abgeht. Wer's schneller haben möchte - und da kann man dann wirklich nicht meckern - der installiert sich den neuesten Treiber selbst. Das geht wunderbar und ist hier beschrieben. Damit hat man dann einen flotten Bildschirmaufbau. Leider lassen sich damit die KDE Desktop Effekte noch nicht nutzen. Man wird in /var/log/Xorg.0.log eine Fehlermeldung wie diese hier sehen:
(EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: cannot open shared object file: No such file or directory)
(EE) AIGLX: reverting to software rendering
D.h. es ist zwar alles soweit vorbereitet im Treiber, aber der 3D-Support fehlt noch. Aber wenn die Treiber-Götter uns gnädig sind und diese Meldung hier stimmt, dann bestehen gute Aussichten, das wir mit dieser Grafikkarte doch noch in den Genuss der KDE Desktop Effekte ohne diese besch... ATI-Closed Source Treiber kommen, die mit jedem Kernelupdate sowieso wieder nicht mehr funktionieren und mit Kernel >= 2.6.28 überhaupt nicht laufen, den ich aber wiederum brauche, damit dieser Laptop hier überhaupt vernünftig tut! Ahhhhhh! ;-) Vorallem ist mir der komplette Laptop mit Kernel 2.6.28 abgesemmelt, wenn ich das erstemal mich mit einem WLAN verbunden habe. Beim zweiten Start ging's dann. Aber mit Kernel 2.6.29 läuft jetzt absolut top.
Damit läuft eigentlich fast alles unter Linux mit dem Laptop. Ausprobiert habe ich allerdings noch nicht Bluetooth, den TPM-Chip und den Fingerabdruckleser. Definitiv nicht funktioniert das integrierte UMTS-Modem. Da gibt's zwar irgendwie eine Möglichkeit (s.u.), aber ganz wahnsinnig bin ich noch nicht, das ich mir dieses Prozedere antun muss. Ich habe stattdessen jetzt eine Karte Option 0301 von Vodafone. Läuft wunderbar mit umtsmon. Ach ja: Für WLAN kann ich nur wicd wärmstens empfehlen. Damit kann man sehr schon seine WLAN's oder auch Ethernet verwalten. Langsam wird's richtig komfortabel ;-)
Links:
Open-Source R600 OpenGL Support May Come Soon
How to setup Bluetooth
Nokia Handy als UMTS-Modem unter Linux (unter Gentoo als Alternative zu einer UMTS-Karte)
UMTS-Anbindung für Netbooks
UMTSmon SUPPORTED HARDWARE
HP un2400 Mobile Broadband Module (das ist besagtes, integriertes UMTS-Modem)
Kernelpatch für un2400 UMTS-Modem (für die Wahnsinnigen unter uns ;-) )
Problem with WWAN module un2400
HP EliteBook 8530p Notebook PC - Overview - Die offizielle Seite zum Notebook von HP
SystemRescueCd
Safe Cflags/Intel
Kubuntu Linux auf dem Elitebook 8530p
HP Elitebook 8530w - Ganz wichtige Seite mit Infos!
RadeonHD xorg Treiber Wiki
radeonhd - The Driver for AMD GPG r5xx/r6xx/r7xx Chipsets
FFe: Xv and EXA not supported on R6xx/R7xx chipsets
radeonhd:r6xx_r7xx_branch
Posted at 11:00nachm. März 30, 2009 by cetixx in Computers | Kommentare [0]
KVM, Qemu: Welche I/O-Scheduler verwenden
Update 20110831: Weitere Informationen zu dem Thema gab es auf dem KVM Forum 2011 in dem PDF Optimizing Your KVM Instances von Mark Wagner. Auch hier zeigt sich, das der Deadline Scheduler aktuell der Optimalste für eine KVM ist.
Update 20100318: Mehr Tuning-Informationen für die KVM gibt es hier: http://www.linux-kvm.org/page/Tuning_KVM .
Update 20090403: Ich denke, das sich das unten stehende, so nicht halten läßt. Die Sache mit dem noop-Scheduler verhält sich teilweise sehr gut, teilweise aber auch ziemlich übel, in dem z.B. der pgflush-Daemon ziemlich viel Systemzeit beansprucht und der I/O-Durchsatz ziemlich in die Knie geht. Das ändert sich schlagartig, sobald man auf den Deadline-Scheduler umschaltet. Auf den getesteten Systemen scheint die Benutzung des Deadline-Schedulers in Host und Guest die beste Kombination zu sein. Man kann das ja selber mal ausprobieren, in dem man den I/O-Scheduler im laufenden Betrieb wechselt z.B.
echo "deadline" > /sys/block/vda/queue/scheduler
Man sollte dann aber schon eine Anwendung oder einen Test fahren, der gut was auf die Platte schreibt und das auch möglichst konstant macht. Oder besser: Man verwendet bonnie++ . Ein eher syntetischer Test für I/O-Durchsatz aber ein guter Ausgangspunkt.
Text vom 20090330: Diese gar nicht so uninteressante Frage kam jetzt schon des Öfteren auf der KVM Mailingliste hoch. Letztendlich ist man sich einig, das das Gastsystem mit elevator=noop gestartet werden sollte. Per Default setzen ja heute die meisten Distributionen den Completely Fair Scheduler-I/O (CFQ) ein. Für den Host selbst ist das vielleicht ok, wenn im Gast elevator=noop als Kernelparameter z.B. im Grub übergibt. Es macht auch nicht wirklich Sinn, wenn sich die I/O-Scheduler im Gast und im Host Gedanken machen müssen, wie denn die Daten am Besten auf die Platte kommen sollen. Wenn ich die Mails der KVM-Entwickler/-User aber richtig interpretiere, dann bevorzugen sie doch eher den deadline Scheduler für den Host. Mit dem habe ich auch sehr gute Erfahrungen gemacht im Serverbereich. Ich finde - aber das ist jetzt meine subjektive Meinung - das der CFQ sich besser für den Desktopbereich eignet als für Serveranwendungen.
Posted at 10:00nachm. März 30, 2009 by cetixx in Tipps | Kommentare [0]
Links 20090327 - ZFS Nexenta
Unbreakable upgrades, ZFS and apt-get - Nexenta OS
Posted at 11:00nachm. März 27, 2009 by cetixx in General | Kommentare [0]
AVM Fritz WLAN Repeater
Wer seine WLAN-Reichweite erweitern möchte, der braucht irgendeine Art Verstärker. Der AVM Fritz!WLAN Repeater ist so ein Teil.
Arbeitet mit dem Linksys WRT160N Router sehr gut zusammen. Zur Einrichtung des Repeaters braucht man nur einstecken, auf das Display drücken, in der Router-Weboberfläche das WPS-Icon anklicken und schon haben die beiden Geräte die Verbindungsdaten abgeglichen. Anschließend kann man den Repeater in eine Stromsteckdose seiner Wahl einstecken - am Besten auf der Hälfte der Strecke zwischen Router und Laptop (oder was auch immer). Feine Sache und funktioniert wirklich gut.
Posted at 11:45nachm. März 21, 2009 by cetixx in Computers | Kommentare [0]
Elitebook 8530p, Gentoo, Sabayon, Kubuntu
Vorne weg: Das HP Elitebook 8530p ist ein tolles 15" Notebook. Mit einer 1680x1050 Auflösung, guter Verarbeitung, gutes Display und für Notebookverhältnisse wirklich schneller Festplatte, macht das Teil schon Spaß - mal vom Lüfter abgesehen, der zwar leise, aber beständig vor sich hin säuselt und ganz gut warm rausbläst.
Tja, leider habe ich blöderweise das Modell mit ATI HD 3650 Grafikkarte bekommen. Konnte ich mir leider nicht aussuchen. Und eines weiß ich jetzt definitiv: Linux und ATI - never ever again. Das ist hochpeinlich, was AMD/ATI da abliefert an Treiber. Für mich war von vornherein klar, das ich die ATI- und nicht die Opensource-Treiber nutzen möchte einfach wegen der KDE Desktop Effekte. Die sind nicht nur schön, sondern auch produktiv. Gehört hatte ich ja schon davon, das ATI und Linux nicht so das Wahre ist. Aber ich dachte (oder hoffte viel mehr), das die Zeiten jetzt auch vorbei sind.
Kubuntu 9.04 läuft mit dem Notebook ganz gut mit den Opensource-Treibern radeonhd, aber die proprietären Treiber liefen nur bei Sabayon, da sie da schon dabei sind. Unter Gentoo und Kubuntu 9.04 lief die Sache mit den proprietären Treibern i.d.R. auf einen schwarzen Bildschirm raus. Bei Gentoo hatte ich das mit Kernel 2.6.27 und 2.6.28 probiert. Zum Schluss gab es auch nur noch Fehler beim Kompilieren/Installieren. Wenn man so im Internet rumliest, dann schreiben viele, das sie wieder auf die Opensource-Treiber gewechselt sind, da mit jedem kleinen Kernel-Update die proprietären Treiber nicht mehr funktionieren.
Wenn ich mir da die Treiber von Intel in meinem Dell 630 oder die Nvidia-Treiber für meine 8600 GTS anschaue, wie gut die funktionieren, dann fällt mir zu den ATI-Treibern nix mehr ein. Die ATI-Treiber waren zu mach64-Zeiten schon unter aller Kanone und sie sind immer noch so schlecht. Und da liegen mehr als 15 Jahre dazwischen... Respekt.
Wer's dennoch versuchen möchte mit dem Notebook und Linux, der sollte unbedingt im Bios die Option System Configuration -> Device Configuration -> FAN Always on while on AC Power ausschalten. Wer Gentoo installiert, der sollte es sich etwas einfacher machen und die Sabayon 4.1 Live-DVD zum Booten nehmen. Diese Distribution (auf Gentoo basierend) ist auf dem neuesten Stand und so braucht man sich wenigstens damit nicht rumzuärgern. Ausserdem kann man auf der Sabayon-Seite sich die Kernel-Konfiguration (amd64 bzw. x86_64 in diesem Fall) downloaden und diese als Ausgangsbasis für den eigenen Gentoo-Kernel verwenden. Das steigert die Wahrscheinlichkeit gleich ein ganzes Stück, das der neue Kernel gleich sauber mit dem Notebook läuft. Und man könnte davon ausgehen, das X damit funktioniert. Hatte damit aber leider kein Glück. Ausserdem sollte man im Bios die Vanderpool Technologie (VT) aktivieren, damit man aus virtuellen Maschinen wie KVM oder VMWare mehr Geschwindigkeit rausholt bez. überhaupt erst nutzen kann (KVM).
Also ich habe das HP Notebook zurückgegeben und bleibe bei meinem Dell 630. Aber wer sich diese Grafikkarte unter Linux wirklich antun möchte, der findet hier vielleicht noch nützliche Infos:
Kubuntu Linux auf dem Elitebook 8530p
ATI Ubuntu Intrepid Installation Guide
Gentoo Linux Wiki - HP Elitebook 8530w
Gentoo Safe Cflags
Gentoo Linux Wiki - RadeonHD
Wenn's gar nicht weitergeht: forums.gentoo.org
Gentoo Linux ATI FAQ
Gentoo ATI Radeon FAQ
The Gentoo Linux alternative installation method HOWTO - Wer nicht die Gentoo Live oder Minimal CD verwenden möchte
chroot: cannot run command /bin/bash: Exec format error ;-)
Posted at 01:00vorm. März 20, 2009 by cetixx in Computers | Kommentare [0]
VLC: Segfault in libc
Wenn mal der VLC nicht mehr startet und in /var/log/messages eine Meldung wie diese zu finden ist
vlc[23006]: segfault at afe80fc4 ip b7d0b19c sp afe80fc8 error 6 in libc-2.8.so[b7c9f000+134000]
dann sollte man mal VLC wie folgt aufrufen von der Kommandozeile aus:
vlc --reset-config
Posted at 11:00nachm. März 19, 2009 by cetixx in Tipps | Kommentare [0]
Kabel BW und Linksys WRT160N Wireless Router
Der vom Kabel BW mitgelieferte WLAN-Router D-Link DI-524 ist ja jetzt nicht so unbedingt der Hit, wenn man eine 32 MBit-Leitung hat. Mehr wie 500-600 KB/sec. war da nicht zu holen, obwohl man nur 3 Meter vom Router und freier Sicht mit dem Laptop weg ist.
Musste was Schnelleres her. Der Linksys WRT160N arbeitet perfekt mit Kabel BW. Ich habe ihn unter Linux eingerichtet. Die Windows-Software habe ich gar nicht ausprobiert. Den Laptop erstmal per Ethernet mit dem Router verbunden. Die Adresse des Routers ist 192.168.1.1. DHCP ist aktiviert, so das man auch gleich eine IP vom Router bekommt. Den dann erstmal einrichten. Dann im ausgeschalteten Zustand an das schwarze Motorola Kabelmodem anstöpseln. Dazu verbindet man einfach per Ethernet-Kabel den Ausgang mit der Bezeichnung "Internet" vom Router mit dem Modem. Dann das Modem vom Stromnetz trennen, 5 Sek. warten, das Modem erstmal hochkommen lassen und dann den Router einschalten. Das ist nötig, da sonst das Modem sich weigert, mit dem Router zu sprechen, da sich die MAC-Adresse geändert hat. Das sollte dann schon gewesen sein.
Und jetzt sieht's mit der Speed schon besser aus. Gleiche Entfernung wie vorher und 2.0-2.4 MByte/sec. und ohne Draft-N (kann mein Laptop nicht :-( ). Das macht aber schon mehr Spaß ;-)
Posted at 01:27vorm. März 19, 2009 by cetixx in Tipps | Kommentare [0]
Linux - Dateien aufteilen mit split
Will man eine Datei in mehrere kleinere Teile aufteilen, um sie z.B. irgendwo hochladen zu können und dort nur Dateien z.B. mit max. 200MB errlaubt sind, dann kann man split verwenden:
split -a 3 -d -b 199M file_to_split.bin splitted.bin.
Wenn die Ausgangsdatei file_to_split.bin also z.B. 600 MByte groß war, dann erhält man jetzt folgende Dateien mit jeweils 199 MByte Größe:
splitted.bin.000
splitted.bin.001
splitted.bin.002
Die Option -a 3 gibt an, das man einen dreistelligen Suffix anhängen möchte. -d gibt an, das dieser Suffix nummerisch sein soll und -b 199M würde in diesem Beispiel die aufgeteilten Dateien max. 199 MByte gross werden lassen. Dann gibt man noch die Datei an die man aufteilen möchte und wie die aufgeteilten Dateien heissen sollen - also den Prefix soz.
Posted at 12:35nachm. März 17, 2009 by cetixx in Tipps | Kommentare [0]
Links 20090312 - Webgrind Relax and Recover
webgrind: Xdebug Profiling Web Frontend in PHP - Performance-Engpässe in PHP finden.
Relax and Recover - ReaR bietet die Möglichkeit, von einem Linux-System nach einem Plattenausfall ein komplettes System wieder herzustellen. Es ist nicht für tägliche Backups gedacht, sondern viel mehr für den Super-GAU: Platte tot. ReaR stellt hierfür dann div. Bootmedien zur Verfügung, mit dem man das System wieder herstellen kann.
Posted at 11:00nachm. März 12, 2009 by cetixx in Links | Kommentare [0]
xorg.conf - Umstieg von 1.3 auf 1.5
Ein Gentoo-Entwickler hat hier ein Python-Skript abgelegt, mit dem man seine xorg.conf in eine HAL FDI Policy Datei umwandeln kann. Probleme gibt es hierbei hauptsächlich bezügl. Tastatur und Maus. Nachdem der X-Server jetzt HAL/EVDEV verwendet, um Tastatur und Maus automatisch zu erkennen, hatte ich erstmal das Problem, das das Tastaturlayout gar nicht mehr stimmte. Auch mit dem KDE Keyboard Manager war da nix zu machen. Erst als ich eine Policy in /etc/hal/fdi/policy/10-x11-input.fdi angelegt hatte und in der /etc/X11/xorg.conf alle InputSection's die was mit Tastatur, Maus oder Touchpad zu tun hatten, entfernt habe, lief die Sache wieder rund. Die 10-x11-input.fdi für meinen Dell D630 Laptop sieht z.B. so aus:
<?xml version="1.0" encoding="utf-8"?>
<deviceinfo version="0.2">
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">xorg</merge>
<!-- Option "XkbModel" "pc105" -->
<merge key="input.xkb.model" type="string">evdev</merge>
<merge key="input.xkb.layout" type="string">de</merge>
<merge key="input.xkb.options" type="strlist">grp:alt_shift_toggle</merge>
<append key="input.xkb.options" type="strlist">grp_led:scroll</append>
<merge key="input.xkb.variant" type="string">,nodeadkeys,</merge>
</match>
</deviceinfo>
Posted at 11:00nachm. März 12, 2009 by cetixx in Tipps | Kommentare [0]
KVM/Qemu: Wie konvertiert man eine VMware VMDK Datei zu einem KVM Image
Die Lösung ist relativ einfach. Entweder verwendet man qemu-img oder kvm-img (je nachdem welches Tool der Distribution beiliegt):
qemu-img convert -f vmdk -O qcow2 vmware-image.vmdk kvm-image.qcow2
Update 20090511: Das funktioniert aber nur solange man nur ein vmdk-File hat. Wenn das VMWare-Image auf mehrere Dateien aufgesplittet ist wie s001.vmdk, s002.vmdk, usw., dann muss man anders vorgehen. Man konvertiert alle diese Dateien ins RAW-Format und kopiert diese dann zusammen in ein File:
for I in *[0-9].vmdk; do kvm-img convert -f vmdk "$I" -O raw "tempdir/$I"; done
cat *.vmdk >> final_image.raw
Das final_image.raw kann man dann mit der KVM starten.
Posted at 08:44vorm. März 11, 2009 by cetixx in Tipps | Kommentare [0]
24 SSD Platten als RAID machen Spaß - Samsung SSD Awesomeness
Posted at 12:15nachm. März 10, 2009 by cetixx in General | Kommentare [0]
PostgreSQL - Warm-Standby Datenbank Recovery
Nachdem ich ja kürzlich beschrieben habe, wie man eine Warm-Standby Datenbank mit PostgreSQL einrichtet, hier nun der Teil wie man die Standby Datenbank in Betrieb nimmt, wenn die primäre Datenbank ausgefallen ist.
Gehen wir mal davon aus, das der Rechner mit der primären Datenbank ausgefallen ist und die Standby Datenbank soll übernehmen. Die Slave-DB (Standby) hängt der Master-DB 60 Sek. hinterher. Es fallen also auf jeden Fall alle Transaktionen unterm Tisch, die in den letzten 60 Sek. gelaufen und nicht abgeschlossen wurden!
Die Slave-DB befindet sich ja im Dauerrecoverymodus und spielt laufend die Transaktionslogs ein, die von der Master-DB rübergeschoben werden. Um die DB aus dem Recoverymodus zu bringen, wurde in /data/pgsql/data/$DBNAME/recovery.conf ein Trigger festgelegt im recovery_command und der sieht so aus: -t /tmp/pgsql.fin.$DBNAME ($DBNAME wie immer im vorhergehenden Artikel schon beschrieben durch den Instanznamen ersetzen).
D.h. wenn wir jetzt als User postgres(!) per touch /tmp/pgsql.fin.$DBNAME diesen Trigger anlegen, beendet das pg_standby Programm den Recovery-Modus und fährt die DB hoch. Das kann eine Weile dauern, bis die Transaktionslogs nachgefahren wurden. Am Besten beobachtet man dabei das Postgres-Logfile. Die Ausgabe sieht dann in etwa so aus:
LOG: could not open file "pg_xlog/000000010000003F000000A3"
(log file 63, segment 163): No such file or directory
LOG: redo done at 3F/A2007F80
LOG: last completed transaction was at log time 2009-03-03 14:23:30.134095+01
LOG: restored log file "000000010000003F000000A2" from archive
LOG: selected new timeline ID: 2
LOG: archive recovery complete
LOG: checkpoint starting: shutdown immediate
LOG: checkpoint complete: wrote 10 buffers (0.0%); 0 transaction log
file(s) added, 0 removed, 0 recycled; write=0.015 s, sync=0.001s, total=0.092 s
DEBUG: transaction ID wrap limit is 2147484026, limited by database "template1"
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
Die Meldung could not open file ... ist ok. Die Slave-DB hätte jetzt eigentlich das nächste Transaktionslog erwartet. Aber da die Master-DB das noch nicht geliefert hat, ist auch keines da und die DB macht einen Rollback auf das letzte Log 000000010000003F000000A2. Das Recovery selbst kann auch nochmal etwas dauern (ca. 1-2 Min.). Wenn database system is ready to accept connections im Log erscheint, ist die DB oben - aber noch nicht erreichbar über eine IP-Adresse.
Da in der Slave-DB in der postgresql.conf die listen_addresses vermutlich nur auf localhost stehen, kann man die DB auch nur vom DB-Rechner selbst aus erreichen. Man muss also nun erstmal ein Interface hochziehen, das die gleiche IP hat wie die Master-DB hatte (aber auch nur wenn der Master-Rechner wirklich nicht mehr am Netz hängt) und dann den Eintrag in der postgresql.conf entsprechend abändern. Dann die DB durchstarten und das war's dann eigentlich.
Sollte die DB auf dem Rechner bleiben, muss natürlich das Backup-Skript nachgezogen werden und was man sonst noch so Adimistratives braucht.
Nicht unerwähnt bleiben soll, das man diese Standby-Sache hier natürlich auch automatisieren kann und mittels Heartbeat dafür sorgen kann, das der Failover automatisch stattfindet, wenn die Master-DB ausfallen sollte. Aber das ist ein anderes Kapitel ;-)
Posted at 08:51vorm. März 10, 2009 by cetixx in Tipps | Kommentare [0]
Gentoo: KDE 4.2 beendet sich einfach nach ein paar Klicks
Schon toll, was so passiert, wenn man historische Sachen mit sich rumschleppt. Nachdem KDE 4.2 eine ganze Weile ohne Probleme lief, hatte ich plötzlich das Problem, das sich KDE einfach mal so beendete, nachdem ich z.B. auf File -> New Tab in Konsole geklickt hatte oder im Konquerer ein paar Buchstaben der URL eingegeben habe. Da kam dann irgendwas von wegen xprop und so (weiß die genaue Meldung nicht mehr).
Des Rätsels Lösung: /etc/X11/xorg.conf anpassen und folgende Option rausschmeissen:
Option "Backingstore" "true"
Diese Option war bei meiner Nvidia 8600 GTS gar nix gut. Drum raus damit. Dann tut's.
Posted at 03:15nachm. März 06, 2009 by cetixx in Tipps | Kommentare [0]
PostgreSQL - Warm-Standby Datenbank mit pg_standby Mini HowTo
Eine Möglichkeit eine relativ aktuelle Kopie einer Postgres-DB auf einen anderem Rechner vorzuhalten, ist die Warm-Standby-DB. Während der Master laufend seine Transaktionslogs archiviert, spielt der Slave die Transaktionslogs ein, sobald sie vorhanden sind. Dafür gibt es das kleine C-Programm pg_standby im contrib-Verzeichnis, wenn man die Postgres-Sourcen installiert hat. Ich empfehle grundsätzlich Postgres selber zu kompilieren. Die Pakete der Distributionen sind meist uralt und es hat sich zwischen 8.1 und 8.3 soviel getan, das man fast grob fahrlässig handelt, wenn man noch 8.1 einsetzt ;-)
Grundvoraussetzung bzw. Empfehlung (die man ernst nehmen sollte) ist, das Master und Slave mit der gleichen Postgres-Version arbeiten und am Besten mit Version 8.3 oder höher. Wenn man die Binaries und Libs vom Master kopiert und für den Slave verwendet, hat man da schon mal eine Sorge weniger (ausser man nimmt eh die Pakete der Distribution). Auch die Verzeichnisstruktur sollte auf beiden Rechnern gleich sein, da z.B. ein CREATE TABLESPACE auf dem Slave die gleichen Pfade vorfinden muss. Bei einem Update der Minor-Relase (also z.B. von 8.3.5 auf 8.3.6) sollte man den Slave zuerst updaten. Die neue Version ist sicherlich besser in der Lage, Logs einer älteren Version zu lesen als umgekehrt.
Zunächst bereitet man am besten Master und Slave mal vor - also Verzeichnisstruktur, Binaries usw. das man beide unabhängig voneinander starten könnte.
Die von mir in dem folgenden Beispiel verwendete Verzeichnisstruktur, mag vielleicht etwas eigenwillig erscheinen und findet sich auch auf keiner Distribution so, aber sie hat den großen Vorteil, das ich beliebig viele unterschiedliche Postgres-Instanzen in unterschiedlichen Versionen parallel auf einem Rechner betreiben kann. Damit sich das Ganze nicht ins Gehege kommt, verwende ich immer einen beliebigen Namesraum. Jede Postgres-Instanz heißt also z.B. so, wie eine Figur aus der Muppetshow oder ein Darsteller aus Star Trek (im Folgenden ist das die Variable $DBNAME)...
In der Master-DB kann man schon mal Folgendes eintragen ($DBNAME ist in den folgenden Abschnitten natürlich durch den jeweiligen Instanz-Namen zu ersetzen!):
# - Archiving -
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = '/data/pgsql/bin/$DBNAME/pg_archive_xlog %p %f' # command to use to archive a logfile segment
archive_timeout = 60 # force a logfile segment switch after this
# time; 0 is off
Mit archive_mode=on schalten wir den Archivierungsmodus ein, d.h. Postgres hebt die Transaktionslogs erstmal auf. Nur wenn archive_command erfolgreich war und das Log an die finale Destination kopiert werden konnte, wird das Transaktionslog gelöscht. Es können also mal eine ganze Reihe Transaktionslogs auflaufen, wenn die Netzverbindung z.B. gestört ist und der Zielserver nicht erreicht werden kann. archive_timeout gibt an, wann spätestens ein Logswitch durchgeführt werden soll. Per Default ist ein Logfile 16 MB groß und bei einer Datenbank, in die nicht viel geschrieben wird, kann das schon mal eine ganze Weile dauern, bis die 16 MB voll sind. Man muss hier selbst entscheiden, wie weit man das Zeitfenster öffnen will. 60 Sek. sind ok, wenn man eine schnelle Leitung hat und wenn die Daten auf dem Standby-System einigermaßen aktuell sein sollen. Weniger als 60 Sek. könnten eventl. problematisch werden. Aber Obacht: Die Transaktionslogs sind immer 16 MB groß! Das häuft sich innerhalb von wenigen Stunden ziemlich an, wenn die Dinger nicht wegkommen! Man sollte das deshalb überwachen und per Skript guggen, ob sich die Logs nicht anhäufen und man eventl. eingreifen muss.
Die Master-DB jetzt aber erstmal noch nicht durchstarten.
Das in der postgresql.conf verwendete pg_archive_xlog-Skript sieht so aus:
#!/bin/bash
#
# This script ships the master transaction logs (WAL)
# to the standby database
#
PGINSTANCE=$DBNAME
# Redirect output
exec 1>/data/pgsql/logs/$PGINSTANCE/pg_archive_xlog.log 2>&1
# Some vars
RSYNC_RSH="/usr/bin/ssh -i /home/postgres/.ssh/id_dsa"
XLOG_FROM=$1 # This is the full path to xlog file incl. file name
XLOG_FILENAME=$2 # This is only the file name of the xlog
DEST_XLOG_DIR="/data/pgsql/dumps/$PGINSTANCE/pg_xlog_master"
DEST_USER="postgres"
DEST_HOST="standby.$PGINSTANCE.tauceti.net
# Does source xlog file exist?
if [ ! -f "$XLOG_FROM" ]
then
echo "No such file/path: $XLOG_FROM"
exit 1
fi
# Do we have a dest file name?
if [ -z "$XLOG_FILENAME" ]
then
echo "No destination file name! Please provide one!"
exit 1
fi
# Tranfer file
/usr/bin/rsync -av --rsh=ssh $XLOG_FROM $DEST_USER@$DEST_HOST:"$DEST_XLOG_DIR/$XLOG_FILENAME"
if [ $? -ne 0 ]
then
echo "rsync not successfull!"
exit 1
fi
# Always return exit status 0 if log transfer finished successfully
exit 0
Das Skript an sich ist nicht sonderlich schwierig. Sobald ein Transkationslog voll ist oder der archive_timeout zuschlägt, ruft Postgres dieses Skript auf und übergibt den vollen Pfad inkl. Dateinamen %p und nur den Dateinamen %f an das Skript. Dieses kopiert dann das Transaktionslog auf den Destination-Server. Das Skript verwendet rsync über ssh, um das Log auf den Zielhost zu kopieren. Dazu habe ich mit ssh-keygen -t dsa ein Schlüsselpaar ohne Passwort für den User postgres erstellt (unter dem die Postgres-Instanz i.d.R. läuft). Den Public-Key kopiert man in die authorized_keys vom User postgres (oder wie auch immer der User für die Postgres heißen mag) auf dem Slave-Rechner. Dann loggt man sich einmal als User postgres vom Master aus auf den Slave ein mit dem Key also z.B. /usr/bin/ssh -i /home/postgres/.ssh/id_dsa postgres@standby.$DBNAME.tauceti.net. Das ist nötig, damit man den Host-Key bestätigen kann. Das Ganze kann man auch über NFS machen. Aber NFS ist oft nicht so zuverlässig, wie man sich das wünschen würde. Muss jeder selber entscheiden...
Dann machen wir in der /etc/hosts vom Master einen Eintrag für den Slave. Man kann das natürlich auch per DNS machen, aber mit der hosts geht man auf Nummer sicher, wenn der DNS mal weg sein sollte (XXX natürlich durch die IP des Slave-Rechners ersetzen und tauceti.net natürlich auch durch die eigene Domain ersetzen):
# Database standby
XXX.XXX.XXX.XXX standby.$DBNAME.tauceti.net
Auf dem Slave legen wir jetzt ein Verzeichnis an, in dem das pg_archive_xlog-Skript die Transaktionslogs kopieren soll:
mkdir /data/pgsql/dumps/$DBNAME/pg_xlog_master
chown postgres.postgres /data/pgsql/dumps/$DBNAME/pg_xlog_master
chmod 700 /data/pgsql/dumps/$DBNAME/pg_xlog_master
Sollte sich die Master DB schon im Archive-Modus befinden (also die DB produziert Transaktionslogs), ist's ok ;-) Ansonsten sollte man die Master DB jetzt durchstarten, damit der Archive-Modus (archive_mode = on) aktiv wird (Gut... Durchstarten sollte man natürlich nur, wenn die Instanz nicht gerade benutzt wird und der Cheffe anschließend kommt, weil seine Reports hinüber sind, die gerade 8 Std. gelaufen sind ;-) ).
Nun loggt man sich in die Master-DB ein und führt einen manuellen Logswitch aus. Damit kann man testen, ob die Transaktionslogs dann auf dem Slave-Rechner landen unter /data/pgsql/dumps/$DBNAME/pg_xlog_master
psql -d template1
select pg_switch_xlog();
Sollte das nicht tun, muss man sich wohl oder übel auf Fehlersuche begeben... Als nächstes machen wir uns eine Kopie der Master-DB auf den Slave-Rechner. Dazu loggt man sich wieder auf der Master-DB ein und versetzt die Datenbank in den Backupmodus (Für label kann man irgendwas angeben. Das ist nur ein Marker.):
psql -d template1
SELECT pg_start_backup('label');
Dann kopiert man am Besten auf der Shell mit rsync alle Postgres-Daten auf den Slave-Rechner ($DBNAME und $ZIELRECHNER natürlich entsprechend ersetzen). Der folgende Befehl geht davon aus, das das Datenverzeichnis auf dem Slave noch leer ist (also keine pg_hba.conf, postgresql.conf, usw. vorhanden ist):
cd /data/pgsql/data
rsync -av --rsh=ssh $DBNAME root@$ZIELRECHNER:/data/pgsql/data/
Dann können wir auf der Master-DB den Backupmodus wieder beenden, wenn alle Daten kopiert sind:
SELECT pg_stop_backup();
Nun wechseln wir auf den Slave-Server. Dort haben wir ja unter /data/pgsql/data/$DBNAME jetzt auch die Transaktionslogs der Master-DB liegen (die haben wir oben beim Backup mitkopiert). Die müssen wir erstmal löschen:
cd /data/pgsql/data/$DBNAME/pg_xlog
find . -type f -exec rm {} \;
Mit dem rsync oben haben wir auch die postgresql.conf der Master-DB kopiert. Die sollte man jetzt etwas anpassen. Z.B. wird wahrscheinlich die IP (listen_addresses) nicht stimmen auf dem Slave und den Archive-Modus sollte man auch ausschalten. Also editieren wir die Datei und ändern Folgendes z.B. entsprechend ab:
listen_addresses = 'localhost'
archive_mode = off
Auch wenn Master- und Slave-Rechner eigentlich ungefähr gleich ausgestattet sein sollten, sollte man eventl. noch die Speicherparameter wie shared_buffers oder effective_cache_size runtersetzen, wenn der Slave vielleicht doch nicht soviel Speicher (RAM) hat wie der Master.
Als nächstes bereiten wir eine Datei namens recovery.conf auf dem Slave vor. Wenn diese Datei im Postgres-Datenverzeichnis liegt und Postgres findet diese Datei beim Starten vor, dann wechselt die DB in den Recoverymodus. Dort drin ist dann beim restore_command das oben erwähnte Programm pg_standby hinterlegt. Dieses liesst dann laufend die Transaktionslogs ein, die die Master-Instanz auf den Slave-Rechner unter /data/pgsql/dumps/$DBNAME/pg_xlog_master ablegt. Eine Vorlage liegt dem Postgres-Source bei z.B.:
cp /server/pgsql/8.3.6/share/recovery.conf.sample /data/pgsql/data/$DBNAME/recovery.conf
chown postgres.postgres /data/pgsql/data/$DBNAME/recovery.conf
Die recovery.conf editieren wir dann wie folgt und ändern nur restore_command:
restore_command = '/server/pgsql/8.3.6/bin/pg_standby -t /tmp/pgsql.fin.$DBNAME /data/pgsql/dumps/$DBNAME/pg_xlog_master %f %p %r 2>>/data/pgsql/logs/$DBNAME/standby.log'
-t wenn diese Datei existiert, wird der Recoveryprozess unterbrochen und die DB fährt hoch.
/data/pgsql/dumps/$DBNAME/pg_xlog_master hier sind die Transaktionslogs der Master-DB zu finden.
%f wird von Postgres ersetzt durch den Filenamen des Transaktionslogs, das es benötigt.
%p wird von Postgres ersetzt durch den Pfadnamen, wo die Transaktionslogs hinkopiert werden sollen.
%r wird ersetzt durch den Namen des Files, das den letzten Restartpunkt enthält. Das führt auch dazu, das ältere Transaktionslogs, die nicht mehr gebraucht werden, auch wieder gelöscht werden können, da mit dieser Information pg_standby ja weiß, welche Transaktionslogs nötig sind, um die DB sauber hochfahren zu können. Ansonsten würden die Logs dort bleiben, wo sie sind und man muss sie von Hand wegkopieren.
2>>/data/pgsql/logs/$DBNAME/standby.log hier leiten wir alle Fehlermeldungen in ein Logfile um.
Dann können wir die Standby-DB starten. Wenn man sich nun auf der Master-DB einloggt und wieder einen manuellen Logswitch ausführt, dann müsste man im Logfile der Slave-DB sehen, das dieses Transaktionslog eingespielt also recovered wird. Im Verzeichnis /data/pgsql/dumps/$DBNAME/pg_xlog_master auf dem Slave-Rechner müssten dann nach einer Weile die Logfiles verschwinden (hängt natürlich von verschiedenen Faktoren ab, wenn die Dinger da verschwinden und kann etwas dauern).
Zu beachten ist zum Schluss noch Folgendes: Wenn man in der Master-DB Änderungen in der pg_hba.conf oder postgresql.conf macht, dann muss man diese Änderungen natürlich auch auf der Slave-DB in den entsprechenden Dateien machen!
Die Wiederherstellungsprozedur dann demnächst in diesem Blog ;-)
Posted at 01:00vorm. März 05, 2009 by cetixx in Tipps | Kommentare [0]