Linux auf Laptop

Eine Seite, die einem bei der Auswahl von Linux-fähigen Laptops helfen kann, ist linux-on-laptops.com . Dort finden sich insbesondere Erfahrungsberichte von Benutzern, die auf ihren Laptops Linux installiert haben (erfolgreich oder auch nicht erfolgreich), bzw. mit welchen Problemen sie zu kämpfen hatten. Es finden sich dort aber auch Links zu Seiten, die weiterführende Informationen beinhalten, z.B. über sogenannte Winmodems (jämmerliche Verkrüppelungen echter Modems, um ein wenig Geld zu sparen, dafür die Arbeit dem Prozessor aufs Auge zu drücken. Winmodem deswegen, weil es funktionierende Treiber nicht selten nur für Windows gibt).

Mein Notebook

• IBM Thinkpad A30p (Modell 2653-64G)
• Intel Pentium III Mobile 1200MHz
• 512MB Hauptspeicher
• 48GB IDE-Festplatte
• DVD/CD-RW (IDE)
• 15 Zoll TFT mit ATI Radeon Mobilty LY
• USB (Controller: Intel 82801CA/CAM HUB)
• Firewire (IEEE1394, OHCI Standard)
• PCMCIA (Controller: Ricoh RL5c478)
• Sound: Intel 82801CA/CAM AC 97
• Netzwerk: Intel 82801CAM (ICH3) PRO/100
• Infrarotanschluss über Intel 82801 CAM LPC
• Modem: Lucent Softmodem AMR

Auf dem Laptop ist standardmässig Windows 2000 installiert (gut, XP gibts auch, aber wer will das schon? ;-)). Die Festplatte ist dabei in folgende wichtige Bereiche partitioniert:

1. /dev/hda1, Typ "c" (Win95 FAT32) mit dem vorinstallierten Win2K, bei mir in der Grösse von etwa 15GB
2. /dev/hda2, Typ "1c" (Hidden Win95 FAT32), eine "versteckte" Servicepartition, auf welcher die Installationsdaten liegen (eine Recovery-CD gibt es leider nicht. Eigentlich unverständlich. Man kann diese bei einem eventuellen Crash aber wohl relativ einfach kostenlos vom IBM Kundenservice nachfordern.)

Die IBM-Service-Partition kann beim Booten durch "F11" angesteuert werden. Dazu verwendet IBM einen speziellen Boot-Sektor, der diesen Tastendruck erkennt. Dieser Bootsektor wird bei der Linux-Installation überschrieben, wenn man "lilo" oder "grub" in den Bootsektor der Platte (/dev/hda) installieren lässt. Um dies zu vermeiden, kann man den Bootsektor auch in den Bootsektor der Linux-Partition installieren lassen (sofern diese sich auf einer primären Partition befindet).
Man kann aber auch "grub" dazu bringen, diese Partition doch noch zu booten (also wenn man den Original Bootsektor überschrieben hat). Dazu ein Ausschnitt aus der "menu.lst" von grub:

title windows recovery
    root (hd0,1)
    unhide (hd0,1)
    hide (hd0,0)
    rootnoverify (hd0,1)
    chainloader +1
    makeactive

    unhide (hd0,0)
    hide (hd0,1)

Die Installation

Suse 8.1

Suse 9.1

Ergebnisse

