Linux auf dem iBook G4

Linux läuft bekanntlich überall. Daß es nicht überall gleich gut läuft ist auch bekannt. Daß es aber – in meinen Augen – nahezu unbrauchbar auf dem iBook G4 ist, hat selbst mich überrascht. Aber erstmal von Anfang an:

Motivation
Mein iBook wurde unter OS X subjektiv immer langsamer. Besonders wenn einige große Anwendungen, wie z.B. Eclipse liefen, dann war das arme Notebook einfach beim Multitasking überfordert. Das kann u.a. am RAM gelegen haben (512MB), muss aber nicht zwangsläufig, da es einige Zeit zuvor – subjektiv – schneller und flüssiger lief. Nachdem ich letztes Jahr auf dem Desktop zum Arbeiten komplett auf Linux umgestiegen bin, fingen mich auch einige andere Dinge an zunehmend zu nerven, so z.B. das irrsinnig langsame – wenn überhaupt noch funktionierende – X11 (brauche ich z.B. für Inkscape) oder das seltsame, unkomfortable Terminal an dem man sich dauernd stößt sobald man via SSH woanders einloggt. Java 1.6 gibts auch nicht und obs das für PPC überhaupt noch geben wird ist eh fraglich. Das Speichermanagement erscheint mir sehr ineffektiv (abgesehen vom statischen Linken aller Programme) und ob sich Leopard performancemäßig lohnen würde stand auch in den Sternen. Was tun, sprach Zeus? Ganz klar: Linux muss her! Also Backup gefahren, Partitionen neu aufgesetzt, OS X reinstalliert und Gentoo Live-CD eingelegt. Das war im Oktober und ich war guter Dinge. Leider sollte meine Euphorie schnell verfliegen….

Es folgt eine ziemlich lange Anleitung zur Lösung vieler vor allem plattformspezifischer Probleme.

WARNUNG!!! Zeitgleich mit der Installation von Linux auf meinem iBook hörte das WLAN auf korrekt zu funktionieren! Ich bin nicht sicher, ob ich irgendetwas per Software (Treiber/Kernel-Module) verstellt/beschädigt habe, dies ein Nebeneffekt des Bootloaders oder einfach ein zufällig aufgetretener Hardwaredefekt ist. Ich bin seitdem nicht mehr in der Lage, in die Mehrheit aller WLAN-Netze, darunter unverschlüsselte wie die WLAN-Netze meiner Uni, aber auch einige WPA-verschlüsselte zu verbinden. (alle Verbindungen sind “leer”, stehen zwar physisch, aber es kann kein Traffic drüber laufen) Anstandslos funktionieren nur noch mein Heimnetzwerk und das im Büro auf Arbeit (beide WPA). Bis ich ausschließen kann, daß die Ursache softwareseitig sein könnte, rate ich davon ab, nach dieser Anleitung Linux zu installieren! Dieses Problem tritt sowohl unter Linux als auch OS X reproduzierbar auf.

Das Befolgen dieser Anleitung geschieht auf eigene Gefahr!

Grundlegendes
Da ich diesen Artikel ein halbes Jahr später tippe, kann ich mich an die Details zum Aufsetzen des Standardsystems (Kernel, Grafik, Sound, Buttons, Lüfter) nicht mehr so ganz erinnern. Das Aufsetzen dieses Grundsystems war aber an sich nicht schwer; das Gentoo-Handbuch für ppc, die Gentoo Foren, das Gentoo-Wiki und Google bieten eigentlich relativ schnell Antworten auf alle entstehenden Fragen. Das Handbuch sollte man auf alle Fälle lesen, sonst bekommt man die Installation gar nicht erst hin. Eins vorweg: Die Architektur ist dazu gedacht mit OS X zu laufen und OS X ist dazu gedacht unter dieser Architektur zu laufen. Das System sieht unter der Haube dementsprechend… seltsam aus. So läuft z.B. Audio direkt über einen I²C-Bus statt über PCI und das Tastaturlayout wird zunächst chaotisch verdreht sein.

Zumindest wer Gentoo hochfährt wird sich erstmal am blinkenden Frontlicht erschrecken – aber keine Sorge, das lässt sich später in der Kernel-Config abstellen bzw. mit anderen Funktionen belegen. Die Ansteuerung dafür erfolgt über /sys/class/leds/pmu-front-led/trigger; Auslesen mit cat liefert alle möglichen Optionen, echo none nach dort bereitet dem Spuk ein Ende und schaltet die Lampe einfach ganz aus.

