oDroid XU4: Booten von SSD/HDD (Ubuntu)
Wie bereits in einem anderen Beitrag beschrieben, ist das Verwenden einer SSD für einen oDroid XU4 genial. Selbstverständlich kann man nicht das gesamte Potenzial wirklich nutzen, da USB 3.0 nicht bei SATA 6 Gb/s mithalten kann. Um schneller als jede microSD Karte oder als der eMMC Speicher zu sein, reichts aber dennoch. Neben den erheblichen Geschwindigkeitsverbesserungen, kann man sich außerdem auf eine erhöhte Zuverlässigkeit und ein besseres Preis/Leistungsverhältnis freuen. Insbesondere die eMMC Speicher sind schweineteuer: 16 GB 45 € – 64 GB 80 €. Hallo? Eine 512 GB Samsung SSD kostet gerade mal 85 €! Um nicht andauernd mit Hard- und Softlinks arbeiten zu müssen, wenn der Speicher des eMMC mal wieder ausgeht, empfehle ich die Festplatte als Systempartition einzurichten. Das geht sowohl für eine SSD, als auch eine HDD, auf dem selben Weg.
Grüße gehen in diesem Zuge raus an jsherm101, der im oDroid Forum einen Artikel für eine Seedbox niedergeschrieben hat. Darin wird nebenbei beschrieben, wie man das rootfilesystem auf eine externe Festplatte verschiebt.
Ich verwende folgende Hardware:
Sabrent USB 3.0 zu SATA Adapter (UASP fähig)*
* hierbei handelt es sich um Affiliatelinks. Das bedeutet, dass ich im Falle eines Kaufes Ihrerseits einen geringen Prozentsatz des Kaufpreises als Vermittlungsgebühr erhalte. Für Sie entstehen dabei keinerlei Mehrkosten.
Festplatte vorbereiten und Konfigurationen anpassen
Bevor wir das System von unserem eMMC/microSD-Speicher kopieren, sollten wir zuerst alle Änderungen vornehmen, damit wir nach dem Kopiervorgang nicht alles nochmal auf der Festplatte anpassen müssen. Zu aller erst sollten wir aber unserer Festplatte ein passendes Filesystem geben. Mit dem Befehl lsblk finden wir heraus, wo in unserem System sich die Festplatte befindet. In meinem Fall ist es /dev/sda :
1 2 3 4 5 6 | root@odroid:~# sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk mmcblk1 179:0 0 29.8G 0 disk ├─mmcblk1p1 179:1 0 128M 0 part /media/boot └─mmcblk1p2 179:2 0 29.7G 0 part / |
mmcblk0 oder mmcblk1 ist dann euer eMMC-/microSD-Speicher. Mit dem Befehl mkfs.ext4 /dev/sda können wir dann das Filesystem EXT4 auf die Festplatte schreiben. Nach etwa einer halben Minute sollte die Festplatte dann bereit sein.
Mit lsblk -f erhalten wir dann die UUID der Partition. Dies ist eine einzigartige ID, die sich nicht ändern wird, wenn ihr die Festplatte z.B. an einen anderen USB-Slot ansteckt:
1 2 3 4 5 6 | root@odroid:~# sudo lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ext4 9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 mmcblk1 ├─mmcblk1p1 vfat boot 52AA-6867 /media/boot └─mmcblk1p2 ext4 rootfs e139ce78-9841-40fe-8823-96a304a09859 / |
Die UUID meiner Festplattenpartition ist 9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 . Die UUID einmal kopieren, wir werden sie gleich brauchen.
Nun werden wir in der boot.ini die Systempartition abändern. Keine Sorge, jegliche Änderungen treten erst nach einem Neustart in Kraft! Die boot.ini könnt ihr mit sudo nano /media/boot/boot.ini öffnen. Im Nano Editor könnt ihr mit Strg+W suchen. Gebt in das Suchfeld bootrootfs ein und bestätigt mit Enter. Ihr werdet eine sehr ähnliche Zeile wie diese finden:
1 | setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes net.ifnames=0" |
Ersetzt dort die UUID von eurer eMMC-/microSD-Partition hinter root=UUID= mit der UUID eurer Festplatte. In meinem Fall sieht es dann so aus:
1 | setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 rootwait ro fsck.repair=yes net.ifnames=0" |
Mit Strg + O können wir den Editor speichern lassen und mit Strg + X den Editor schließen. Die erste Konfigurationsänderung ist damit vollbracht. Sollte später etwas schief laufen und der oDroid XU4 bootet nicht mehr, könnt ihr jederzeit euren eMMC-/microSD-Speicher an eurem PC anschließen und dort die boot.ini wieder anpassen. Es ist daher nützlich sich die bisherige UUID irgendwo aufzuschreiben.
Um für zukünftige Updates der boot.ini durch apt vorbereitet zu sein, empfehle ich außerdem sehr die boot.ini.default unter /media/boot/ anzupassen. Ich habe dort ans Ende der Datei folgende Zeile eingefügt. Denkt bitte daran die UUID durch eure auszutaschen:
1 | bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 rootwait ro fsck.repair=yes net.ifnames=0" |
Als nächstes muss man die /etc/fstab Datei anpassen. Hierbei ist es wieder das selbe Suchen-und-Ersetzen Spiel wie eben. Aus
1 | UUID=e139ce78-9841-40fe-8823-96a304a09859 / ext4 errors=remount-ro,noatime 0 1 |
wird
1 | UUID=9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 / ext4 defaults,errors=remount-ro,noatime 0 1 |
Wie zu sehen ist, habe ich noch die Option „defaults“ miteingesetzt. Diese übergibt folgende Standard-Einstellungen: rw,suid,dev,exec,auto,nouser,async . Schlussendlich können wir endlich mit dem Kopiervorgang beginnen. Dazu benötigen wir das Tool rsync. Installieren kann man es mit dem Befehl apt update && apt install rsync . Um Daten auf die Festplatte schreiben zu können, müssen wir zu Beginn einen Ordner erstellen und die Festplatte darin mounten. Das geht einfach mit dem Einzeiler sudo mkdir /mnt/harddrive && sudo mount -uuid 9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 /mnt/harddrive.
Damit keine inkonsistenten Daten übertragen werden, solltet ihr vor dem Kopieren einmal alle Dienste wie Webserver, Datenbank oÄ. beenden. In meinem Fall war das systemctl stop nginx mysql php7.2-fpm tvheadend raspotify .
Den Kopiervorgang können wir dann mit rsync -aAXvP --exclude={"/dev/*", "/proc/*", "/sys/*", "/tmp/*", "/run/*", "/mnt/*", "/media/*", "/lost+found"} / /mnt/harddrive/ starten. Holt euch einen Kaffee – das kann etwas dauern. Sobald das Kopieren durch ist, würde ich das selbe Kommando nochmal starten, um sicherzugehen, dass in der Zwischenzeit keine Daten verändert worden sind und falls doch, man die Daten mitüberträgt. Meist handelt es sich dabei nur um Logs.
Abschluss
Haben wir die Konfigs angepasst und die Daten übertragen, können wir den oDroid nun mit shutdown -r now neustarten. Wenn der oDroid nach dem Neustart ohne Probleme zu erreichen ist, ist das schon einmal ein sehr gutes Zeichen! Mit df können wir nun verifizieren, dass das Filesystem wirklich auf der SSD/HDD ist:
1 2 3 4 5 6 | root@odroid ~ # df Filesystem 1K-blocks Used Available Use% Mounted on udev 951104 0 951104 0% /dev tmpfs 204244 8248 195996 5% /run /dev/sda 960381672 145143004 766384156 16% / [..] |
Wie man sehen kann, ist /dev/sda unter / gemountet. / ist dabei das Root-Filesystem.
Kommentare (12)
Hi Dennis,
danke für deinen Artikel. Ich bin im gefolgt, aber hatte gerade mit dem angegebenen rsync Befehl meine Probleme. Nachdem ich diesen abgesetzt hatte, hat es die ganze Nacht gedauert und das Ergebnis war eine vollgeschriebene 250 GB externe SSD.
Danach habe ich SSD und Edward an meinen Laptop gehangen und dort mittels eines normalen Kopierens der Dateien den Datentransfer von SD-Karte zu SSD Festplatte gemacht.
Danach lief dann alles bestens.
Außerdem habe ich das Tutorial für mich so angepasst, dass ich nicht die komplette Festplatte /dev/sda mit einem ext4 Dateisystem formatieren, sondern auf der SSD zwei Partitionen erstelle. Eine als Root Partition für den Odroid und eine swap Partition, um dem Odroid RAM-technisch ein wenig unter die Arme zu greifen.
Danke für dieses sehr gute Tutorial
Gruß
Nico
Vielen Dank für deine ausgezeichneten Anleitungen für den XU-4.
Kleiner Fehler bei Benutzung von ‚uuid‘, ein ‚-‚-Zeichen hier:
sudo mkdir /mnt/harddrive && sudo mount -uuid 9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 /mnt/harddrive
Also muss dort entweder:
sudo mkdir /mnt/harddrive && sudo mount –uuid 9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 /mnt/harddrive
oder
sudo mkdir /mnt/harddrive && sudo mount -U 9d4a8ebc-1fa4-4b33-8baf-1fc5d434e6c2 /mnt/harddrive
stehen.
Gruß
Daniel
Danke SilverBury für den Hinweis! Das ist leider durch WordPress bedingt … das ist der Meinung „–“ durch „-“ zu ersetzen. Ich bin bereits an einer Alternativ-Lösung dran … das könnte nur noch ein paar Wochen dauern.
Hallo Dennis,
der rsync Befehl kopiert leider recursiv /mnt/hardware/mnt/hardware/…..
der exclude scheint hier nicht richtig zu funktionieren.
(Odroid HC1 mit Ubuntu 18.04 minimal image)
Moin Klem! Eigentlich sollte genau das nicht tun… hm. Probier es doch mal zusätzlich mit mnt, also:
rsync -aAXvP --exclude={"/dev/*", "/proc/*", "/sys/*", "/tmp/*", "/run/*", "/mnt/*", "mnt", "/media/*", "/lost+found"} / /mnt/harddrive/
cd /
rsync -aAXvP –exclude ‚dev/*‘ –exclude ‚proc/*‘ –exclude ’sys/*‘ –exclude ‚tmp/*‘ –exclude ‚run/*‘ –exclude ‚mnt/*‘ –exclude ‚media/*‘ –exclude ‚lost+found‘ / mnt/harddrive/
By cd / I could exclude relative paths.
Plus destination folder is now mnt/harddrive/ instead of /mnt/harddrive/.
This is preventing infinite nested /mnt/harddrive/ creation on my system.
Thanks a lot, great solution! Just a note for future users to replace the quotation marks and long dash to double dash. Just another victim of wordpress 🙂
Mein XU4 bootet jetzt nicht von der SSD
Letzte Meldung: „random: crng init done“
Wie kann ich wieder von meiner eMMC/SDKarte booten ?
Oh nein, das tut mir Leid zu hören! Laut Google ist das allerdings kein Fehler, sondern damit die Shell am Ende auftaucht, müsstest du nur einmal die Enter-Taste drücken: https://www.raspberrypi.org/forums/viewtopic.php?t=209093
Um die Änderung zurückzuspielen, musst du den eMMC Speicher/die SD Karte in deinen PC stecken und die boot.ini zurück ändern. Unter Windows und macOS sollte die Boot-Partition direkt gemounted werden, so dass du die boot.ini problemlos dort finden solltest. Wenn es doch noch hakt, melde dich gerne! (:
Habe das gleiche Problem – alle Schritte genau befolgt (Danke gll – ich hatte auch Rekursion, aber so geht’s…), mehrfach überprüft und doch die gleiche Fehlermeldung wie bei DeepThought…
Was kann ich tun – der Link hat mir leider auch nicht weiter geholfen…
So hatte es bei mir mit Ubuntu 20.04 geklappt (ohne rekursion)
rsync -aAXvP –exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} / /mnt/harddrive/
Ich hatte auch Probleme mit der System-Kopie mittels rsync, es wurde rekursiv kopiert, die Liste der ausgenommenen Verzeichnisse wurde nicht korrekt übernommen.
Zwei Punkte haben mir hier sehr geholfen:
Zum einen –dry-run => ich konnte die Rekursion sehen, ohne dass Daten kopiert wurden und so mein Troubleshooting vornehmen
Zum anderen –exclude-from=./rsync-exclude.txt => damit habe ich die auszuschließenden Verzeichnisse in eine Text-Datei ausgelagert, je Verzeichnis eine Zeile in der Form /dev/* was ohne Rekursion funktionierte.
Fazit:
rsync -aAXvP –dry-run –exclude-from=./rsync-exclude.txt / /mnt/disk/
wenn das sauber läuft, dann mit
rsync -aAXvP –exclude-from=./rsync-exclude.txt / /mnt/disk/
scharf ausführen.