Suse 8.1: Allerdings muss man sagen, dass das ACPI ("advanced configuration and power interface") bei den bisherigen stabilen Linux-Kerneln noch nicht richtig unterstützt wird. Erst beim Kernel 2.6 wird sich das richtig ändern. Momentan kann es funktionieren - oder auch nicht. Beim A30p scheint es zu "nicht funktionieren" zu tendieren. "suspend-to-disc" und automatisches Schlafenlegen beim Schliessen des Deckels werden also wohl noch ein wenig warten müssen. Immerhin ist Intel selbst bei der ACPI-Implementation des Kernels aktiv. Informationen siehe unter acpi.sourceforge.net und developer.intel.com/technology/iapc/acpi/
Das IBM-Bios beherrscht neben ACPI aber immer noch APM. Wenn man dem Kernel beim Booten ein "acpi=off" übergibt, kann man das APM unter Linux recht gut verwenden. Im KDE zeigt sich auch prompt die dann funktionierende Akkulade-Anzeige, und zumindest "Bildschirm aus" und der Standby-Modus arbeiten korrekt. Hibernation hab ich noch nicht "geschafft".
Suse 9.1: ACPI funktioniert (mit dem Thinkpad) ein wenig besser, aber nicht wirklich:

• "Suspend to RAM" tuts zwar, aber das Backlight bleibt eingeschaltet. Ansonsten schaltet das Notebook zwar in den Schlafmodus (auch die Schlaflampe geht an), aber ein Schimmern im Display zeigt die sinnlose Energieverschendung. Dieser Effekt wird aber auch in Meldungen der Kernelliste beschrieben.
• "Suspend to Disk" läuft (Speicherzustand wird in den Swap geschrieben), aber beim nächsten Start stürzt der Kernel beim Zurücklesen übel ab (Reboot). Da heisst es vermutlich einfach "auf einen neuen Kernel" bzw. eine neue ACPI-Version warten.

Suse 8.1: Das Modem ist leider eines der Modelle, die sich auch Winmodem schimpfen. Hierbei wird ein Teil der normalerweise nötigen Elektronik eines Modems durch den Prozessor "nachgebildet". Somit braucht man, im Gegensatz zu einem "normalen" Modem, einen besonderen Treiber, der diese Funktionalität zur Verfügung stellt. Bei Windows ist dies kein Problem (daher auch "Winmodem"), unter Linux ist das leider nicht immer gegeben. Normalerweise sollte man "Winmodems" vermeiden (genauso wie "GDI"-Drucker - man könnte auch "Winprinter" dazu sagen :-/).
Das im Thinkpad verwendete Modem mit AMR-Chipsatz kann mit dem Treiber von Smart Link betrieben werden. Die Treiber finden sich unter linmodems.technion.ac.il/resources.html (bzw. unter linmodems.technion.ac.il/packages/smartlink/ ).
Allgemeine, aber nicht unbedingt ganz aktuelle Informationen zu "Winmodems" finden sich unter www.linmodems.org .
Suse 9.1: Das Modem wird automatisch erkannt und der Treiber (der gleiche, wie oben beschrieben) entsprechend installiert.

Suse 8.1: Das DVD-Laufwerk wird standardmässig ohne DMA betrieben. Dies führt beim Abspielen von DVDs zu Aussetzern im Sekundentakt. Ein einfaches "/sbin/hdparm -d1 /dev/hdc" in z.B. "/etc/rc.d/boot.local" schaltet das DMA wieder an, und DVDs werden nun korrekt abgespielt.
Suse 9.1: DMA ist für das DVD immer noch standardmäßig abgeschaltet. Es gibt im Yast aber inzwischen auch einen eigenen Menüpunkt, um den DMA-Modus aller Geräte zu steuern. Wer nicht obige Zeile eintragen will, kann das jetzt über Yast machen.

Suse 8.1: Das Einführen einer Flashcard (eingesteckt in einen PCMCIA-Flashcard-Adapter) in einen der PCMCIA-Slots führte zu einem Fehler. Die Lösung bestand (erstaunlicherweise) aus dem Austauschen aller Texte "ide_cs" durch "ide-cs" in der Datei "/etc/pcmcia/config". "ide_cs" und "ide-cs" bezeichnen beide Kernel-Module, die vom PCMCIA-Manager beim Einstecken der Karte automatisch geladen werden. Beide der o.g. Module sind für "PCMCIA IDE/ATA disk cards" zuständig - aber das eine ist offenbar erfolgreicher ;-)
Suse 9.1: Oben beschriebene Manipulation ist jetzt nicht mehr nötig. Nach dem Einstecken einer Speicherkarte laufen erstaunlicherweise aber scheinbar beliebig lange Meldungen im syslog durch. Das kann daran liegen, dass Suse einen Automouter für mobile Karten verwendet (-> Ein USB-Memory-Stick taucht nach dem Einstecken im "Arbeitsplatz" (Konqueror-URL: "drives:/") auf, braucht nicht gemountet und auch nicht unmountet werden). Gerade im Hinblick auf diesen Automounter könnte sich noch etwas an der Zuverlässigkeit tun.