Kurz zu X11 um ein wenig Sucherei zu ersparen: Einen ATI-Treiber gibts nicht und damit auch keine 3D-Unterstützung; Grafik ist somit auf das X11-Radeon-Modul bzw. den Framebuffer beschränkt. Für den Monitor habe ich als Frequenzen Horizontal 31.5 – 48.5 und Vertikal 50-70 konfiguriert. Keyboard-Treiber sollte kbd sein, pc104 tuts erstmal. Da das iBook nur die eine Maustaste hat (obwohl Apple auf den großen Rechnern mit der “Mighty Mouse” inzwischen selbst davon abgekommen ist), benötigt man eine Tastenemulation per F10, F11 oder was auch immer. Dies ist der erste Zeitpunkt an dem man merkt, daß (nicht nur) die Tastatur eindeutig zu wenig Tasten hat. Wie diese Emulation funktioniert bzw. wo man sie einstellt, weiß ich leider im Moment nicht mehr, kurzes Googlen sollte aber reichen, falls das nicht schon im Handbuch oder Wiki erklärt wurde.

Kurz zum Sound: Ich verwende das Modul snd-powermac

Kurz zu Funktionstasten: pbbuttonsd ist Dein Freund.

Wie man schon merkt, schreibe ich diesen Artikel nicht für absolute Linux-Newbies und empfehle jedem der jetzt schon nicht mehr mitkommt, es gar nicht erst zu versuchen zu installieren. (jedenfalls nicht mit Gentoo)

Tastenlayout
Zunächst möchte man in der grafischen Oberfläche sicherlich Umlaute tippen können, also wird das deutsche Tastaturlayout ausgewählt. Unter KDE geschieht dies im Control Center unter “Keyboard Layout” als Keyboard model “Apple Laptop”, Keymap de und Variant mac. Als nächstes wir man sich mit der Tatsache konfrontiert sehen, daß Sonderzeichen sich nicht mehr eingeben lassen ohne zum US-Layout zurückzuwechseln. Der Grund ist einfach: Die Mac-Tastatur hat zwar die Tasten ctrl, alt und meta, leider ist alt aber wirklich das PC-alt und nicht etwa – wie unter OS X – ein PC-“alt gr”. Diese gewünschte Funktion nennt sich nicht etwa “compose” (das setzt nur Umlaute etc. zusammen) sondern “ISO level 3 shift” und muss erst noch gemappt werden. Unter KDE gibt es im Control Center den Punkt “Keyboard Layout” und dort den Tab “Xkb Options”. Die gesuchte Option heißt dort “Third level choosers” und in meinem Fall habe ich dort “Left Alt key” ausgewählt. Nützlich ist auch noch die Wahl des Euro-Zeichens unter “Adding the EuroSign […]”. Für alle nicht-KDEler: Das so entstehende, im Konfigurationsdialog angezeigte Kommando lautet: setxkbmap -option eurosign:e,lv3:lalt_switch

Nun wechseln wir mal das Fenster… Uuups, Alt+Tab geht nicht, Meta+Tab will auch nicht?! Klar, man hat sich ja Alt “kaputtgemappt”. Also benötigen wir noch irgendeine Taste wir als dafür misbrauchen können. Dummerweise ist aber kaum noch was übrig auf der Tastatur und fatalerweise lässt sich sogar eine Taste weniger davon verwenden als gedacht, denn laut xev senden linke und rechte Meta-Taste denselben Tastencode. Autsch!!! In meinem Fall habe ich schweren Herzens einfach die Meta-Taste – da unter Linux eh kaum verwendet – mittels xmodmap auf die Funktion eines “Alt” umgebogen; dazu habe ich mir eine Datei ~/.Xmodmap angelegt mit folgendem Inhalt:

keycode 115 = Alt_L

Diese Datei sollte vom Login Manager ausgeführt werden. Hmm, sollte? Wird aber nicht! Zumindest nicht mit KDM; denn wie steht da unter Gentoo in /etc/X11/Sessions/Xsession so schön: # xkb and xmodmap don't play nice together Also ists abgestellt. Hmpf… Abhilfe schafft ein Abändern der Xsession oder ein Autostart-Eintrag mit dem Inhalt: /usr/bin/xmodmap $HOME/.Xmodmap

