piVCCU Update 3.47.22

[deimos]

Hi,

bei Punkt 3 muss ich wiedersprechen. Es wird da nur gefragt, ob man eines hat. Bei nein wird einfach nur das Update abgebrochen.

Viele Grüße
Alex

[eurofinder]

OK, danke für die Informationen. Variante 1 war ich mir nicht ganz sicher, ob das auch funktioniert wie Variante 2.

Dann werde ich in Kürze auch mal ein Update machen.

Gruß und nochmals danke für die Klarstellung
eurofinder

[eiGelbGeek]

Moin ....

Sind die raspberrypi-kernel-headers pivccu-modules-dkms aus dem testing und stable Repro unterschiedlich?

Hatte gestern folgendes Problem .... installiert war 3.47.18 aus dem Testing Repro, habe damals direkt wieder das stable Repro vorgegeben. nun habe ich gestern sudo apt update && sudo apt upgrade -y ausgeführt.... danach wurden die Kernel Module nicht mehr gefunden und folglich konnte natürlich die piVCCU nicht gestartet werden

Da ich nicht lange nach den Problemen suche wollte/konnte (merke nicht kurz vor dem schlafen gehen ein Produktiv System updaten) habe ich die Module deinstalliert ... und auf das Testing Repro umgestellt .. und alles neu installiert... danach lief natürlich alles wieder.

Kann ich daraus schliessen, das ich die Module neu installieren muss, wenn ich zum stable zurück will? oder ist bei mir einfach irgendwas anderes schief gelaufen? apt upgrade -y hat auch einen neuen Kernel installiert ... da könnte ja auch das Problem liegen oder?

PS: Die 3.47.22 läuft ohne Probleme (HM und HmIP im Einsatz)

[deimos]

Hi,

die Kernel Header kommen nicht von mir, sondern sind in einem Repo der Raspbian Foundation.
Das pivccu-modules-dkms Paket ist aktuell in testing und stable identisch.
Ich vermute mal, dass du gleichzeit Kernel und piVCCU aktualisiert hast.
Bei einem Kernel Update werden alle Module auf Dateiebene gelöscht und sind nur noch im Speicher vorhanden. Werden diese dann noch aus dem Speicher entladen, dann können sie nicht mehr geladen werden. Dieses Entladen passiert auch bei Bernden von piVCCU, welches auch im Zuge eine piVCCU Updates erfolgt.
Die Lösung ist aber recht einfach: Durch einen Neustart wird der neue Kernel aktiv, die Module werden automatisch für den neuen Kernel gebaut jnd erst dann startet piVCCU jnd kann dann die neu gebauten Module laden.

Viele Grüße
Alex

[eiGelbGeek]

F*** also hätte vermutlich ein sudo reboot gereicht na dann weiß ich für nächste mal bescheid

[deimos]

Hi,

nachdem keine Probleme aufgetaucht sind, habe ich die Version 3.47.22 jetzt auch im stable apt Repo hochgeladen.

Viele Grüße
Alex

[Daimler]

Hi Alex,

bei Punkt 3 muss ich wiedersprechen. Es wird da nur gefragt, ob man eines hat.

Aber leider ist es dann bereits zu spät - selbst wenn man dann per ctrl-c abbricht, ist das System bereits zerschossen.

Ich falle da (fast) jedesmal auf die Schn...., weil mir genau da (bei der Frage nach dem Backup) einfällt, dass ein Update bei gemountetem Log-Laufwerk in die Hose geht.
Könnnte man / du nicht eine Prüfroutine einbauen?

[deimos]

Hi,

bei Punkt 3 muss ich wiedersprechen. Es wird da nur gefragt, ob man eines hat.

Aber leider ist es dann bereits zu spät - selbst wenn man dann per ctrl-c abbricht, ist das System bereits zerschossen.

Der Trick ist mit "Nein" zu antworten, dann bricht das Update sauber ab mit einem Rollback (im Sinne der Debian Pakete).

Ich falle da (fast) jedesmal auf die Schn...., weil mir genau da (bei der Frage nach dem Backup) einfällt, dass ein Update bei gemountetem Log-Laufwerk in die Hose geht.

Erzähl mehr dazu, dieses Problem wurde bisher nie an mich rangetragen.

Könnnte man / du nicht eine Prüfroutine einbauen?

Für das Vorhandensein eines Backups? Schwierig bis unmöglich. Klar könnte ich da irgendwas einbauen, wie lange das letzte Backup her ist, aber das sagt nichts aus, wer weiß, ob das Backup wirklich noch vorhanden ist oder vielleicht ist ein älteres Backup auch noch absolut valide, weil sich nichts geändert hat. Aber nehmen wir an, man hätte da tatsächlich einen Weg für eine solche Prüfung: Wenn die sagt "Passt nicht", dann kann ich nur das machen, was jetzt aktuell passiert, wenn man bei der Frage mit Nein antwortet.

Viele Grüße
Alex

[Daimler]

Hi,

Der Trick ist mit "Nein" zu antworten, dann bricht das Update sauber ab mit einem Rollback (im Sinne der Debian Pakete).

OK, danke!
Gut zu wissen - das war mir nicht bekannt.

Erzähl mehr dazu, dieses Problem wurde bisher nie an mich rangetragen.

Wie erwähnt, habe ich die 'Schreiblaufwerke' (Logs, HPCL-Logs und Backup) auf ein Serverlaufwerk gemountet.

Code: Alles auswählen

//192.168.10.53/HomeMatic/PI/Produktiv_piVCCU3/Backup /mnt/Backup cifs ....
//192.168.10.53/HomeMatic/PI/Produktiv_piVCCU3/Logs /var/lib/piVCCU3/rootfs/mnt/Logs cifs ....

Wenn diese Mounts beim Update bestehen, kommt dann während des Updates irgendeine Lese- oder Schreibfehlermeldung (Verzeichnis nicht vorhanden) und das Update bricht ab.
Dann ist Komplett-Restore angesagt!
Verzeihe mir bitte, das ich nicht die exakte(n) Fehlermeldungen liefern kann, aber ich möchte es jetzt ungern wiederholen!

[deimos]

Hi,

Verzeihe mir bitte, das ich nicht die exakte(n) Fehlermeldungen liefern kann, aber ich möchte es jetzt ungern wiederholen!

Durchaus verständlich

Wenn du mir verrätst, wie und wo du die Mount angelegt hast, kann ich aber versuchen das in einem Testsystem nachzustellen.

Viele Grüße
Alex