[GELÖST] FHEM-Konfiguration "verschwindet" beim Raspi-Neustart

Begonnen von weeze, 06 Juli 2020, 11:11:51

Vorheriges Thema - Nächstes Thema

weeze

Hallo zusammen,

ich habe schon seit einiger Zeit eine FHEM-Installation, die sehr stabil läuft. Nun habe ich unvermittelt das Problem, dass ein Teil der FHEM-Konfiguration verschwindet, wenn der Raspi neugestartet wird. D.h. die Konfiguration ist nach dem Neustart nicht leer, sondern enthält nur ein Teil der zuletzt angelegten Devices etc.. Die Konfiguration ist jedoch (meiner Meinung nach) zuvor gespeichert worden.

Dazu kommt, dass scheinbar auch das installierte Perl-JSON Paket nach dem Neustart "verschwunden" ist. Es scheint also nicht unbedingt ein Fehler in FHEM zu sein.

Hat jemand eine Idee, wo der Fehler liegen könnte?

MadMax-FHEM

Du hast sicher "save" gedrückt!?

KEIN rotes Fragezeichen mehr vor "shutdown restart"!?

Du editierst NICHT selbst in der cfg rum!?
Auch NICHT über den fhem-internen Editor!!?

Läuft z.B. alexa-fhem/gassistant!?

Auf welcher HW läuft fhem überhaupt!?
(PI mit SD? -> SD defekt!?)
Welches OS!?

Im fhem Log schon mal geschaut!?

Also: mehr Infos!! ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Glaskugel sagt: Deine SD-Karte könnte hinüber sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

weeze

#3
Vielen Dank für die schnellen Antworten :)

Die Konfig-Änderungen sind defintiv gespeichert. Ich erstelle automatisch Backups der FHEM-Installation auf ein NAS und dort sind alle Änderungen enthalten. Nach Shutdown Restart sind die Änderungen auch noch da. Erst bei einem Neustart des Raspberry kommen die Änderungen abhanden.

Meine Vermutung ging daher auch in Richtung defekter SD-Karte. Stutzig gemacht hat mich dabei aber insbesondere, dass per apt-get installierte Pakete nach der Installation problemlos funktionieren und nach einem Neustart verschwunden sind.

Falls niemand eine andere Idee hat, wie dieser Fehler zustande kommen kann, würde ich mein Glück mal mit einer anderen SD-Karte probieren.

MadMax-FHEM

Zitat von: weeze am 06 Juli 2020, 12:22:35
Falls niemand eine andere Idee hat, wie dieser Fehler zustande kommen kann, würde ich mein Glück mal mit einer anderen SD-Karte probieren.

Klingt (klar) Richtung: defekte SD...

Evtl. gleich auf SSD umsteigen!

(und falls noch nicht Buster -> Buster Lite!)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

? Das ist schräg und klingt - was FHEM angeht - danach, als würde der Verweis auf die configfile geändert!?! Also im Startscript des OS steht was anderes als das, was später daraus gemacht wird.

Dass installierte Pakete funktionieren und hinterher weg sein sollen, ist nochmal schräger und klingt dann danach, als würde der Pi dann wieder von einem ganz anderen Medium booten...? Sowas passiert aber meinem Bauchgefühl nach nicht wirklich von allein, da muß jemand dann massiv "nachscripten" o.ä.. Oder es findet alles in einer Ramdisk statt, oder sonst irgendein ziemlich ungewöhnliches setup?

Wenn da nichts klingelt, würde ich eine saubere Neuinstallation anregen, aber in der Konstellation nicht mal mehr sicher auf eine defekte SD-Karte tippen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

weeze

Echt spitze, wie schnell hier geholfen wird - nochmals Danke dafür!

@Joachim:
Wie wäre das Setup mit einer SSD im Idealfall? Festplattengehäude und dann per USB an den Pi? Oder gibt es da was besseres? Der Vorteil der SSD ist wahrscheinlich, dass die mehr Schreibzyklen abkönnen als eine SSD?

@Beta-User:
Ich kenne mich mit Linux nur sehr rudimentär aus, aber auch für mich klingt das alles sehr seltsam. Gescripted habe ich nichts, dazu wäre ich erstmal gar nicht in der Lage. Im Prinzip habe ich nur Raspian und FHEM installiert und dann immer mal wieder Pakete installiert. Bis vor einigen Wochen lief, wie gesagt, alles wie gewünscht.

Falls ich doch bei einer SD-Karte als Speicher bleiben sollte: Kann ich die Daten einfach von der alten auf die neue Karte kopieren oder würdet ihr davon abraten?

Beta-User

