Raspberry Pi 3 bootet von USB-Stick und SSD

JoWiemann · 05 August 2016, 10:13:43

siehe hier: http://www.heise.de/newsticker/meldung/Raspberry-Pi-3-bootet-von-USB-Stick-und-SSD-3288619.html

Grüße Jörg

betateilchen · 05 August 2016, 10:44:59

Den Hinweis hatten wir gestern schon irgendwo hier im Forum. Achja - hier :
https://forum.fhem.de/index.php/topic,56196.msg478750.html#msg478750
allerdings ohne Link.

Da bin ich ja mal gespannt, ob mein Netzwerk-Boot per TFTP auch irgendwann "out-of-the-box" funktioniert...

Intruder1956 · 09 August 2016, 13:53:14

Hallo, ich habe es getan

Mein Raspi3 läuft jetzt ohne SD-Karte nur mit einem Intenso SanDisk Ultra USB 3.0 32 GB
Ich bin nach folgender Anleitung vorgegangen
https://raspberry.tips/raspberrypi-tutorials/raspberry-pi-3-bootet-jetzt-ohne-sd-karte-von-usb-stick-oder-festplatte/

Fhem läuft auch, wenn auch nur Testweise
Das einzige was ich bemerkt habe ist, dass der Raspi beim reboot etwas länger braucht, weil er wohl erst nach einer SD-Karte sucht.
Habe dann die Karte neu formatiert und leer eingesteckt. Habe nicht das Gefühl das es schneller ist.
Wenn er dann hochgefahren ist, geht es schnell

Gruß Werner

betateilchen · 09 August 2016, 14:01:01

Für mich ist das "den Teufel mit dem Beelzebub austreiben".

Der USB Port an einem Raspberry ist für mich in keinster Weise zuverlässiger als eine microSD Karte im eingebauten Steckplatz.
Ok, mir ist ja auch noch nie eine SD-Karte im Regelbetrieb eines Raspberry kaputtgegangen.

mahowi · 09 August 2016, 14:59:06

Ich sehe jetzt auch keine so großen Vorteil darin. Ich habe schon lange nur /boot auf der SD-Karte und das System auf einem Stick, bisher problemlos. Wenn der Pi jetzt beim Booten erst nach einer SD-Karte sucht, bevor er vom Stick bootet, kann ich die auch direkt drin lassen.

Probleme hatte ich nur mal, als ich anfangs das System auf einer Festplatte hatte, wahrscheinlich kam es da zu Timing-Problemen.

KölnSolar · 07 Oktober 2016, 22:04:21

weil ich in letzter Zeit 2 Crashs(warum ?) der SD card hatte, hab ich mich auch mal am boot mit USB nach dieser Anleitung
https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/msd.md
probiert. Hat im 2. Anlauf bestens funktioniert. Mein Problem war, dass das .svn-Verzeichnis eine riesige Datei beinhaltete, die meinen Stick(4GB) beim rsync sprengte. ein svn cleanup brachte nix. Ich vermute mal, dass es sich um einen Fehler durch die Abstürze handelte. Denn sie wissen nicht was sie tun: ich hab die betroffene Datei gelöscht

Hat jemand eine Ahnung, was die Ordner und Dateien in /opt/fhem/.svn überhaupt für eine Bedeutung haben ? Hat ja sicherlich etwas mit dem Update von fhem zu tun, aber müssen die im System gespeichert bleiben ?
Grüße Markus
PS: Ein weiterer Grund war, nun die abgestürzte SD zu mounten und analysieren, also der Ursache für die Bootverweigerung auf den Grund zu gehen. Seltsam war nämlich, dass nach sudo shutdown -r now nicht mehr gebootet wurde

Wernieman · 07 Oktober 2016, 23:07:52

.svn wird von svn verwendet. Wie lädst Du Dir fhem herunter?

Direkt eine Dev-Version vom SVN? Sonst solltest Du die Ordner nicht haben ..

KölnSolar · 07 Oktober 2016, 23:57:49

Du kannst Fragen stellen

Ich denke ich hatte die Installation nach Betateilchens Anleitung
https://forum.fhem.de/index.php/topic,53825.0.html
erstellt und ein aktuelles fhem mit

6. Aktuelles fhem aus SVN holen (00:30)

cd /opt
svn checkout svn://svn.code.sf.net/p/fhem/code/trunk/fhem fhem

installiert.

Seitdem mache ich normale Updates.

Sind das also Leichen von der Erstinstallation, die ich löschen kann ?
Danke u. Grüße Markus

Wernieman · 08 Oktober 2016, 15:44:52

Jenau ... wenn Du mit SVN arbeitest, entstehen solche Ordner. Das sind "Zusatzinformationen" für SVN.

KölnSolar · 09 Oktober 2016, 17:15:02

Danke Dir, habs dann mal gelöscht

Mir ist dann heute noch aufgefallen, dass die Umstellung auf Boot-Stick ein Problem erzeugt hat: das presence Modul mit lan-ping hat nicht mehr funktioniert; Grund: es fehlte die "capabilty" cap_net_raw+ep auf dem binary für den ping. Hat jemand eine Idee warum ? Und viel wichtiger: Was kann noch alles an "capabilities" verlorengegangen sein ?
Grüße Markus

RaspiCOC · 26 November 2016, 08:24:59

Nachdem ich jetzt ja auch schon mehrfach Probleme mit der SD-Karte hatte, spiele ich auch mit dem Gedanken, von SSD zu booten.

Mit einem frischen Jessie hat das jetzt auch schon mal wunderbar geklappt. Ich würde nun die Prozedur mit meinem FHEM Image widerholen und mal schauen, ob das zuverlässig funktioniert.

