[GELÖST] Backup einspielen - geht nicht

[LibertyX]

Der Fehler wird verursacht, wenn man die erste "Beta Firmware" auf der CCU installiert hatte die HMIP Geräte unterstützt hat, diese legte diese Dateien mit einem "Standard Schlüssel an" egal ob Geräte angelernt wurden oder nicht. Ich vermute, dass er diese Beta installiert hatte und daher der Fehler herkommt, mit dem löschen der Dateien wird das Problem beseitigt

siehe viewtopic.php?f=65&t=34497 (Bekannte Probleme/Limitationen)

Per ssh

Code: Alles auswählen

rm -rf /etc/config/hmip_*.conf /etc/config/crRFD/*

ausführen
reboot der CCU
danach sollte der Fehler weg sein, wenn nicht, liegt es dann ggf an etwas anderem.

[Stephan0815]

Willst du ein Backup von der letzten version einspielen? Das ging bei mir auch nicht. Aber mit der vorletzten version ging es

[LibertyX]

Also mit der 2.27.8.20170620 ging es nicht aber mit der 2.27.8.20170501?

Das würde sich mit meinen Erfahrungen decken.

[Stephan0815]

Nein, wenn ich backup genommen habe erstellt mit 20170501 geht es, mit einem backup aus der am Ende 15, ging es nicht

[EckartS]

Mein Problem ist nicht gelöst, aber eingegrenzt:

- Das Backup meiner Installation von RaspberryMatic 2.27.8.20170501 kann ich ohne Probleme auf eine neue SD-Karte mit einem Image von RaspberryMatic 2.27.8.20170501 einspielen.
Das Backup-File selbst ist also wohl in Ordnung.
- Ich kann es aber nicht auf eine SD-Karte mit einem Image von RaspberryMatic 2.27.8.20170620 einspielen.
Es kommt zwar keine Fehlermeldung, aber nach dem Reboot erscheint wieder die nackte Installation ohne Backup.

Dass das Backup/Restore-Programm neuerdings eine Prüfung meiner Konfiguration vornimmt und die bei Programmierfehlern nicht überträgt, wie Xel66 vermutet, erscheint mir nicht plausibel.
Aber woran liegt es dann?

Grüße, EckartS

[Herbert_Testmann]

hallo

Hast Du das Backup mal entpackt und einfach das gesicherte Verzeichnis auf die neue SD Karte an die entsprechende Stelle kopiert. Beim zurück spielen des Backup passiert ja auch nichts anderes.

[LibertyX]

Dass das Backup/Restore-Programm neuerdings eine Prüfung meiner Konfiguration vornimmt und die bei Programmierfehlern nicht überträgt, wie Xel66 vermutet, erscheint mir nicht plausibel.
Aber woran liegt es dann?

Dem ist auch nicht so, dass ist ein sehr einfaches Skript, dass beim Backup den Ordner usr/local gzipt und dann dieses Archiv mit den Dateien (firmware_version, key_index, signature) in ein weiteres tar Archiv packt und folgendermaßen benennt hostname-FWVERSION-yyyy-mm-dd-HHMM.sbk. Beim Restore entsprechend umgekehrt.

Wie Herbert_Testmann schon sagte, kannst du das Archiv einfach entpacken (z.B. 7zip) und die Dateien selbst per ssh oder sftp auf den Raspi verschieben oder du versuchst es mal mit dem von jmaus beschriebenen Restore üper ssh viewtopic.php?f=65&t=37728

Du bist wie gesagt nicht der einzige der bei dem Restore mit der 2.27.8.20170620 Probleme hat, ich musste es auch 3x einspielen bevor es ging.
Beim ersten mal kam die Meldung "Ein Komponente der CCU reagiert nicht" aber ohne weitere Angaben.
Beim zweiten mal ließ es sich zwar einspielen, aber danach bootete der Raspi nur noch bis " Die RaspberryMatic ist noch nicht bereit ..." da blieb er dann stehen bzw hat man die Seite neu geladen "Seite kann nicht geladen werden"

[EckartS]

Ok, dass versuche ich.
Kann ich das tar-file einfach unter Windows entpacken und in die entsprechenden dirs des Raspi verschieben oder gehen da irgendwelche wesentlichen Linux-Dateiattribute verloren?
Grüße, EckartS

[LibertyX]

Die gehen beim entpacken unter Windows verloren, wenn du die Dateien dann per sftp überträgst werden die Berechtigungen von bereits auf dem Raspi vorhandenen Dateien übernommen.

Besser ist es natürlich wenn du es auf dem Raspi entpackst

[EckartS]

Hallo,

die Sache ist durch einen Hinweis von jmaus gelöst, und sie hatte einen ganz banalen Grund: Gleich zwei 4GB SD-Karten, die ich im Wechsel zum Testen benutzt habe, hatten wohl Speicherfehler. Jedenfalls ist ein Restore mit eine weiteren teuren 8GB-Karte ohne Probleme erfolgreich durchgelaufen.

Diese Hürde ist also bewältigt. Danke für Eure Hinweise.

Jetzt am verregneten? Wochenende steht allerdings noch an, zu prüfen, was in V...20170620 die Abstürze von HmIP und VirualDevices auslöst, die reproduzierbar auftreten, wenn man mit WebUI arbeitet.

Grüße, EckartS