Der Vorteil einer SSD ist das definierte "wear-leveraging"; gerüchteweise soll es auch SD-Karten geben, die das können... Gerüchte besagen auch, dass die "besseren Chips" in SSD kommen, und die anderen verwendbaren in SD-Karten, die Technik ist aber im Prinzip (häufig) identisch, und wie stark welcher Effekt zum Tragen kommt, ist teils Glückssache (k.A., inwieweit das auch vom Preis abhängt).

(mit Pi+USB-SSD kenne ich mich nicht (mehr) aus, aber im Prinzip ist zumindest bei den alten USB-Implementierungen@Pi auch ein Datenflaschenhals "built-in", wenn man keine "direktere" Datenanbindung des Massenspeichers an den Prozessor hat).

Was den Umzug angeht: Falls die cfg und statefile intakt sind, ist damit das meiste gerettet. Ich würde es mit einer backup-Rücksicherung nach erfolgtem update versuchen, und dann mal nachsehen, was alles ggf. nicht geht - auch wegen fehlender Perl-Pakete usw.. Kann klappen, muß aber nicht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

#8
Zitat von: weeze am 06 Juli 2020, 14:13:04
@Joachim:
Wie wäre das Setup mit einer SSD im Idealfall? Festplattengehäude und dann per USB an den Pi? Oder gibt es da was besseres? Der Vorteil der SSD ist wahrscheinlich, dass die mehr Schreibzyklen abkönnen als eine SSD?

Naja "Festplattengehäuse" usw. ist wohl etwas "übertrieben" ;)

Ich habe das hier:
https://www.amazon.de/gp/product/B014RBL57E/
https://www.amazon.de/gp/product/B01N9ZWJV2/

für mein fhem, ohne Gehäuse, steht aber wo ich ihne eh nicht sehe ;)

Und das hier für meinen tvheadend Server PI:
https://www.amazon.de/gp/product/B011M8YACM/
(etwas lang aber passt direkt zum Gehäuse)
https://www.amazon.de/gp/product/B01ESQZG6Y/
(kürzeres Kabel aber dafür muss etwas "bearbeitet" werden, weil SATA-Stecker und Gehäuse nicht 100%ig "harmonieren" ;)  )
https://www.amazon.de/gp/product/B077S5G7ZT/
Folgende Platte (aber das ist dann "egal" ;)  ):
https://www.amazon.de/gp/product/B076XWDN6V/

EDIT: bzgl. optimaler Anbindung hat Beta-User sicher recht. Aber ich habe noch keinen Nachteil bemerkt. SSD ist auch per USB schnell genug. Mit gutem Netzteil (und einem PI3 aufwärts) ist es auch bei weiteren USB-Dongels kein Problem... Wobei ich bei meinem tvheadend einen aktiven USB-Hub gebraucht habe (nachdem ich von 2 China-DVB-C Tunern auf einen Hauppauge Dualtuner "umgezogen" bin). Bei meinem fhem habe ich noch einen HM-CFG-USB und einen ZWave-USB stecken UND ein EnOcean Aufsteckmodul und läuft prima mit dem renkforce-USB-SATA... :)

Zitat von: weeze am 06 Juli 2020, 14:13:04
Falls ich doch bei einer SD-Karte als Speicher bleiben sollte: Kann ich die Daten einfach von der alten auf die neue Karte kopieren oder würdet ihr davon abraten?

Tja, kommt drauf an.
Wenn tatsächlich die SD einen Treffer haben sollte, dann stellt sich die Frage: wie "zuverlässig" sind die Daten ;)

Entweder "altes" (verlässliches) Backup nehmen...
...oder mit einem neuen/frisch erstellten probieren...

Von einem Gesamt-Image-Backup halte ich persönlich wenig.
Und "gezogen" per dd oder sonstigem "Direct Copy" auch meist unnötig groß...

Und wenn die SD einen Treffer hat -> Backup Müll!
Wenn "gezogen" während das System läuft: (meist/kann) unbrauchbar...

Was ich schon mal mache: Backup des Gesamtsystems per tar.
Dadurch wird nur der Platz verbraucht, der auch genutzt wird...
...und ich kann auf jedes Speichermedium umziehen, das groß genug ist...

Also auch ganz leicht von einer 64GB Karte auf eine 8GB Karte (sofern die 8GB reichen)...


Du solltest aber generell einen Plan für Backup/Restore haben! :)
Der sollte/könnte ja jetzt "greifen" ;)

Aber eigentlich gehe ich (immer) wie folgt vor:

PI neu aufsetzen: neuestes OS (was ich als "stabil" erachte: aktuell Buster / PI-OS ist mir noch zu neu [und nur für den PI4 "gedacht"!?]) in LITE!!
Dann Grundeinstellungen Pi etc.
fhem installieren: debian.fhem.de -> the easy way
Zusätzliche Pakete und Einstellungen laut meinen Notizen!
(das alles mache ich meist parallel an einem anderen PI, dann steht fhem nicht so lange ;)  )

Backup aktuelles fhem -> backup-Befehl in fhem
fhem und PI stoppen

