2 Die Erstinbetriebnahme
2.2 Der erste Start
2.2.2 Vorbereitungen zum Start eines Linux von der SD-Karte
Im Gegensatz zum Raspi gibt es hier weniger Informationen zu den Betriebssystemen und auch weniger Images zum Herunterladen für den CubieTruck. Das diese aber einen ARM-Prozessor und eine Mali-GPU wie viele andere Modelle verwendet, gibt es doch eine kleine Auswahlmöglichkeit.
Vor dem Start sollte man sich die Infos unter folgendem Link ansehen:
http://www.armbian.com/documentation/
Verwendet wurde ein Debian-basiertes Linux unter:
http://www.armbian.com/download/
Auf diesem Link befindet sich eine sehr gute Übersicht über viele verschiedene solcher ARM-Boards von verschiedenen Herstellern.
http://www.armbian.com/cubietruck/
Auswahl: Unter der Listenspalte Vanilla wurde Jessie gewählt.
http://mirror.igorpecovnik.com/Armbian_5.04_Cubietruck_Debian_jessie_4.4.3.zip
Die Zip-Datei von ca. 0,25 GB wurde heruntergeladen und entpackt. In dem Paket befindet sich eine kleine exe-Datei für das Schreiben des Images auf eine SD-Karte unter Windows. Die andere große Datei von ca. 1,0 bis 1,3 GB ist ein Image als raw-Datei. Unter Linux schreibt man diese Datei mit dd auf eine leere SD-Karte, da bei dem Vorgang alle Daten verloren gehen.
'dd bs=1MB if=Armbian_5.04_Cubietruck_Debian_jessie_4.4.3.zip of=/dev/sdx'
Achtung bei Nutzung von dd und der Angabe des zu beschreibenden Mediums „of=/dev/sdx“! Wenn das falsche Medium erwischt wird, ist das sehr ärgerlich da alle Daten unwiederbringlich überschrieben wurden. Ich hatte parallel gparted laufen und sicherheitshalber einen weiteren angeschlossenen USB-Stick '/dev/sdb' gezogen. Ein ausgelöster Reload der Partitionen durch eine Betriebssystemroutine verursachte eine Neuzuordnung genau während jener höchstens drei Sekunden bis dd gestartet wurde, so dass die Lücke zwischen /dev/sda bis /dev/sdd geschlossen wurde und „Schwups“ war das falsche Medium überschrieben. Der USB-Speicherstick enthielt glücklicherweise nur die zip-Datei, die sofort wieder heruntergeladen werden konnte. Somit war kein relevanter Datenverlust entstanden.
Nachdem die SD-Karte beschrieben war, befand sich auf dieser eine primäre Partition von ca. 1,1GB, der restliche Speicherplatz auf der 32GB SD-Karte war noch unbelegt.
Diese SD-Karte könnte nun ohne weitere Bearbeitung in den CubieTruck eingesteckt werden und das System würde booten. Bei dem Bootvorgang würden auch noch Partitionen angelegt oder vergrößert werden. Ich habe aber auf der Karte vorher mit gparted selbst noch Partitionen angelegt und die Größen verändert.
Anbei die Ausgabe der Partitionen mit „fdisk -l“:
Disk /dev/mmcblk0: 29 GiB, 31104958464 bytes, 60751872 sectors
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 16525311 16523264 7.9G 83 Linux
/dev/mmcblk0p2 16525312 60751871 44226560 21.1G 5 Extended
/dev/mmcblk0p5 35280896 56424447 21143552 10.1G 83 Linux
/dev/mmcblk0p6 56426496 60751871 4325376 2.1G 82 Linux swap / Solaris
Wer genau hinsah, fiel vielleicht auf, dass hier eine Lücke am Anfang der erweiterten Partition von ebenfalls fast 8GB vorhanden ist. Das war Absicht um bei Bedarf mittels „gparted“ später die erste Partition zu vergrößern (oder den Weg über die Konsole zu testen). Jedoch zeitnah wurde die Hälfte des freien Bereiches hinzugenommen, da mit den Anwendungen und vor allem Aufheben der Dateien in /var/cache/apt die erste Partition sich doch schneller füllte als angenommen.
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 26079231 26077184 12.4G 83 Linux
/dev/mmcblk0p2 26079232 60751871 34672640 16.5G 5 Extended
/dev/mmcblk0p5 35280896 56424447 21143552 10.1G 83 Linux
/dev/mmcblk0p6 56426496 60751871 4325376 2.1G 82 Linux swap / Solaris
Im Hinblick auf Abstürze und korrupte SD-Karten (dirty bit gesetzt) scheint der CubieTruck beim Booten toleranter als der Raspberry Pi 2 zu sein. Die Notwendigkeit des CubieTruck hier toleranterweise trotzdem von der SD zu booten, würde sonst zu häufig bei einer Fehlbedienung zum Totalverlust auf der SD-Karte führen. Wenn Android starten würde, wäre eine der ersten Fragen während des Startvorgangs, die Frage ob die SD-Karte für Android vorbereitet werden solle. Wenn diese aus Versehen bejaht werden sollte, wären aller Daten auf der SD-Karte verloren, da diese neu partitioniert, formatiert und ein kleiner Teil überschrieben werden würde.
Wenn das "dirty bit" gesetzt sein sollte, der Reparaturversuch beim Selbstcheck während des Hochfahrens scheiterte, befindet sich die SD-Karte nur im read-only Mode. Ein Versuch hierbei andere Medien zu mounten funktioniert in dem Zustand auch nicht, sei noch angemerkt. Passiert dies während des Betriebes, dass die SD-Karte korrumpiert, dann befindet sich die SD-Karte ebenfalls nur noch im read-only Mode. Ein Versuch andere Medien zu mounten funktioniert in dem Zustand wiederum auch nicht. Noch nicht gespeicherte Daten sind damit in der Regel nicht mehr zu retten.
Eine zweite SD-Karte sollte bereit gehalten werden als eine Sicherungskopie für den Fall der Fälle, dass alles schief gehen sollte. Dies gilt vor allem, wenn das System mit einer schwachen Datenverbindung (mobiles Internet, DSL deutlich unter 2MBit) wieder aufgesetzt werden müßte, viele Anwendungen nachgeladen wurden oder viele Konfigurationen am System durchgeführt wurden. Wenn alles ausreichend dokumentiert wurde, wie zum Beispiel in diesem Dokument, dann dauert das Wiederaufsetzen des Systems nur noch ein Viertel der Zeit oder sogar weniger. Auch sehr zu empfehlen ist dies, wenn das Gerät für Personen ohne Linux-Kenntnisse aufgesetzt wurde, die nicht in der Lage sind mit „fsck“ das Dateisystem wieder zu reparieren.
Getestet wurde was passiert, wenn am USB-Anschluss des CubieTruck ein SmartPhone angeschlossen würde und der CubieTruck nur über ein 1A Netzteil versorgt wäre. Bei diesem Experiment ging das Gerät sofort aus. Als zweiter Versuch wurde der CubieTruck mit nur einem 0,5A Netzteil gestartet. In dem Falle gab es nur ein kurzes Blinken der LED und das Gerät war nach wenigen Sekunden (kleiner 5 Sekunden) sofort aus.
Empfohlen wird ein Netzteil mit mindestens 2A für den Betrieb ohne SATA oder USB-Festplatten, beziehungsweise mindestens 3A, wenn diese vorhanden wären. Eine Obergrenze für die Stromversorgung ist zwar nicht angegeben oder aufgedruckt, aber nach der Dicke der Anschlüsse und Leiterbahnen sollte es 4A nicht übersteigen. Wird mehr benötigt, so muss die Versorgung über einen USB-Hub realisiert werden, der nur funktioniert, wenn dessen externe Versorgungsquelle angeschlossen wurde. Ansonsten kann das Gerät auf diese Art und Weise sehr schnell Elektronikschrott werden.
Nachtrag: Über längere Zeit wurde der CubieTruck mit dem 1A Netzteil betrieben. Ausgefallen auf Grund Strommangels war es nur einmal, als zwischen einer 32GB SD-Karte im USB-Adapter und einem 128GB USB-Stick kopiert wurde. Beide Speicherkomponenten waren günstige Sonderangebote und zeichnen sich nicht durch geringen Stromverbrauch aus. Solche Angaben fehlen in der Regel auf diese Produkten. Aus diesem Grunde gibt es bei den verschiedenen Elektronikhändlern und Elektronikläden USB-Strommessadapter um auch solche Messungen durchzuführen.