Die Aufgabe war ganz einfach: Auf einem Netbook sollte testweise ein Ubuntu laufen, wobei das auf der internen SSD installierte System in keinster Weise verändert werden darf. Damit die User-Experience nicht durch einen rausstehenden USB-Stick gestört wird, entschied ich mich für die Installation auf einer SD-Card. Das alternative System sollte dann über das BIOS-Bootmenü gestartet werden, was voraussetzt, dass ein grub im MBR der SD installiert ist.  

Dies erschien keine Herausforderung zu sein, hatte ich doch schon bei meinem EeePC Erfahrungen mit einem Zweitsystem auf einer SD-Card gesammelt. Das macht man doch locker zwischen Frühstück und zweitem Kaffee. 😉 Allenfalls dass es diesmal der Ubuntu Netbook Remix (UNR) sein sollte, versprach einen leichten Anflug von Spannung.

Nach unzähligen Installationen geht das wie im Schlaf: USB-Stick mit Installer für UNR gebaut (was etwas anders geht, als ein normaler Installer-USB-Stick); USB-Stick angesteckt, SD-Card eingelegt, Netbook angeschaltet und via BIOS-Boot-Menü vom USB-Stick gebootet. Anschließend Ubiquity angeworfen, Angaben zu Sprache, Tastatur, Zeitzone und Partionierung vorgeben. Ooops, der Device-Name der SD-Card ist aber seltsam: /dev/mmcblk0p1?!! Aber die Vorgaben zur Partionierung und dem Filesystem lassen sich festelegen und die weitere Installation läuft auch. Aber kurz vor dem Abschluss gibt es einen Fehler: Die Installation von grub sei gescheitert. 🙁

Als einer erneuter Versuch mit dem gleichen Ergebnis endet, stand es fest: Ich hatte ein Problem.

Nach einer Phase der Ratlosigkeit warf ich /dev/mmcblk in das böse Google und finde einen User-Kommentar bei golem.de:

[…] Das belustigende daran ist, dass das superfortschrittliche Betriebssystem Linux nicht wirklich mit SD Karten klarkommt. Und zwar scheiterte eine Installation aller gängige großen Distros bei mir daran, dass die Bootmanager oder Installationsprogramme die SD-Karte als Blockdevice unter /dev/mmcblk* erkannt wird (der SD Controller ist einer der schnellen Sorte, der per PCI und nich USB angebunden ist) und nicht als Festplatte /dev/sd*. Mit Windows 98 war das jedoch kein Problem. Jaja, dieser Fortschritt…
[Benutzer Vollblutprofi bei golem.de]

Bisher hatte ich immer mit meinem EeePC 900 gearbeitet und da scheint die interne Peripherie zu einem großem Teil per USB angebunden zu sein. Vor mir lag aber ein Acer Aspire One und der scheint etwas anders aufgebaut zu sein. (Bei meinem ThinkPad X61s tauchen SD-Karten auch unter /dev/mmcblk0p1 auf.)

Einige Sucherei später stieß ich auf ein (englischsprachiges) Blogposting zur Verwendung von SD-Cards als Träger für das Root-Dateisystem auf dem Acer Aspire One. Dort ist zu lesen:

There is just one problem with the setup: the bios on the Acer Aspire One is unable to boot from the SD card. That means that you can’t just setup Ubuntu on it and restart.
[bikethetam – How to make the Acer Aspire One faster auf UbuntuSolutions]

In dem Blogposting wird weiter ausgeführt, dass auf dem Acer Aspire One ein Zugriff auf die SD-Card im internen Kartenleser nur möglich ist, wenn im Kernel entsprechende Module geladen sind. Das BIOS scheint hierfür keine Unterstützung zu bieten.

An dieser Stelle fiel mir dann auch wieder ein, dass die SD-Card im BIOS-Bootmenü gar nicht aufgetaucht war. Ein Booten von der SD wäre somit auch nicht möglich gewesen, selbst wenn ich das Ubuntu nebst grub auf anderem Weg (z.B. mit einem anderen Rechner oder eines USB-SD-Card-Readers am Aspire selbst) auf der SD erfolgreich installiert hätte.

Im obigem Blogposting wird beschrieben, wie man nach einer Beschreibung bei osnews.com das System so hinfrickelt, dass Ubuntu von einem Root-Filesystem auf der SD-Card läuft. Dabei wird eine mit den entsprechenden Modulen ergänzte initrd im /boot einer auf der internen SDD vorhanden Ubuntu-Installation für die frühe Bootphase genutzt. Im weiteren Bootverlauf wird dann auf die – Dank der Module in der initrd nun erreichbare – SD „umgeschwenkt“. Der Pferdefuß dieser Lösung liegt darin, dass nach dem Booten das System nur noch die /boot auf der SD „sieht“ und bei Updates die maßgebliche initrd im /boot der internen SDD nicht mehr erreichbar ist und auf dem alten Stand bleibt, sodass sie manuell per cp „geupdatet“ werden muss. Ich würde hier einen Ansatz versuchen, bei dem /boot „offiziell“ auf einer eigenen, kleinen Partition auf der internen SSD liegt. Da es dann nur dieses eine /boot gibt, wäre es auch nach dem Booten noch erreichbar und würde damit auch vom System geupdatet werden. Dies auch der Weg, den Ubuntu nutzt, um System-Partionen, die auf Logical Volumes liegen, einzubinden.

Beide Ansätze setzen jedoch voraus, dass man den Inhalt der internen SSD verändert. Die ist aber im vorliegenden Fall (noch) tabu.

So wird es nun doch eine Installationen auf einem – wenn auch sehr kleinen – USB-Stick werden.

Nachtrag 29.06.2009:
Bei meinem Thinkpad X61s taucht die SD auch nicht im BIOS-Bootmenü auf, sodass es dort die gleichen Probleme geben dürfte.