Ich weiß nicht ob es genau damit zusammenhängt, aber irgendwie ist Alt+Tab (physikalisch Meta+Tab) bei mir seitdem desöfteren virtuell am Hängen (als wäre es Caps Lock). Diese Lösung ist also ein wenig mit Vorsicht zu genießen.

Man kann natürlich auch irgendwie (Google hilft) die (echte!) Enter-Taste, also die links neben den Cursor-Tasten, fürs ISO-Shift verwenden, womit Meta Meta und Alt Alt bleibt. Da man die Mac-Tastenbelegung hat, empfinde aber zumindest ich diese Position als ziemlich verwirrend. Die Verwirrung lässt sich übrigens noch ein wenig steigern, wenn man in KDE unter “Keyboard Shortcuts” auch noch die Option “MacOS-style modifier usage” wählt, womit Control und Meta/Command getauscht werden (dann sollte allerdings wirklich Enter benutzt werden und nicht das was ich getan hab). Alternativ lässt sich natürlich auch Meta auf Enter biegen aber das hab ich hier einfach sein gelassen. Wer es unbedingt tun will, sollte einfach mal eine Runde mit xmodmap rumspielen.

WLAN
Das ist auch eine schöne Geschichte. Es gab ja von Apple zwei verschiedene WLAN-Module, AirPort (802.11b, 11MBit/s) und AirPort Extreme (802.11b/g, 54MBit/s). Während das langsamere Modul schon länger unter Linux unterstützt wurde, war für das schnellere längere Zeit keine Dokumentation und damit auch kein offener Treiber verfügbar. Die Situation änderte sich erst 2007 allmählich und im Oktober (Kernel 2.6.22) verwendete ich noch das Modul bcm43xx. Inzwischen (Kernel 2.6.24) gibt es ein anderes Modul namens b43, welches meiner Meinung nach besser und stabiler läuft. Die Hardware benötigt noch einen Microcode, der zunächst mittels des Tools bcm43xx-fwcutter aus dem Internet geladen und (bei Gentoo) nach /lib/firmware bzw. /lib/firmware/b43 gespeichert wird. Für WLAN-Neulinge unter Linux dürfte noch interessant zu erwähnen sein, daß wpa_supplicant für WPA-Verschlüsselung benötigt wird. /etc/conf.d/net sieht dann in etwa so aus:

modules=( "wpa_supplicant" )
wpa_supplicant_eth2="-Dwext"
config_eth2=( "dhcp" )
dns_servers_eth2="192.168.0.1"

Sieht man beim Booten die Meldung “Your system has a problem assigning persistent names”, dann hat man vermutlich zuviel mit verschiedenen Modulen rumgespielt und muss manuell /etc/udev/rules.d/70-persistent-net.rules anfassen und nicht mehr zutreffendes entfernen.

Hat man beide Module kompiliert und startet beim Booten immer bcm43xx, dann kann man es einfach auf /etc/modprobe.d/blacklist setzen. Anschließend noch update-modules und env-update laufen lassen.

Netzwerk allgemein
Die Finger lassen sollte man momentan (Februar 2008) von NetworkManager bzw. knetworkmanager, denn diese zerschießen zum einen /etc/resolv.conf (sollte ein Symlink sein, vgl. eine funktionierende Gentoo-Distribution) und funktionieren zum anderen eh nicht zufriedenstellend. Ich habs nach viel zu viel Ärger wieder entfernt.

Interessant ist hingegen netplug, welches dafür sorgt, daß beim Wechsel eines Ethernet-Kabels das Interface neu gestartet wird (z.B. um direkt ein neues DHCP zu holen).

Nervig ist das Firewire-Netzwerk. Am Besten gar nicht erst eth1 beim Booten hochfahren, das hat bei mir nur für Hänger gesorgt. (oder man lässt es gleich aus dem Kernel raus)

Fürs DHCP möchte man am Besten das Timeout so klein wie möglich setzen, damit das iBook nicht erst nach 5 Minuten zuende gebootet hat; nach /etc/conf.d/net: dhcpcd_eth0="-t 2"

