Den Asus EEE richtig demontieren

“Machst ja mächtig einen auf dicke Hose mit deiner Löterei.” – Wieso, das kannst du doch auch? – “Niemals.” – Wetten?

Als ich die Lötanleitung für das zusätzliche Flash-Laufwerk überarbeitet habe, ist mir aufgefallen, dass das hier fehlt: eine Schritt-für-Schritt-Anleitung über den Weg ins Innnere des EEE. Sinn ist, allen die Angst zu nehmen, die sich noch nicht so recht ans Basteln trauen. Continue reading

Asus EEE: Der gute Draht zu mehr Flash

Wieder was gelernt. Nicht so:

…sondern so:

Der richtige Draht für 3,3V

Böser Fehler: meine interne 8GB-Flash-SSD habe ich auf die falsche Versorgungsspannung gehängt und dadurch eine Menge Probleme ausgelöst. Offensichtlich ist die 5V-Spannung, die ich hier abgeschaut und ausgesucht habe, nicht stabil (Okay: der Autor dieser Seite warnt, dass man alle Spannungen noch einmal nachmessen soll.)

Misstrauisch war ich geworden, weil der EEE beim Hochfahren unter Xubuntu immer etwa zwanzig Gedenksekunden ohne Meldung einlegte – als Abstoßungsreaktion auf den Stick –  außerdem entlud sich der Akku auch bei ausgeschaltetem Rechner. Also habe ich das USB-Flash-Memory nicht nur an eine unstabile Versorgungsspannung angeschlossen, sondern auch noch an eine, die nicht abgeschaltet war. Seit ich den Flash-Speicher auf das mittlere Bein gehängt habe – dort sind geschaltete 3,3V zu messen – läuft der Stick nicht nur stabil, er verheizt auch weniger Leistung.

Notiz an mich: Die Umbauanleitung wird ausgebaut und überarbeitet.

Asus EEE PC: Das Schweigen der Journale

Aber EXT3 ist böse, oder?

Klösterliche Schreibstube (Q: Gutenberg digital)

Im Anschluss an die zuletzt erörterten Verdachtsmomente zum Durchhaltewillen von Flash-Speicher möchte ich ergänzen, dass ich die oft gehörte Warnung vor journalbasierten Filesystemen wie EXT3 und ReiserFS für genauso unsinnig halte. Wenn ich das Prinzip richtig verstanden habe – was nicht der Fall sein muss – werden in einem JFS alle Schreibzugriffe erst einmal in einer fortlaufenden Datei protokolliert und diese dann, bei Leerung des Caches, nach und nach auf die Platte geschrieben. Ich sehe nicht, wo das so furchtbar viel Overhead produzieren soll, dass die (Flash-)Platte leidet; im Gegenteil: die schwer belasteten Sektoren, die den Superblock enthalten, werden von dauernden Schreibzugriffen entlastet, die jetzt im Cache bleiben können. Zudem gewinnt man höhere Betriebssicherheit. Aber wie gesagt: ich muss das nicht richtig verstanden haben.

Nicht überzeugt? Dann ist da noch der unwichtige Umstand, dass das vorinstalllierte Xandros alle Daten und Systemveränderungen auf eine EXT3-Partition schreibt. So schlimm kann sie also gar nicht sein.

Und wer immer noch Angst um seinen Flash-Speicher hat, kann ja immer noch tapfer sein und ein JFFS2-System aufsetzen.

eeeXubuntu: Netter Versuch! [Update 4.4.08]

Schön ausgedacht. Hübsch umgesetzt. Und dann kommt die hässliche Praxis. Beim EEE PC unter eeeXubuntu liegt die Tücke im Detail.

Um das vorneweg klarzustellen: es geht nicht nur um den Fuchsschwanz-Faktor. Der EEE-PC soll mein Begleiter sein in Alltag und Berufsleben; ich will ein System, das so sicher ist und komfortabel wie (X)Ubuntu, aber so schnell da wie Xandros, oder wenigstens fast: Notiz machen, Rechner zuklappen = Akku sparen, eine Stunde später die nächste Notiz. Außerdem hätte ich gern ein bisschen mehr Speicher als die knapp 200MB, die die Xubuntu-Installation auf sda1 vom internen Flash-Speicher übrig lässt. Deshalb der Hassel mit internem 8GB-Aufrüststick und der Swap-Partition, sonst könnte ich mich ja auch mit einem normalen Boot zufrieden geben.

Die interne USB-SolidStateDisk - an für sich eine gute Idee…