Meine Frage ist jetzt nur: Boot via USB ist ja bei Jessie derzeit noch Beta. Komme ich dann mit einem produktiven System (ja, ja, das macht man nicht) später wieder auf die offizielle Distro von Jessie bzw. Nachfolger drauf?

KölnSolar · 29 November 2016, 21:23:16

scheinbar wird bei einem update/upgrade auch die Boot-Partition verändert, was dann den Reboot verweigert. Mit nachfolgendem sudo BRANCH=next rpi-update scheint es zu funktionieren.
Mein detaillierterer Erfahrungsbericht https://forum.fhem.de/index.php/topic,61206.msg530914.html#msg530914

RaspiCOC · 06 Dezember 2016, 13:20:40

Es ist mal wieder so weit...

Heute Nacht hat sich mein FHEM Pi verabschiedet. FHEM down, SSH ohne Reaktion, Reboot des Pi von USB SSD nach Powercycle ging nicht. Also, wieder die SD-Karte mit Stand von vor einer Woche rein und die zwischenzeitlichen Änderungen nachgezogen. WAF gerade komplett am Boden - Kaffeemaschine ging nicht....

Ich habe so das Gefühl, dass mein alter RPi 1 am zuverlässigsten funktionierte. RPi 2 B und nun auch RPi 3 B haben mich immer wieder und nicht reproduzierbar hinsichtlich des Massenspeichers im Stich gelassen. Klar, ich habe Backups; aber die mache ich natürlich nicht täglich. Das FHEM Backup ist in erster Linie einfach nur groß, ohne dass mir eine Restoremethode bekannt wäre.

Daher überlege ich gerade, ob es nicht möglich wäre, über einen Cronjob immer einen intakten und aktuellen Clon der SD-Karte zu haben. Würde mir das so vorstellen (in Anlehnung an das "Raspberry Boot via USB Tutorial" auf raspberry.org:

Micro SD-Karte in USB-Kartenleser an aktivem USB-Hub mit RPi verbinden. Ggf. unmount...

Code Auswählen

sudo parted /dev/sd*

(parted) mktable msdos
Warning: The existing disk label on /dev/sd* will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
(parted) mkpart primary fat32 0% 100M
(parted) mkpart primary ext4 100M 100%

Die Micro-SD muss m.E. nicht einmal die gleiche Größe wie die "Hauptkarte" haben...

Jetzt das Filesystem auf der frischen Micro-SD einrichten:

Code Auswählen

sudo mkfs.vfat -n BOOT -F 32 /dev/sd*1
sudo mkfs.ext4 /dev/sd*2

Jetzt die neuen Filesysteme mounten:

Code Auswählen

sudo mkdir /mnt/target
sudo mount /dev/sd*2 /mnt/target/
sudo mkdir /mnt/target/boot
sudo mount /dev/sd*1 /mnt/target/boot/

Ggf. nun rsync installieren

Code Auswählen

sudo apt-get update; sudo apt-get install rsync

Und zu guter letzt mit

Code Auswählen

sudo rsync -ax --progress / /boot /mnt/target

einen Clon der "Haupt SD" erstellen.

Damit nach einen Reboot des RPi die geklonte Karte wieder korrekt gemounted wird, ergänze ich dann noch

Code Auswählen

/dev/sd*2       /mnt/target   auto    noatime,umask=000         0       0
/dev/sd*1       /mnt/target/boot   auto    noatime,umask=000         0       0

in der /etc/fstab

Zu guter letzt dann noch einen Cron-Job auf dem RPi einrichten:

Code Auswählen

sudo crontab -e

und im sich öffnenden Editor z.B.

Code Auswählen

30 0 *** rsync -ax / /boot /mnt/target

ergänzen, um täglich um 0:30 Uhr die Synchronisation anzustossen.

Wenn dann mal wieder die SD den Geist aufgibt, habe ich dann eine frische SD-Karte, von der ich booten kann und maximal 24 Stunden altes Image.

So weit meine Überlegungen.

Würde das funktionieren?

Wernieman · 06 Dezember 2016, 13:44:48

Das Problem ist, das bei Deinem Laufenden System die Laufwerke gemountet sind und DU sie nicht einfach "demounten" kannst (z.B: root).Da Prozesse laufen, kann es sein, das Files nicht vollständig auf der SD geschrieben sind etc. ... und somit Deine Kopie ungültig.

ABER .... warumm willst Du jeden Tag eine neue SDCarte generieren? Was ändert sich an Deinem System?

Normalerweile doch nur fhem, d.h. es reicht, wenn Du /opt/fhem täglich sicherst .... eventuell vorher per cron fhem einen "save"-Befehl geben ...

RaspiCOC · 06 Dezember 2016, 14:14:17

Es ändert sichnatürlich nicht täglich was, aber wie wir Spielkinder so sind dann doch auch mal Kleinigkeiten. Ich gebe Dir dahingehend Recht, dass Änderungen an der fhem.cfg nicht das Problem darstellen, jedoch andere Änderungen ausserhalb FHEM - beispielsweise aktuelle Änderungen im Zusammenhang mit Alexa-FHEM.

Nach folgender Anleitung hatte ich eine bootfähige SSD von der im Betrieb befindlichen SD-Karte erstellt: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md. Das hatte wunderbar funktioniert. Da ich ausserhalb der SD-Karte meine Logs schreibe (sprich USB-Stick) wird sich im laufenden Betrieb nicht allzuviel an Daten auf der SD-Karte ändern. Relevant wären ja auch allenfalls Änderungen, die während des rsync-Prozesses geschehen würden.

Mir geht es also um die Frage, ob die von mir beschriebene Vorgehensweise so grundsätzlich funktioniert oder eben nicht.