siehe hier: http://www.heise.de/newsticker/meldung/Raspberry-Pi-3-bootet-von-USB-Stick-und-SSD-3288619.html
Grüße Jörg
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...
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/ (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
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.
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.
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 :o
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 :o
.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 ..
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
Jenau ... wenn Du mit SVN arbeitest, entstehen solche Ordner. Das sind "Zusatzinformationen" für SVN.
Danke Dir, habs dann mal gelöscht ;D
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
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?
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
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...
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:
sudo mkfs.vfat -n BOOT -F 32 /dev/sd*1
sudo mkfs.ext4 /dev/sd*2
Jetzt die neuen Filesysteme mounten:
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 sudo apt-get update; sudo apt-get install rsync
Und zu guter letzt mit
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
/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:
sudo crontab -e
und im sich öffnenden Editor z.B.
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?
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 ...
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 (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.
@RaspiCOC Zu Deinem Wunsch kommt sicherlich noch was von Werniemann. ;) Mir stellt sich aber eher die Frage nach der Ursache. Zumal die Daten in den mir bekannten Fällen erhalten blieben. Guck mal in den Parallelthread
https://forum.fhem.de/index.php/topic,61206.msg530914.html#msg530914
Da sind schon interessante Punkte zusammengekommen. Vielleicht kannst Du dort mal Deine Symptome etc. berichten.
Grüße Markus
Danke für den nochmaligen Hinweis auf den Parallelthread. Ich werde auch noch mal versuchen, diesen zu verstehen und werde gern versuchen eventuell neue Symptomatiken zu beschreiben.
Nach diesem Crash heute nacht will ich aber erst mal auf Stock-Jessie bleiben und SD-Karte nutzen und dennoch in den Genuss von mehr Ausfallsicherheit kommen....
Wenn Du Die Antwort eines "Linux (und Unix) Admins" hören willst:
Die Wahrscheinlichkeit für einen Korrupten Dump eines gemounteten Devices ist so hoch, das es für ein Backup inakzeptabel ist.
Wir haben hier im Forum schon mehrfach und heftig darüber diskutiert ... meine persönliche Meinung s.o.
Allerdings haben andere hier im Forum eine andere Meinung ... ;)
Ok, das bedeutet letztlich, dass ein Dump von einem laufenden System grundsätzlich mit dem Risiko behaftet ist, dass der Target korrupt ist.
Wissend, dass das dann so ist, würde ich weiterhin in regelmäßigen Abständen einen WinDiskImager Dump ziehen. Parallel könnte ich aber die oben beschriebene Vorgehensweise nutzen. Wenn es gut gegangen ist, dann habe ich auf diese Weise ein sehr aktuelles Image. Geht es nicht gut, dann habe ich mein reguläres Backup. Also kann ich ja nur gewinnen.
Das vorausgeschickt; würde die oben beschriebene Vorgehensweise nun funktionieren oder müsste ich dort noch was ändern?
Gesendet von meinem SM-G925F mit Tapatalk
Beim überfliegen habe ich nichts negatives gesehen, außer das DU täglöich die komplette SD neu schreibst. SDs haben nur eine begrenzte Haltbarkeit ....
Das ist sicherlich unerwünscht. Ich ging bisher davon aus, dass rsync doch nur geänderte Dateien verarbeitet. Das würde die Belastung der SD-Karte ja schon signifikant reduzieren. Den Full-Backup mache ich doch nur mit der Option -I (-I, --ignore-times don't skip files that match in size and mod-time) oder irre ich da?
rsync macht aber nur Datei-Sync, z.B. KEINE Kernelupgrades ....