Nun passiert beim Suspend-to-disk-Tiefschlaf offenbar folgendes (wilde Theorie): die Swap-Partition wird auf Platte geschrieben – auf sda5, im internen Speicher also -, dann geht der EEE schlafen und meldet dabei die USB-Anhängsel ab. Da er sie nach dem Aufwachen wieder ordentlich anzapft, ist das soweit kein Problem.

Außer dass der 8GB-Speicher dann als sdd angemeldet wird, nicht als sdc. Was soweit nicht weiter wild wäre, wenn ich ihn nicht in Form der sdc3-Partition als /home-Verzeichnis gemounted hätte. Das Home-Verzeichnis ist also weg, und der Desktop läuft nicht mehr rund.

Versuche, den Rechner auszutricksen, haben auch nichts gefruchtet:

  • ein Skript in /etc/acpi/suspend.d/ – Ordner, das die Partition abmeldet, ein weiteres, das sie wieder anmeldet,
  • ein Mounten der sdc3-Partition über die UUID statt über den Namen /dev/sdc3.

Und nun? Ein Linux-Übergeek wüsste sicher sofort, was faul ist und was man tun kann. Der Untergeek muss weiter experimentieren.

(Da fällt mir auf, ich habe noch gar nicht geschaut, ob das beim normalen Suspend-to-RAM auch passiert… ts, ts…)

Nachtrag, 4.4.08:
Wie hat der hamburgische Kollege Detlef Schwarzer immer gebrummelt? “Versuch macht kluch!” In der Tat. Das Problem tritt auch bei Suspend-to-RAM auf und lässt sich daher auch gut per dmesg im Log nachlesen: der SCSI-Treiber versucht, die Laufwerke anzusprechen, die sind aber abgeschaltet worden. Der Treiber weiß sich nicht anders zu helfen, als für die wiedergefundenen USB-Laufwerke neue SCSI-Kanäle anzumelden. Deshalb ist mein /home-Verzeichnis plötzlich auf sdd5 statt sdc5, was den Fenstermanager natürlich aus dem Takt bringt.

Immerhin funktioniert ein Trick:

(1) Ins Verzeichnis /etc/acpi/suspend.d eine ausführbare (Skript)-Datei anlegen namens 12-unmount-usb.sh, die den Befehl umount /home ausführt.

(2) Die FSTAB so anpassen, dass das /home-Laufwerk nicht über /dev/sdc5 gemountet wird, sondern über seine UUID.

(3) Im Verzeichnis /etc/acpi/resume.d ein weiteres Skript namens 89-remount.sh, das – naja – mit mount -a alles remounted. Damit ist das home-Verzeichnis immerhin wieder verfügbar, leider gehen einem irgendwann die Laufwerksbuchstaben aus, weil der SCSI-Controller wie gesagt dauernd neue Kanäle registriert, sodass man schon beim zweiten Resume plötzlich das Laufwerk sdf im System hat.

Der Trick ist also keine Lösung – die Skripten müssen also das USB-Laufwerk ordentlich abmelden, damit es an alter Stelle wieder einsortiert wird. Ein erster Anlauf brachte keine Lösung, aber ich arbeite dran.

Asus EEE PC: Xandros oder Xubuntu?

Fuchsschwanzmofa

Hat man ein Mofa nicht nur, damit man den Auspuff aufbohren kann – und einen Fuchsschwanz an den Lenker binden? Für junge Männer trifft das sicher zu. Von daher ist ein Alternativ-Betriebssystem für den Kleinst-Laptop EEE sicher eine feine Sache, die einem das Gerät noch näher bringen kann. Ubuntu bietet sich an – das ist verbreitet, komfortabel und in der gut angepassten Variante eeeXubuntu zu bekommen. Aber hat das Ganze über den Fuchsschwanz-Wert hinaus noch praktischen Nutzen?

Xubuntu-Einstellmöglichkeiten

Ein paar grundsätzliche Überlegungen

Bestandsaufnahme: im direkten Vergleich mit der EEE-Standardinstallation ist (X)Ubuntu-Linux unbestritten

Und da ist das dickste Argument noch gar nicht erwähnt: die riesige Ubuntu-Community, die noch das obskurste Problem längst gelöst hat. Allerdings sind riesige Gewinner-Communities eher abstossend – der “Bayern-München-Effekt”. Die wirklich coolen Säue sitzen in der EEE-Gemeinde, oder? Und sie haben nicht nur (einige wenige) Freunde bei Asus in Taiwan, sie haben auch gute Argumente, lieber am vorinstallierten EEE-Xandros-Linux weiterzuschrauben – trotz aller berechtigten Kritik an der lieblosen Linuxerei auf dem Standard-EEE.