Suse 8.1: Firewire funktioniert zumindest mit einer externen Festplatte in einem Gehäuse des Typs Map-H31C1 einwandfrei (na ja, fast: Die erste Verbindungsaufnahme scheitert (Festplatte wird nicht erkannt), Abziehen und erneut Einstöpseln funktioniert dann, auch alle erneuten Einstöpselversuche laufen dann fehlerfrei ab). Datensicherungen sind hier auch deutlich schneller und einfacher durchzuführen als auf CDs. Etwas irritierend ist nur, dass beim "Wechsel" des Betriebssystems (Booten von Windows nach Linux bzw. umgekehrt) das Gehäuse (d.h. die darin befindliche Platte natürlich) erst aus- und wieder eingeschaltet werden muss, damit das OS das Gerät korrekt erkennt.
Nach einem (sicherheitsbedingten) Update auf den Kernel 2.4.21 klappt die Erkennung der Festplatte im Firewiregehäuse leider nicht mehr. Es ist mir noch unklar, woran das genau liegt. Der 2.6er Kernel der Knoppix 3.4 hat keine Probleme.
Suse 9.1: Firewire scheint jetzt recht stabil zu funktionieren. Durch den Automounter erscheinen die Partitionen der o.g. Festplatte nach dem Einstöpseln im Konqueror, und man kann loslegen. Im Internet findet man allerdings oft den Rat, dem Modul für die Plattenemulation (sbp2) den Parameter "serialize_io=1" mitzugeben, damit die Plattenzugriffe serialisiert werden. Dies ist nicht weiter schlimm, da es natürlich keinen Einfluss auf andere Platten hat. Eintragen kann man diesen Parameter in der "modprobe.conf" (bzw. bei Suse "modprobe.conf.local", dort sollten eigene Ergänzungen hinein), nämlich mit "options sbp2 serialize_io=1". Zumindest haben einige GB Datenschaufeleien akzeptabel funktioniert.

Die ATI-Grafikkarte wird gut unterstützt. Insgesamt scheint aber eine Unterstützung von NVidia-Karten (Geoforce) etwas besser zu sein.

Die beim Thinkpad vorhandenen Extratasten sind unter X zunächst ohne Funktion. Die "ThinkPad"-Taste lässt sich zu nichts zu bewegen, die anderen 8 Tasten aber wohl. Dazu sollten diese zunächst so konfiguriert werden, dass sie auch Symbole zurückmelden. Die Datei ".Xmodmap" im Homeverzeichnis ist dazu geeignet (siehe das Manual zu "xmodmap"). Folgende Zeilen aktivieren diese Tasten:

keycode 236 = F20
keycode 178 = F21
keycode 229 = F22
keycode 230 = F23
keycode 231 = F24
keycode 232 = F25
keycode 234 = F28
keycode 233 = F29

Suse 8.1: Zudem hatte ich das Problem, dass die Num-Lock-Taste unter X nicht so wollte: Es wurde ein anderer X-Event gesendet, nämlich "Pointer_EnableKeys". Das führt zu einem Piepen, aber danach kommen beim Betätigen der Tasten des in der Tastatur integrierten Zahlenblocks keine Zahlen, sondern gar keine Zeichen :-O
Folgende Zeile in der ".Xmodmap" korrigiert dieses Verhalten:

keycode 77 = Num_Lock

Der TrackPoint wird problemlos als PS/2-Maus erkannt. Bei einem stationären Arbeiten kann es daneben aber sehr hilfreich sein, eine handelsübliche Maus an den seriellen Anschluss des ThinkPad anzuschliessen. Unter X kann man (zumindest ab XFree 4.0) auch mehrere Mäuse eintragen, die alle gleichzeitig benutzt werden können. Der interne TrackPoint sollte aber der "CorePointer" sein, da der immer vorhanden ist. Die anderen Mäuse können während des Betriebs auch fehlen.
Bei einer SuSE-Distribution kann man einfach eine serielle Maus zur bestehenden Konfiguration hinzunehmen (Hinweis: fast alle seriellen Mäuse verwenden das Microsoft-Protokoll). Aber man kann die Maus auch selbst in der "XF86Config"-Datei aufnehmen.

Thinkpad-Bios-Einstellungen wie z.B. die Prozessorgeschwindigkeit in Abhängigkeit von der Stromversorgung, das Verhalten beim Schliessen des Deckels und viele andere Einstellmöglichkeiten können mit dem Programm tpctl (Thinkpad Control) vorgenommen werden. Dieses Programm ist auf jeden Fall zu empfehlen!

Suse 8.1: USB klappt generell ganz gut (zumindest wenn es passende Treiber gibt, klar :-)). Mein USB-Stick wird korrekt erkannt, und unter KDE taucht (meist, nicht immer :-O) auch direkt ein passendes Icon auf.
Ein Typhoon 6-in-1-Card Reader funktioniert auch einwandfrei (obwohl auf der Packung Linux natürlich nicht erwähnt wird). Es ist nur zu beachten, dass beim Boot-Loader (ob jetzt Lilo oder Grub) nicht die Option "max_scsi_luns=1" angegeben wird. Diese Option verhindert das Suchen nach weiteren logischen Einheiten an einem SCSI-Gerät und wird meist verwendet, um bei nicht ganz sauber gebauten IDE-CDROMs (die ja i.d.R. über die IDE-SCSI-Simulation angesprochen werden) zu verhindern, dass das Gerät acht Mal (LUN 1-8) auftaucht. Der Typhoon-Cardreader hat aber 4 Slots, die in Linux über das gleiche Verfahren (LUN) erkannt werden müssen. Gibt man nun die obige Option an, findet Linux nur einen der vier Slots.
Suse 9.1: Im wesentlichen gleiches Verhalten wie unter Suse 8.1. Wie oben bei "Firewire" schon gesagt, verwendet Suse jetzt einen Automounter ( submount ), um beispielsweise USB-Memory-Sticks ohne Benutzeraktion im konqueror zugreifbar zu machen. Das Ding scheint aber noch nicht ganz perfekt zu arbeiten, wobei hier aber auch noch Randeffekte durch den Kernel (hier sind viele Dinge stark überarbeitet worden) bzw. durch Effekte der Hardware auftreten können. Bei Einstecken meines Sticks erscheinen beispielsweise Tonnen von Logmeldungen, und der Kernel erkennt 4-6 mögliche Geräte bzw. Partitionen. Hier muss man aber auch sagen, dass manchmal die Hardware auch Defizite hat, unter dem Kernel 2.4.21 gab es allerdings keine Probleme. Im Konqueror (URL "drives:/" tauchen dann auch 4-6 Festplatten auf, die man aber nicht "öffnen" kann. Eines der neuen Symbole ist dann aber tatsächlich "USB-Festplatte", und das ist dann korrekt der Stick, der ansonsten auch korrekt funktioniert. Also zum Glück nur eine Unschönheit.

Suse 8.1: IRDA, also die Infrarotschnittstelle, funktioniert einwandfrei - zumindest wenn man das irda-Paket installiert, in dem die High-Level-Treiber enthalten sind. Danach kann beispielsweise ein IRDA-fähiges Mobiltelefon verwendet werden, um eine DFÜ-Verbindung (über /dev/ircomm0 als seriellen Port) herzustellen.
Suse 9.1: Eigentlich funktioniert unter 9.1 IRDA immer noch wunderbar. Erstaunlicherweise aber nicht auf Anhieb, denn da funktioniert einfach nur nix :-/ (Genauer gesagt, ein "irattach /dev/ttyS0 -s" funktioniert nicht). Grund sind einige Module, die nicht automatisch nachgeladen werden. Ich lasse daher die Module "irtty-sir" und "ircomm" beim Booten laden (beispielsweise im "/etc/sysconfig-Editor" von Yast, System -> Kernel -> MODULES_LOADED_ON_BOOT eintragen). Generell geht aber auch, die "modprobe.conf" entsprechend anzupassen, damit diese Module beim Laden von "irda" mitgeladen werden.

Suse 9.1: Bluetooth über einen USB-Dongle der Firma Epox (BT-DG02A) funktioniert erstaunlich reibungslos. Das Gerät wird erkannt und kann über Shellkommandos (z.B. rfcomm, hcitool) oder den kbluetoothd unter KDE verwendet werden - zumindest wenn man sich ein wenig mit Bluetooth und den dort verwendeten "Profilen" (im Sinne von Anwendungsprofilen) beschäftigt hat.
Inzwischen benutze ich Bluetooth, um über mein (neues) bluetoothfähiges Mobilfunktelefon (MFT) ins Internet zu kommen, wenn gerade keine andere Verbindungsmethode greifbar ist. Dazu mußte ich allerdings ein klein wenig tun:

• Überhaupt versuchen, das MFT zu finden: "hcitool scan"
  Hier werden die auffindbaren Bluetooth-Geräte mit Hardwareadresse und Namen ausgegeben. "hcitool" kennt noch weitere Kommandos, die teilweise die Hardwareadresse benötigen. Das MFT muß dabei die Erkennung von außen zulassen (nennt sich bei mir "Sichtbarkeit").
• Um eine Verbindung über PPP herzustellen, benötigt man ein serielles Device. Das MFT (hier ein Nokia E50) bietet über Bluetooth normalerweise ein serielles "Profil" an. Dies kann man mit dem Befehl "sdptool browse" ermitteln. Sortiert nach vorhandenen Geräten werden alle dort zur Verfügung gestellten "Services" angezeigt. Man muß ein wenig in der Ausgabe suchen, um etwas brauchbares zu finden. Bei mir beginnt der interessante Abschnitt mit "Service Name: Dial-Up Networking". Die standarisierte serielle Verbindung hat den Protokollnamen "RFCOMM" (den gibt es mehrere Male), und es ist dort ein Kanal ("Channel") angegeben (eine Zahl, analog der Portnummer beim TCP/IP). Bei mir war dies "Channel: 2". Wie gesagt, nicht verwirren lassen, "RFCOMM" gibt es meist mehrmals.
• Nun passt man die Konfigurationsdatei "/etc/bluetooth/hcid.conf" an. Diese ist entsprechend kommentiert, wichtig sind der lokale Name und zum Beispiel, ob der Bluetooth- Adapter von außen gefunden werden können soll. Dieses sollte man aus Sicherheitsgründen nur dann aktivieren, wenn man eine neue Verbindung aufnehmen soll. Ist die Verbindung "gefestigt" (MFTs und Handhelds bieten normalerweise die Möglichkeit, eine Verbindung nach dem ersten Male in ihrer Konfiguration zu hinterlegen. Dann braucht man das Reagieren auf Anfragen ("hcitool scan") nicht mehr, die Verbindung klappt dann auch ohne), kann man dies deaktivieren.
• Die Verbindungsaufnahme von Bluetoothgeräten wird durch eine "PIN" gesichert. Normalerweise vergibt man auf einem Gerät eine PIN, auf dem anderen muß man diese bei der Verbindungsaufnahme eingeben. Unter Suse 9.1 wird diese PIN in "/etc/bluetooth/pin" eingetragen.
• Die Emulation einer seriellen Verbindung unter Linux geschieht durch Aufruf des Programms "rfcomm". Dessen Konfiguration steht unter "/etc/bluetooth/rfcomm.conf". Dort kann man eine Menge von Devices eintragen. In jedem Block steht die Hardwareadresse sowie der "channel". Beide Daten wurden oben bereits ermittelt.
• Durch Aufruf von "rfcomm bind 0" (für Device 0 in rfcomm.conf) wird ein Device "/dev/rfcomm0" angelegt.
• Nun muß man den PPP-Daemon konfigurieren, über "/dev/rfcomm0" eine Verbindung aufzubauen. Ich habe natürlich eine GPRS-Verbindung eingetragen, zur Konfiguration ziehe man das Handbuch der Distribution zu Rate.
• Man muß natürlich auch das MFT dazu bringen, eine Verbindung zum BT-Dongle herzustellen bzw. zuzulassen. Im Handbuch ist erläutert, was man tun muß, wann die PIN eingegeben werden muß, und wie man es anstellt, daß das Gerät nach der ersten Verbindung die Daten speichert, um später die Verbindung ohne weitere Nachfrage zuzulassen.
• Startet man den PPP-Daemon, wird eine Bluetooth-Verbindung hergestellt (der obige Aufruf von rfcomm legt nur ein Device an, die Verbindung wird da noch nicht hergestellt).
• Mit "rfcomm release 0" wird das Device wieder gelöscht. Dabei darf die PPP-Verbindung natürlich nicht mehr aktiv sein. Es ist auch ratsam, das Device vor dem Abziehen des BT-Dongles wieder zu entfernen.
• Hat der Verbindungsaufbau funktioniert, sollte man die Sicherbarkeit des Telefons nach außen auf jeden Fall wieder abschalten. Die Verbindung mit der Linux-Box klappt nun auch ohne diese Einstellung.

Suse 9.1: WLAN über eine PCMCIA-Karte der Firma Netgear mit integriertem "prism54"-Chipsatz (WG511) (allerdings nur mit WEP-Verschlüsselung) funktioniert auch recht reibungslos.
Der "prism"-Treiber ist seit 2.6.5 im Kernel enthalten, Suse liefert ihn in seinem 2.6.4-Kernel aber auch schon aus. Der Treiber (hier zu seiner Homepage ) benötigt zum Betrieb die Firmware der Karte, diese muss bei jedem Einstecken auf die Karte geladen werden. Zur Zeit muss diese Firmware noch aus dem Windowstreiber(archiv) extrahiert werden. Auf der o.g. Seite steht, wie das geht. In Yast2-Online-Update gibt es dafür aber auch einen Updatepunkt, der dies automatisch tut.
Nach dem Einstecken kann man dann das Interface über Yast2 konfigurieren. Per Hand geht das über iwconfig und ifconfig. Unter KDE gibt es den kwifimanager.
Da das WEP-Verschlüsselungsverfahren allerdings inzwischen mehr als unsicher ist, wollte ich entsprechend auf das sichere WPA-Verfahren umstellen. Dies hat Probleme bereitet, da es mit dem Prism54-Treiber Schwierigkeiten gibt: Obwohl es gehen sollte, hats halt nicht geklappt. Auf Anregung in den News habe ich mit daraufhin eine Karte mit Atheros-Chipsatz gekauft (DWL-G650 von D-Link) und dann folgendes installiert und konfiguriert:

• Den madwifi-Treiber für Atheros-basierte WLAN-Karten (bislang keine USB-Sticks)
• Den WPA Supplicant , der (unter Linux) für die WPA-Verschlüsselung zuständig ist.