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.

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.