Denn das Xandros hat drei schwergewichtige Argumente für sich:

  • Speed
  • Speed
  • Speed.

Mein schon heftig verbasteltes Xandros kreidlert ab wie ein Epo-Radler. Nach 12 Sekunden ist der Cursor da, nach spätestens weiteren 21 Sekunden ist der Desktop einsatzbereit, nach weiteren 11 Sekunden steht die WLAN-Verbindung. Um komplett abzuschalten, benötigt das System sage und schreibe 10 Sekunden – in dieser Zeit hat eeeXubuntu kaum den Tastendruck ausgewertet.

Die eeeXubuntu-Vergleichswerte für einen normalen Bootvorgang: 42 Sekunden bis zum Login-Bildschirm, der Standard-Desktop steht nach weiteren 11 Sekunden, bis der völlig überflüssige 3D-Schickibuntifuchsschwanz-Fenstermanager compiz übernommen hat, sind noch einmal 42 Sekunden vergangen (ist Warten der wahre Sinn des Lebens?) Heruntergefahren ist Xubuntu in 22 Sekunden.

Etwas besser sieht der Vergleich aus, wenn man eeeXubuntu nicht kaltstartet, sondern in den Tiefschlaf schickt (a.k.a. suspend-to-disk oder hibernate) und wieder aufweckt. 32 Sekunden, bis der Rechner alles gesichert hat und den Winterschlaf erreicht, 30-35 Sekunden, bis er arbeitsfähig wieder vor mir steht. Das ist doch schon besser.

Eine Tiefschlafstudie

Die Tiefschlaffunktion ist sicher der grösste Leckerbissen auf der Palette der eeeXubuntu-Spezialitäten; im Xandros -Kernel ist sie gar nicht hineinkompiliert, was nicht nur Robert Basic Nerven raubte. Mich wiederum kostete es einige Nerven, bis eeeXubuntu wirklich winterschlafen wollte. Letztes Problem war, dass nach dem “Hibernate”die swap-Partition regelmässig verschwunden war – und das ist bei allen so, die die Standardinstallation nutzen. Das Problem liegt interessanterweise im Bootmanager: die entsprechende Grub-Zeile wurde um “resume=/dev/sda5” ergänzt, und das Problem war behoben. Ein bekannter Bug der Standard-Installation mit ubiquity. (Mehr Details hier. )

Die Installation war auch kein Zuckerschlecken: für eine fuchsschwanzige Xubuntu-Experience rät es sich, die Schrauber-Liste im eeeUser-Wiki Punkt für Punkt abzuarbeiten. – Nun denn: Nachdem Xubuntu nun also rund läuft, ist eins im direkten Vergleich nicht mehr zu übersehen: hübsch, aber fett. Ein rundes halbes Gigabyte mehr als meine vergleichbare Xandros-Installation, und da sind die 560MB für die nötige Swap-Partition noch gar nicht gerechnet. (Zum Sinn und Unsinn von Swap auf Flash-Karten hier bald mehr.) Schöne Spielereien wie Compiz verbrennen wertvollen Akku-Strom, ebenso wie all die hübschen Helferlein, die man sich zwangsläufig ins Haus holt – selbst auf dem schlanken XFCE-Desktop.

Halten wir fest: es macht sich bezahlt, dass Asus sein Taschenlinux liebevoll klein und schnell optimiert hat; man spart sich endlose Headerdateien und ganze Regale voller Bibliotheksdateien, die für den EEE ohnehin irrelevant sind. Die Vorteile der Optimierung durch Asus scheinen die grössere Ubuntu-Community auszugleichen – das Xandros bleibt die Nummer eins. Wenn man nicht doch einen Fuchsschwanz will.

Nachsatz

Der grosse Vorteil am Tiefschlaf ist unbestritten: man arbeitet genau da weiter, wo man aufgehört hat. Das Xandros ist zwar wie gesagt schneller, wenn man es komplett herunter- und wieder hochfährt, verbraucht in der Zwischenzeit dann auch keinen Strom, nervt aber, weil man alles, was Office offen hatte, erst mal wieder herstellen muss. Eine Projektidee: alle aktiven Userspace-Programme wie Firefox, Ooo und Mail über so was hier in eine Datei sichern und über ein Startskript wieder aufrufen? (Noch nicht getestet; die Software scheint nicht weiterentwickelt zu werden.)

Noch ein allerletztes PPS: gerade will ich diesen Artikel speichern, da schaltet der EEE ohne Vorwarnung ab. Der Akku war leer, und xubuntu hat’s nicht gemerkt. Da ist wohl noch Bastelei fällig.