Die Uhr
Das war auch eine Freude…

Ich bin der “glückliche” Besitzer eines iBooks, dessen Akkuschraube fast seit dem Kaufdatum extrem lose sitzt. Mehrmaliges Nachbessern bei Gravis hat leider nichts gebracht, das Ding ist und bleibt locker. So passiert es schonmal, daß beim Transport der Akku abfällt – und damit, mangels CMOS-Batterie (oder was immer das beim Mac wäre), u.a. die Uhrzeit auf 0 zurückfällt. Linux ist hier leider – durchaus zu Recht – ziemlich empfindlich. Bootet man aus der Vergangenheit, dann wird z.B. das ext3-Dateisystem erstmal komplett geprüft und korrigiert, anschließend ein Neustart durchgeführt und findet sich dann in Gesellschaft von vielen vielen Meldungen der Marke “File has a modification date in the future!” (genaue Meldung grad nicht parat). Hier gibt es genau 3 Möglichkeiten sich zu helfen:

  1. Schnell genug reagieren und nach OS X booten um dort die Zeit neu stellen.
  2. Schnell genug reagieren um in die Open Firmware zu springen und dort die Uhr zu setzen (Googlen).
  3. Zu spät reagieren oder zu faul sein und diese ganze Prozedur inkl. fsck über sich ergehen lassen, dann unter Linux die Zeit setzen.

Allgemein empfiehlt es sich, sich die aktuelle Uhrzeit per NTP zu holen, sobald die Netzwerkdevices up kommen. Dazu am Besten direkt in die /etc/conf.d/net schreiben:

postup() {
        /usr/sbin/ntpdate ptbtime1.ptb.de >/dev/null
        return 0
}

Mit einem associate_timeout_eth2=20 kann man dann noch dafür sorgen, daß beim Booten auf dem am Wahrscheinlichsten verfügbaren Device (hier: eth2, WLAN) genug Zeit zum Verbinden und Synchronisieren gelassen wird.

Bei Dual Boot mit OS X läuft die Uhr übrigens immer auf UTC. Mit diesem Wissen kann (und sollte) man dann auch gefahrlos die Systemzeit zurück in die Hardwareuhr schreiben.

Ein schönes Phänomen, das man dann noch erleben darf – und bisher für mich trotz Dual Boot am festen Rechner neu war -, ist ein kontinuierliches Abgleiten der Zeit zwischen den beiden Systemen OS X und Linux oder auch nur Linux selbst. Linux (zumindest Gentoo) ist so schlau und führt Buch über die Abweichungen der Hardwareuhr. So kann der normale Drift mit jedem Neustellen (i.d.R. NTP-Synchronisieren) der Uhr festgestellt und in Zukunft automatisch beim Hochfahren korrigiert werden. Bedauerlicherweise führt das zu Fehlern wenn Linux nicht als einziges die Kontrolle über die Uhr hat, sondern OS X reinpfuscht oder ein abfallender Akku gelegentlich für Stromausfälle und damit einen Reset der Hardwareuhr sorgt. Korrigiert Linux anfangs noch wild herum (die Korrekturen reichten bei mir von einigen Stunden bis hin zu mehreren Tagen), scheint Linux irgendwann die Abweichungen panikartig vermeiden zu wollen – und traut der Uhr einfach nicht mehr. Die Folge: Die Tageszeit stimmt letztlich (unkorrigiert), aber dem Datum wird plötzlich gar nicht mehr getraut und einfach vom letzten bekannten ausgegangen (also Zeit des Shutdowns). Dieser Fehler hat bei mir Monate überdauert. Erst vor ein paar Tagen stieß ich dann nach vielen okkulten Tips auf einen aufschlussreichen Thread im Gentoo-Forum:

Die Lösung des ganzen Desynchronisationsproblems liegt einfach im Löschen der Datei /ect/adjtime:

Zitat zojas:
there are two hwclock lines in /etc/init.d/clock.

the first line invokes the ‘adjust’ function of hwclock.

the other sets the system clock from the hardware clock.

the adjust function is designed to correct for the drift of the hardware clock. the man page for hwclock describes this in detail (search for ‘The Adjust Function’) but the idea is that whenever the hardware clock is set from the system clock, hwclock remembers the adjustment necessary in /etc/adjtime. After that happens a few times, it calculates an adjustment factor. the adjustment factor gets applied to the hwclock as an offset when you invoke ‘hwclock –adjust’.

