Mit dem Erscheinen des RapberryPi 3 wurde der Betrieb ohne SD Karte möglich. Dies wurde in den Medien hervorgehoben und die hierfür erfoderliche Vorbereitungsprozedur wird vielerorts besprochen, hier am Ende des Beitrags. Beim Pi 3+ soll dieses Verfahren fest voreingestellt sein. Fast unbeachtet blieb, dass durch die erforderlichen Änderungen in den Bootprogrammen und die neu zur Verfügung gestellte Datei „bootcode.bin“ neben den älteren Systemen (Pi1B+, Pi2) auch aktuelle Systeme wie Pi zero mit USB-Hub problemlos von einem USB Massenspeicher gebootet werden können. Lediglich eine kleine FAT32 formatierte SD Karte, die die ca. 50 kB große Datei bootcode.bin enthält, ist erfoderlich.
bootcode.bin von der Organisation über den auf der Seite angegebenen Link herunterladen
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/
SD-Karte in FAT32 formatieren. Normale Formatieroption auf einem Windows Rechner.
Die heruntergeladene Datei auf die SD Karte kopieren. Fertig!
In dieser Konfiguration sollte das Booten von einem USB-Stick funktionieren. Braucht das USB-Medium zur Initialisierung länger als 2 Sekunden, kann die Wartezeit bis zum Bootversuch auf insgesamt ca. 6 Sekunden verlängert werden. Dazu muss auf der SD-Karte die leere Datei „timeout“ ohne Extension - Dateiartbezeichner - angelegt werden s.u..
Als Massenspeicher können USB-Speichersticks und USB-SSD oder Festplatten verwendet werden. Bei Letzteren ist insbesondere auf den Strombedarf zu achten, da der USB-Anschluß am Pi normalerweise nur 600 mA zur Verfügung stellen kann.
Das zu verwendende System von der Organisation herunterladen
https://www.raspberrypi.org/downloads/
oder das aktuelle Volkszähler Image
https://demo.volkszaehler.org/downloads/volkszaehler_latest.zip
Auf meinem Pi2 konnte mit dem aktuellen Volkszähler-Image problemlos gebootet werden und wie im bekannten „How to“ weiter vorgegangen werden. https://wiki.volkszaehler.org/howto/raspberry_pi_image
Das zu verwendende Image wird am einfachsten mit dem Hilfsprogramm ETCHER auf den Massenspeicher geschrieben. Etcher ist für MAC, Linux und Windows Systeme verfügbar und kann auch mit *.zip komprimierten Dateien umgehen.
Der Ablauf ist selbsterklärend. Etcher erkennt den am USB Port angeschlossenen Massenspeicher. Verwendet man einen Massenspeicher, der größer ist als die üblichen USB-Sticks, wie Festplatte oder SSD, so erscheint der Hinweis „large drive“ und es kann keine Auswahl getroffen werden. Erst wenn man in den Einstellungen „unsafe mode“ aktiviert, kann das Laufwerk ausgewählt werden. Aber Vorsicht Etcher bietet dann auch die im System installierten Massenspeicher zur Auswahl an.
Der Flash-Vorgang läuft zügig. Die Vorbereitung zum Booten vom USB-Massenspeicher ins Desktop sind damit abgeschlossen. Seit Raspian Stretch ist der SSH-Zugang über das Netzwerk standardmäßig nicht mehr aktiv. Um SSH zu aktivieren muss auf der Bootpartition die leere Datei „ssh“ ohne Extension angelegt werden.
Bei Linux Systemen geht das mit dem Befehl „touch“, bei Windows Systemen (z.B. Win 10) im Explorer mit Rechtsklick in den offenen Ordner und der Auswahl „Neu“. Dort wird dann Textdokument angewählt, der Dateiname „ssh“ eingegeben und die Extension .txt entfernt.
Sollte sich herausstellen, dass der angeschlossene USB-Massenspeicher zu lange zum Hochfahren braucht, wird auf diese Weise die leere Datei „timeout“ auf die Boot-SD geschrieben.
Dieses Vorgehen wurde mit einem RaspberryPi 2 V1.1 sowie einem P1 B+ mit USB-Stick und einer 120 GB Kingston A400 SSD getestet. Zum Booten mit der SSD wurde timeout benötigt. Ich weiß nicht, ob das an der SSD oder dem SATA zu USB Adapter liegt. Ein RaspberryPi zero mit 3fach USB und LAN Hub bootet bei mir auf diese Weise von einem USB-Stick.
Soll ein WLAN Zugang beim Booten aktiviert werden, so muss ab Raspian Stretch auf der Bootpartition eine Datei „wpa_supplicant.conf“ vorhanden sein, die wie die nachfolgende aufgebaut ist -alle Angaben erforderlich, WPA2-Verschlüsselung-:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE
network={
ssid="IhrNetzwerkname"
psk="IhrNetzwerkSchlüssel"
key_mgmt=WPA-PSK
}
Das Verfahren wurde mit einem Pi zeroW und einem Pi2 V1.1 mit USB-Stick und Pi tauglichem USB-WLAN-Stick getestet.
Gerade das Gerät, mit dem der USB-Boot eingeführt wurde, braucht eine besonders aufwändige Vorbereitung. Es muss auf dem Prozessor ein sog. OTP (One Time Programmable) Register gesetzt werden, das genau einmal programmiert werden kann. Der Vorgang kann also nicht rückgängig gemacht werden. Der SD-Boot ist immer noch möglich, da der Raspi immer zuerst einen SD-Boot versucht.
Zunächst benötigt man eine SD-Karte mit einem neuen Raspian Stretch nach dem 10.04.2018, mit der der Pi3 gebootet wird. Danach wird an das Ende der Datei /boot/config.txt die Zeile program_usb_boot_mode=1 eingefügt, was auf der Shell mit folgender Kommandozeile erledigt werden kann:
echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
Dann muss neu gebootet werden - sudo reboot -. Nun sollte man überprüfen, ob der Programmiervorgang erfolgreich war. Dazu kann mit dem Befehl:
$ vcgencmd otp_dump | grep 17:
das OTP-Rgister ausgelesen werden.
Die Ausgabe muss 17:3020000a lauten, dann war das Programmieren erfolgreich. Die zum Programmieren eingefügte Zeile sollte entfernt werden, damit bei weiterer Verwendung der SD Karte in anderen Pis keine Programmierversuche unternommen werden. Die Datei config.txt kann mit sudo nano /boot/config.txt editiert werde. Es darf keine Leerzeile am Ende stehen.
Damit sollte ein Booten von einem USB-Stick gelingen. Sollte das angeschlossene Gerät länger als 2 Sekunden bis zur Betriebsfähigkeit benötigen, kann durch Setzen des OTP „timeout Registers“ die Boot-Verzögerung um ca. 3 Sekunden auf 5 Sekunden verlängert werden. Dazu muss erneut ein Programmiervorgang über die SD-Karte durchgeführt werden, indem in die Datei /boot/config.txt als letzte Zeile program_usb_boot_timeout=1 eingefügt wird. Das macht man wie oben beschrieben einfach mit der Kommandozeile
echo program_usb_boot_timeout=1 | sudo tee -a /boot/config.txt
Danach ist ein „Reboot“ erforderlich, um die Programmierung durchzuführen. Auch diese Zeile sollte dann wieder aus der config.txt entfernt werden.
https://github.com/raspberrypi/documentation/commit/b81b4d6266c66533a55d0edccf9e468ec9deaa62
Sollte es weiterhin Boot-Probleme von einem USB-Massenspeicher bei einem Pi3 geben, so wird von der Organisation das oben für den Pi2 und Pi1 B+ beschriebene Vorgehen empfohlen.
Die nachstehende Beschreibung der alten Vorgehensweise wurde belassen, da die Angaben zum Kopieren des Systems hilfreich sein können.
In diesem Artikel zeige ich die Schritte, um einen Raspberry Pi mit einer externen (SSD) Festplatte zu betreiben. Der Pi kann leider nur von einer SD-Karte booten. Deshalb habe ich eine 16GB SSD per USB angeschlossen (von der ich nur 8GB nutze). Das Ziel wird es sein, dass zwar von der SD-Karte gebootet wird, alle weiteren Dateien jedoch auf der SSD liegen. Die SD-Karte enthält zwei Partitionen. Eine Boot-Partition und eine Daten Partition. In meinem Fall ist es eine 8GB Karte.
Ein „df -h“ ertellt mir diese Auflistung.
| Dateisystem | Größe | Benutzt | Verf. | Verw% | Eingehängt auf |
|---|---|---|---|---|---|
| rootfs | 7,2G | 3,7G | 3,3G | 54% | / |
| /dev/root | 7,2G | 3,7G | 3,3G | 54% | / |
| devtmpfs | 235M | 0 | 235M | 0% | /dev |
| tmpfs | 49M | 400K | 49M | 1% | /run |
| tmpfs | 5,0M | 0 | 5,0M | 0% | /run/lock |
| tmpfs | 98M | 4,0K | 98M | 1% | /run/shm |
| /dev/mmcblk0p1 | 56M | 19M | 38M | 34% | /boot |
Das rootfs zeigt eigentlich auf /dev/mmcblk0p2, was die zweite Partition der SD-Karte ist.
Ein Backup fertige ich wöchentlich nach dieser Anleitung an: http://www.linux-tips-and-tricks.de/raspiBackup Prinzipiell würde es auch reichen, nur die root Partition (die Große, auf der die Daten liegen) Wiederherzustellen. Ich habe jedoch der Einfachheit halber das gesammte Backup genommen.
Das Restore habe ich mit diesem Befehl durchgeführt:
sudo dd if=/mnt/BackupOnNAS/RaspberryPi/raspberrypi/raspberrypi-dd-backup-20140106-175539 of=/dev/sda bs=4M
Ein „sudo fdisk -l“ liefert nun diese Ausgabe:
Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017b69
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 15523839 7700480 83 Linux
Disk /dev/sda: 16.0 GB, 15999336448 bytes
64 heads, 32 sectors/track, 15258 cylinders, total 31248704 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017b69
Device Boot Start End Blocks Id System
/dev/sda1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/sda2 122880 15523839 7700480 83 Linux
Somit haben wir ein Abbild der SD-Karte auf der SSD Erstellt. D.h. auch, dass die zweite Partition die Datenpartition ist!
Nach dem Restore wird noch geprüft, ob die Root Partition in Ordnung ist. „sudo e2fsck /dev/sda2“ liefert
e2fsck 1.42.5 (29-Jul-2012) /dev/sda2: sauber, 134179/483328 Dateien, 1029190/1925120 Blöcke
„sudo mkdir /mnt/ssd“ erstellt ein Verzeichnis, in das wir per „sudo mount /dev/sda2 /mnt/ssd“ die Root-Partition der SSD mounten. Mit „cd /mnt/ssd“ und „ls“ sehen wir nun die Inhalte der SSD.
Wird später von der Root-Partition der SSD gebootet, sollte diese auch auf sich selbst und nicht die SD-Karte zugreifen. Dafür müssen wir den Eintrag per fstab Ändern.
„sudo nano /mnt/ssd/etc/fstab“ listet die Einträge auf:
proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults 0 2 /dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Anstatt mmcblk0p2 wollen wir /dev/sda2 nutzen. Daher ist der Eintrag entsprechend abzuändern:
proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults 0 2 /dev/sda2 / ext4 defaults,noatime 0 1
[Ctrl]+[o] speichert und [Ctrl] + [x] verlässt den Editor wieder…
Bevor wir weitermachen, wird die SSD wieder entladen: „sudo umount /dev/sda2“ (kommt die Meldung „umount: /mnt/ssd: device is busy.“, so müsst ihr mit „cd ..“ ein Verzeichnis nach oben gehen. Danach klappt es)
In der Boot-Partition der SD-Karte tragen wir nun die Root-Partition der SSD ein.
„sudo nano /boot/cmdline.txt“ bringt den Editor:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Wir möchten anstatt der SD-Karte, die SSD nutzen:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait
Die Spannung steigt. Ein Reboot mit „sudo reboot“… Kommt der PI wieder hoch? … … Ja! Er ist wieder da. Ich kann mich per ssh einloggen.
Wie finde ich jetzt heraus ob wirklich die SSD angesprochen wird? Vorhin habe ich das Verzeichnis /mnt/ssd angelegt. Dieses existiert unter /mnt nicht. D.h. die SSD läuft!