fhem auf dem neuen PI bzw. der neuen Installation stoppen
Backup einspielen
Starten und wenn meine Notizen komplett und korrekt waren: fertig :)

Wenn nicht: fhem Log und nacharbeiten...
...UND: Notizen vervollständigen/korrigieren!!!

Dauert (weil ich das gelegentlich "übe" ;) bzw. eigentlich immer auf die neueste OS Version gehe [wenn ich sie für "stabil" erachte]) unter einer Stunde...

EDIT: und wenn man einen 2ten PI für die Vorbereitung hat, dann "steht" fhem nur so ca. 5-10min (max)... Also eigentlich halt so lange es dauert das Backup-File von der alten Installation zur neuen zu transferieren bzw. eigentlich nur so lange bis die Backup-Datei "entpackt" ist... ;)

EDIT: hier ist es ganz gut beschrieben https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html Es gibt aber auch einige Threads dazu...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

weeze

Wenn ihr beide den Umzug auf ein aktuelles OS empfiehlt, werde ich einfach alles neu aufsetzen und dann das FHEM-Backup einspielen. Mal schauen wie das klappt.

Danke für die Tipps! Ich werde berichten, ob das den Fehler behoben hat. Kann allerdings etwas dauern, da erstmal andere Sachen dran sind.

MadMax-FHEM

Zitat von: weeze am 07 Juli 2020, 10:02:17
Wenn ihr beide den Umzug auf ein aktuelles OS empfiehlt, werde ich einfach alles neu aufsetzen und dann das FHEM-Backup einspielen. Mal schauen wie das klappt.

Danke für die Tipps! Ich werde berichten, ob das den Fehler behoben hat. Kann allerdings etwas dauern, da erstmal andere Sachen dran sind.

Wenn der Fehler nicht weg ist bzw. der mit apt-get und Modulen sollte/muss dann WEG sein...
...wenn bei fhem noch was nicht passt bzgl. Dingen die aus dem Backup kommen (sollten) -> schauen, ob das Backup (da ja evtl. von defekter SD) "vertrauenswürdig" ist/war (evtl. zum Test mal mit einem älteren Backup gegenprüfen)...

Und egal wie: ein guter (und verm. "überfälliger" ;)  ) Test für Backup/Restore :)

Viel Erfolg, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Vielleicht noch zur Klarstellung: in meinem Beitrag war mit "backup" ausschließlich ein FHEM-Backup gemeint gewesen (daher auch die dringende (!) Empfehlung erst ein (FHEM-)update zu machen vor dem restore), das OS scheint ja in jedem Fall einen Hau zu haben, das sollte man mMn. auf jeden Fall neu aufsetzen, zumal, wenn es ein älteres Release ist.

Bei einem FHEM-Backup dürfte das Risiko auch deutlich geringer sein, dass du dir damit was "komisches" reinziehst; vorher mal reinschauen, ob die cfg intakt ist, schadet aber in keinem Fall...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Kusselin

Hallo, eine Verständnisfrage..,

wenn ich ein Backup von Fhem gemacht habe das auf einem Stretch lief -> kann ich das dann zb wie  von Ottos Seite
https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html
auf ein frisch installiertes buster wieder einspielen?

Danke und Gruss

Gisbert

Zitat von: Kusselin am 08 Juli 2020, 15:03:19
Hallo, eine Verständnisfrage..,

wenn ich ein Backup von Fhem gemacht habe das auf einem Stretch lief -> kann ich das dann zb wie  von Ottos Seite
https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html
auf ein frisch installiertes buster wieder einspielen?

Danke und Gruss

Die Fhem-Dateien haben ja vermutlich nichts mit dem Linuxsystem zu tun, aber an der Stelle nur eine Vermutung.
Was aber auch noch schiefgehen kann, ist eine Kombination eines aktuellen Backups mit aktuellem Fhem auf einen älteren Fhem-Stand. Dann laufen u.U. nicht alle Module bzw. es werden Attribute gelöscht, die nicht zum alten Fhem-Stand passen. Das ist mir passiert als ich einen 2-Monaten alten Snapshot einer LVM-root-Partition eingespielt hatte und mit mit einem aktuellen Fhem-Backup gekoppelt hatte.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Kusselin

Zitat von: Gisbert am 08 Juli 2020, 15:23:32
Was aber auch noch schiefgehen kann, ist eine Kombination eines aktuellen Backups mit aktuellem Fhem auf einen älteren Fhem-Stand.

das kann man nicht fest sagen.....ist also Glückssache??

Zitat von: Gisbert am 08 Juli 2020, 15:23:32
Die Fhem-Dateien haben ja vermutlich nichts mit dem Linuxsystem zu tun, aber an der Stelle nur eine Vermutung.
nehm ich dir nicht ab mit Vermutung 8)