you could see this could quickly become disasterous if an outside agent (like Mac OS X) is also adjusting the hardware clock.

Zitat Jaminadi:
My solution was as follows.

  1. Sync my clock
  2. hwclock -w
  3. rm /ect/adjtime
  4. Sync my clock (optional)
  5. hwclock -w

Das war dann auch meine Lösung und mit einem Mal ging wieder alles. Will man den Ärger dauerhaft loswerden, kommentiert man einfach aus dem init-Script die betreffende Zeile mit der Drift-Korrektur aus.

Java und Eclipse
Bedauerlicherweise veröffentlicht Sun keine JREs/JDKs für ppc-Linux. So bleiben nur Blackdown und IBM, wobei Blackdown bei mir schon immer Probleme gemacht hat und im Portage auch gar nicht mehr für Java 1.5 oder höher enthalten ist. Dann gibt es noch ein JDK von IBM, das aber leider nicht auf Apple-Rechner abzielt und somit bei mir zumindest mit Eclipse (SWT?) diverse Abstürze verursacht. Evtl. hat man Glück und es läuft mit export JITC_PROCESSOR_TYPE=6 und dem Parameter -Xnojit – bei mir lässt sich Eclipse leider gar nicht damit zum Laufen bewegen. Die letzte Option stellt dann noch GCJ dar. Nach 4 Stunden ist das dann kompiliert, eine weitere benötigt Eclipse und dann kann man es starten. Langsam. Mit Grafikbugs. Laufen kann man das nicht nennen, es scheint eher zu kriechen. Der Start dauert zwar auch woanders recht lange aber die 2-3 Minuten die man beim gcj mit dem Splash-Screen verbringen muss eh sich mal das Hauptfenster öffnet, stellen hier einen traurigen Negativrekord in der Ausführungsgeschwindigkeit dar. So hab ich das dann bisher auch noch nicht wirklich viel getestet, sondern nur kurz reingesehen. Die Menüs bedienen sich mal sehr flüssig, mal absolut stockend. Ich dachte mir dann, daß das an der Alpha-Version liegen könnte die ich mir installiert hab, aber leider berichten auch massenhaft andere Benutzer über diesen schneckigen Bytecode-Interpreter. Unter ppc-Linux muss man so wohl leider weitestgehend auf Java und Eclipse verzichten – ein Manko aufgrund dessen man sich den dauerhaften Einsatz dann leider doch zweimal überlegt; nach all dem Architektur-Chaos bin ich jetzt jedenfalls erstmal ordentlich desillusioniert was den Einsatz von Linux auf meinem iBook angeht, denn ich programmiere hauptsächlich in Eclipse und ein Fehlen oder extreme Langsamkeit desgleichen ist da ein ziemlich schwerwiegender Nachteil.

Speicherupgrade
Damit GCJ und Eclipse überhaupt kompilieren konnten, brauchte ich dann doch noch das Speicherupgrade, das ich mit Linux eigentlich möglichst umgehen wollte. Mein 14″ iBook G4 hatte ich damals mit insgesamt 512 MB RAM bestellt, da ich der Meinung war, dies würde locker für ein Notebook ausreichen. Davon sind 256MB fest im iBook verbaut (nicht wechselbar). Da mir der Einbau eines Apple-getesteten RAMs bei einem Vertragshändler unverhältnismäßig teuer erschien, ich meinen Hardwareschutzbrief nicht verlieren wollte und eben dieser vor gut einem Monat auslief, stattete ich nun doch mal K&M einen Besuch ab, um mir 1GB PC2700U-25330 (SO-DIMM DDR1 333MHz, Unbuffered, CL 2,5) zu kaufen. Der Verkäufer drückte mir ein Modul des Herstellers Exceleram in die Hand und nach dem relativ unproblematischen Einbau und einem Speichertest unter OS X schien das iBook sich damit auch abzufinden (ausführlich beschriebene Anleitungen finden sich schnell durch Googlen oder in den üblichen Mac-Foren).

Zurück unter Linux erschrak ich dann: Linux greift nur auf 768MB RAM zu, also nur den internen Speicher + das halbe neue Modul. Nachdem ich durch mehrmaliges Booten den Fehler in Linux aber nicht OS X reproduzieren konnte kam ich dann über Google drauf, daß ich unter Linux in den Kernel Unterstützung für High Memory einkompilieren muss. Damit läuft das tatsache und ich frag mich seitdem, ob das PPC- oder Apple-bedingt als “High Memory” gilt…

Offene Probleme
Davon gibt es noch viele. Einige Probleme die es unter anderem noch zu lösen gilt sind:

  • Das oben in der Warnung beschriebene Problem mit meinem WLAN, egal wodurch das nun verursacht wird, Software (Linux) oder Hardware (dann hierfür irrelevant).
  • CPU Throttling – ich habe es bisher nicht hinbekommen, die CPU auf 666MHz (Stromsparmodus) runterzutakten. Somit ist das iBook mit Linux noch nicht wirklich mobil einsetzbar.
  • Konsolenwechsel rufen auffallend häufig dieses Mac-typische und eigentlich für Hardwarefehler stehende Weiß-Rot-Grün-Blau-Testbild hervor (siehe hier im Blog die Posts über die Reparaturen, hervorgerufen wahrscheinlich durch den Designfehler, den der dänische Verbraucherschutz aufdeckte). Danach gibt X11 ohne Reboot keine Grafik mehr aus.
  • Schreibzugriff auf HFS+-Partitionen ist nur mit deaktiviertem Journaling möglich, da sonst Datenverlust droht, da unter Linux zur Zeit das Journal nicht geschrieben wird.
  • 3D-Unterstützung – wird wohl so schnell nicht kommen, wenn überhaupt. Die einzige Möglichkeit ist momentan Software-Rendering via Mesa und das ist erwartungsgemäß sehr langsam. Vielleicht ändert sich etwas, wenn mehr Informationen von ATI/AMD veröffentlicht werden.
  • Java – Evtl. ändert sich auch hier etwas wenn Sun die eigene Java-Plattform weiter öffnet.
  • Flash – wie auch die leidigen Themen Java und 3D fehlt hier eine Binary für PPC-Linux. Sehr schade, denn die Alternativen kommen mit der Mehrheit aller Flash-Dateien nicht klar und somit werden einige Webseiten komplett unbenutzbar.
  • Komfortablere und automatische Netzwerkkonfiguration insbesondere des WLANs in wechselnden Umgebungen. (eher ein Standardproblem als architekturspezifisch) Würde knetworkmanager funktionieren wär das schonmal klasse, tuts aber bisher leider nicht.

Da sich meine Motivation aber dank Eclipse auf einem neuen Tiefpunkt befindet, bin ich mir nicht sicher ob ich diese Lösung noch lange weiter verfolgen sollte.

Positives zum Schluss
Trotz all den Problemen seien hier nochmal einige Vorteile genannt.

Mit MacOnLinux existiert ein hervorragender Virtualisierer (nicht Emulator!) für OS X, der es irgendwie schafft, mit annähernd gleicher Geschwindigkeit zu laufen als sei OS X direkt gebootet worden. Fenstermodus und Vollbild lassen sich dabei parallel benutzen.

Unter Linux ist es mir im Oktober gelungen ein HD-Video fast ruckelfrei wiederzugeben. Nach einem world-Update klappt das leider nicht mehr, zeigt aber dennoch, daß Gentoo offenbar besseren Altivec-Support bietet als viele Programme unter OS X, auch an anderen Stellen stellt man immer wieder überrascht einen Performanceschub fest. Die Geschwindigkeit beim Kompilieren entspricht in etwa einem 2GHz Pentium-Rechner. LaTeX setzt ebenfalls extrem viel schneller als unter OS X. Was dort teilweise 10s oder länger benötigt läuft unter Gentoo genauso schnell wie auf meinem Athlon XP 2400+.

Fazit
Viele ungelöste Probleme auf einer teilweise sehr exotischen Plattform. Ein System zum Basteln mit vielen Narben und offenen Wunden. Wer Zeit hat kann sich daran probieren (sofern ich mein WLAN nicht damit zerschossen hab), aber wer auf Java respektive Eclipse oder sogar Flash angewiesen ist, der sollte sich sehr gründlich überlegen, ob es ihm die Sache wert ist.