Könnte Update von Raspberry Pi OS zu Problemen bei FHEM führen?

Begonnen von Dracolein, 28 September 2021, 07:21:42

Vorheriges Thema - Nächstes Thema

Dracolein

Guten Morgen zusammen,

ich weiß, ich bin mit folgendem ein ungern gesehener Außenseiter hier, wenn ich zugebe, dass FHEM bei mir unter Raspbian (mit GUI) problemlos läuft.
Folgende Frage habe ich im Vorfeld, um möglichen Schwierigkeiten aus dem Weg zu gehen bzw. mich für den Fall zu wappnen.

Mein FHEM-System inkl. Raspberry Pi mit Raspberry Pi OS "Buster" wird diesen Dezember genau 2 Jahre alt. Seither habe ich FHEM regelmäßig aktualisiert, ebenso diverse Hardwarekomponenten (deConz) und alles läuft soweit prima.
Worum ich mich nicht gekümmert habe, waren Updates des Betriebssystems, damals noch mit Linux Kernel Version 4.19. Inzwischen gibt es schon Version 5.10.17 und ebenso weitere aktualisierte Bestandteile des Betriebssystems. Es wäre möglicherweise sinnvoll, diese Updates nachzuholen.

Muss ich mir mit Bezug zu FHEM irgendwelche Gedanken vor dem Update machen?
Ich würde mich sonst regulär an die raspi-docu halten ( https://www.raspberrypi.org/documentation/computers/os.html#using-apt ).
Da mir jegliche Erfahrungen im Hinblick fehlen, möchte ich deshalb Eure Einschätzung vorher einholen.

VIelen Dank vorab.

Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Adimarantis

Ich mache regelmäßig
apt update
apt upgrade
reboot

auf meinen Raspis
FHEM hat da gar kein Problem mit. Ich habe sogar schon ein update von Stretch->Buster hinter mir.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

"Eigentlich" sollte das stressfrei gehen, FHEM an sich ist in der Regel nicht das Problem, schon gleich nicht, wenn man kein Distributions-upgrade macht (buster->bullseye)....

Die Haken, über die man sich bei einem OS-upgrade Gedanken machen sollte:
- Werden "tieferliegende" Funktionen verwendet, die über das OS laufen? Insbesondere: GPIO-Zugriffe könnten eine Falle darstellen (einer der Gründe, warum ich für sowas lieber einen Arduino etc. dazwischenschalte)
- Ändert sich was an Perl (in der Regel nicht bei buster->buster usw.)?

Würde dazu tendieren, hier eher noch zu warten, bis "bullseye" dann Basis von Raspi-OS ist und vorher nochmal zu schauen, dass die Perl-Funktionen "sauber" sind, also keine "unescaped löeft brace"-Meldungen im Log zu finden sind usw..
Dann einen Neuaufsatz (ohne GUI...) auf einer neuen SD-Karte; dann hast du die alte immer noch als Notlösung, falls was schief geht. (Oder eben direkt das aktuelle OS nehmen, und dann buster (aktuell) -> bullseye umziehen...

(Oder ist die GUI wichtig? Jedenfalls deconz-GUI kann man auch per "remote X-Server" starten, wenn man das braucht).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

Also Prinzipiell "sollten" kleine Updates kein Problem machen. Da Du einen PI hast, hast Du eine Kopie der SD-Card? Vor allem bei größeren Veränderungen IMMER Sinvoll .....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Dracolein

Hi zusammen,

jau, eine Backup-SD Karte habe ich immer rumliegen, allein schon aus meinen Erfahrungen mit plötzlich gestorbenen SD-Cards.

Ich nutze den Pi ausschließlich für FHEM in Verbindung mit angeschlossenem Monitor zur grafischen Steuerung via FTUI und angeschlossenem ConBee II USB-Stick für mein Zigbee Netzwerk. Andere Aufgaben hat der Pi explizit nicht erhalten.

Kleiner Exkurs zur GUI-Entscheidung.... nunja ich sehe mich bei weitem nicht als "Kenner" von Unix, Linux & Co, der mit Kommandozeile arbeitet. Drum war es mir immer ein persönliches Bedürfnis, ein GUI-unterstütztes Betriebssystem zu haben, was an sich bei mir auch echt keine Probleme bereitet. Nachdem der Pi hochgefahren ist, startet sich die deConz Oberfläche, ich öffne den Chrome-Browser, logge mich in FHEM ein und starte FTUI im Vollbildmode, fertig.

Andere Frage:
besteht überhaupt eine zu MS Windows / macOS vergleichbare Notwendigkeit auf regelmäßige Updates des Betriebssystems? Das war mein eigentlicher Hintergrundgedanke für diese Thematik. Ich erwarte keine neuen Features damit, sondern höchstens Bugfixes oder erhöhte Stabilität bzw. ggf. gefixte kritische Sicherheitslücken. Mir fiel der Gedanke am Wochenende auf, als ich mal wieder diverse Updates meiner Netzwerk- und Serverdevices durchschob, dass einzig der Pi bisher überhaupt kein Update erhielt.
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Beta-User

Zitat von: Dracolein am 28 September 2021, 09:09:19
Kleiner Exkurs zur GUI-Entscheidung.... nunja ich sehe mich bei weitem nicht als "Kenner" von Unix, Linux & Co, der mit Kommandozeile arbeitet.
...was hindert dich daran, "das bißchen" zu lernen?

Zitat
Drum war es mir immer ein persönliches Bedürfnis, ein GUI-unterstütztes Betriebssystem zu haben, was an sich bei mir auch echt keine Probleme bereitet. Nachdem der Pi hochgefahren ist,
...sollte sich der Paket-Manager des OS eigentlich direkt melden und mitteilen, dass diverse sicherheitskritische Updates zur Verfügung stehen...

Zitat
Andere Frage:
besteht überhaupt eine zu MS Windows / macOS vergleichbare Notwendigkeit auf regelmäßige Updates des Betriebssystems?
::) s.o....

Das "Problem" ist aber grade durch die GUI nicht kleiner, sondern größer, weil eben jedes installierte Paket auch Sicherheitslücken aufweisen kann. Von weiteren Fallstricken wie "modemmanager" reden wir dabei noch gar nicht...

MAn. solltest du dringend die Serverfunktion _headless!_ von FTUI trennen - für "Bedienzwecke" (so man überhaupt solche hat) reicht eigentlich auch ein mehr oder weniger beliebiges Endgerät mit Browser, von mir aus gerne auch ein weiterer Pi, wenn's denn unbedingt sein muss...
(Oder: die Experten können ggf. sogar Anleitungen liefern, wie man nur einen Fullscreen-Browser ohne den sonstigen Ballast einer GUI startet...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

Genau so haben wir das Monitoring in meiner alten Firma erledigt. Der Browser wurde automatisch (ohne GUI) beim Booten im XServer Hochgefahren ... leider habe ich das Image nicht mehr.

(Hinweis: System + XServer + GUI sind die 3 "Ebenen" des Rechners. Mann kann also unter Unix Grafische Probramme ohne GUI starten)

Was viele Vergessen: Schon die Existens der Libs der GUI kann Seurity Probleme bereiten.

Und was in diesem Thread viel Wichtiger ist: Je mehr installiert ist, desto mehr kann beim Update Probleme machen.
Hinweis: Dazu gehört auch CPAN!
Also ein "nacktes" Serverbetriebsystem für FHEM (Ohne GUI, CPAN und Hardwareanpassungen) ist "eigentlich" Problemlos upzudaten. Auch über Versionsgrenzen hinweg. Habe es beruflich auch schon mit LAMP (Bzw. LNMP, da Nginx anstatt Apache) mehr als ein mal Problemlos durchgeführt und da machen PHP-Versionen eigentlich die Probleme.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

frank

antworten auf die thread-frage können ja nur spekulationen sein.

daher würde ich auf einer neuen sdcard mit einem funktionierenden aktuellen image das update/upgrade ausführen und selber auf probleme achten (logs anschauen).

gibt es probleme, einfach mit alter sdcard fortfahren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

topa_LE

Trotz der 120 Tage, hol ich den "Mist" noch mal hier raus ...

JA, in der Tat ist ein Update von Buster auf Bullseye der letzte Krampf, um nicht zu sagen "fast" unmöglich ohne enormes Handanlegen (mit Fachkenntnis vorausgesetzt)!

Meine Vorgeschichte: FHEM Backup gemacht, Neue SD-Card (bullseye) komplett frisch, wie es ja so schön hier empfohlen wird gemacht.
(Ein nicht so sehr empfohlendes In-Upgrade auch probiert / Buster/Full-Upgrade/Bullseye), ohne Chance auf ein sauberes Reboot inkl. System!

... und dann bin ich keiner, der sich wenig mit Linux auskennt!

... weiter zum Thema:

Mein bestehendes voll funktionsfähiges FHEM umfasst ca. 500 Defines inkl. sämtlicher Zwave Fibaro usw. / Daher sträubte ich mich (und das nun aktuell völlig zurecht), für ein Neuaufsetzen inkl. Bullseye von meiner FHEM-Plattform. (Läuft ja auch :-) )

Beides völlig unlauffähig, was das ein Full-Update betrifft (Inlake-Upgrade , also Buster/Bullseye funktioniert nicht ohne Errors).

Oh, kein Problem mit Backup/- und Restore! Bitte völlig neu ein RaspiOS frischt auf SD-Card drauf und dann völlig (schmerzfrei dein FHEM-Backup) über Restore zurück ... / DAS geht völlig naneben, weil etliche Abhängigkeiten für FHEM fehlen (.z.B. CPAN etc.)!!

Dies war mir persönlich völlig unmöglich, selbst bei Neuaufsetzung von Raspbian, ein Backup von FHEM fehlerfrei zu restoren!

Hier sollte mal langsam seitens dem Entwickler (R.K.) nachjustiert werden, da eben auch gemäß des FHEM-Entwicklungstandes (6.1) einiges nicht mehr zeitgemäß zu scheinen ist!

Für mich, (und ich bin zur ersten Stunde ein FHEM Nutzer), bedarf es jetzt langsam der Überlegung, ein zeitgemäßeres Smarthome System zu nutzen, da hier aktuell wenig der Zeit mitgegangen wird.

Ein problemloses Upgrade auf neuere Debian-Dist ist leider laienhaft unmöglich!
Wie es mit ioBroker oder OPENHab/home-Assistant bezüglich der Upgrade-Funktionalität ist, vermag ich nicht zu beurteilen.

Allerdings, war aktuell die URL bei mir mit http:IP:8083 nicht mehr aufrufbar.

Nach LOG sämtlicher Errors , wie  CPAN (Nachinstallierungen), keine Change auf Erfolg.

Letztendlich ist ein Upgrade in FHEM der völlige Kram, weil hier selbst nie dem Debian-Fortschritt nachgefolgt wird.


Grundsätzlich nutze ich seit vielen Jahren FHEM, nur habe ich aktuell "Bauchschmerzen" was die Zukunft in Bezug auf Upgrades betrifft.

Ich hatte schon damals ein Problem von Strech auf Buster zu schwenken ...

Beta-User

Zitat von: topa_LE am 01 Oktober 2022, 23:44:30
Letztendlich ist ein Upgrade in FHEM der völlige Kram, weil hier selbst nie dem Debian-Fortschritt nachgefolgt wird.
Das kann ich nicht nachvollziehen. Ein "nackiges" FHEM läuft nach meiner bisherigen Erfahrung ohne weiteres auf sehr vielen Debian-Versionen und auch auf extremst vielen Perl-Versionen...

Es wird seitens der meisten Modul-Maintainern auch darauf geachtet, externe Perl-Abhängigkeiten (v.a. von Modulen, die _nur_ über cpan zu bekommen sind!) möglichst gering zu halten.

Wenn du also Module im Einsatz hast, die was voraussetzen, das man separat über das OS (apt) nachinstallieren muss, oder nur per cpan bekommt, muss du dir das halt aufschreiben und/oder dann halt auf dem passenden Weg nachinstallieren. Gerade, wenn du ein "gebranntes Kind" bist, stellt sich mir die Frage, warum dazu keine Notizen vorhanden sind... (Otto123 hat ein paar Scripte im Angebot, mit denen man das ggf. vereinfacht nachholen könnte).
Und dann gäbe es da noch den "installer", mit dem man eine Konfiguration auf solche Abhängigkeiten untersuchen könnte und das im Vorhinein fixen.

Und dann gibt es eben sehr viele Module, die du ggf. von irgendwoher nachinstalliert haben könntest. Für deren Probleme dann die Community hier "verantwortlich" machen zu wollen, ist nicht eben fair...

Für die Schnittstelle zu cpan selbst gibt es dann auch wieder eine Vielzahl von Möglichkeiten, welche sollte man also nehmen (oder besser: "verordnen"?!?)...?

Da hier aber keiner weiß, welche KONKRETEN Probleme du hattest, kann auch keiner effektiv helfen, sorry.

Und ja, den Frust kann ich nachvollziehen, dass man sich da um plötzlich um Dinge kümmern muss, mit denen man nicht gerechnet hatte. Ich kenne andere Smarthome-Systeme nicht, aber erfahrungsgemäß ist es "überall" so, dass man irgendwann einen gewissen Aufwand damit hat, alles auf der Höhe der Zeit zu halten und sich gewisse Brüche nie vermeiden lassen. Dass ein System so langlebig ist wie FHEM, kommt mir eher wie die große Ausnahme vor.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

#10
Da kann ich nur zustimmen.

Ziehe schon seit Jahren/Jahrzehnten mit fhem von OS zu OS immer komplett neu.

Mit einem entsprechenden Backup-/Restore Konzept ist/war das noch nie ein Ding.

Wichtig ist halt zu notieren, welche Zusatzschritte für bestimmte Module (nicht nur fhem auch HW) notwendig sind...

Das bei der Erstinstallation alles zu tun, sich das nicht merken/notieren und sich dann beim Neuaufsetzen wundern/beschweren, dass diese MANUELLEN, von DIR SELBST, gemachten Schritte dann nicht "einfach so" passieren, tja...

Aber nun läuft es ja wieder?
Schritte DIESMAL wenigstens notiert!? ;)

Gruß, Joachim

P.S.: wenn bei anderen Systemen steht, dass du was aus git holen und dies und das einfügen musst, bin ich ziemlich sicher, dass das bei einer Neuinstallation (ohne sich das notiert zu haben) auch "auf die Füße fällt"...
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)

Wernieman

Der Vorteil von anderen Systemen: Es giebt ein "install-Script". Der Nachteil von anderen Systemen: es giebt ein Install-Script ....

Ein Install-Sciprt macht es einfacher es erstmal laufen zu kriegen, ABER man weiß nie, was der Ersteller so an Hacks eingebaut hat. Wenn man dann nicht das System des Entwicklers verwendet (oder seine Ideen möchte), hat man ein viel Größeres Problem als bei FHEM. Und ja, 500 Geräte wird Dir bei jedem System ein Problem beim Update erzeugen.

Kurzgefasst:
Wie oben schon von anderen Gefragt: Wo war Dein Problem? (Abgesehen davon, das Du Module mit CPAN Abhängigkeiten verwendest)

Und nur mal am Rande:
Du hast 2 Möglichkeiten ein solches System aufzubauen:
1. Ein Hersteller suchen: Du bist an den Hersteller gebunden, Cloudzwang und Teuer, dafür (mit Glück und eventuell ) Support
2. Selber machen (FHEM, OpenHub etc.): Unabhängiger, Lokaler, Kein Offizieller Support und Einarbeitungszwang

Kurzgefasst: Bei 2 bezahlt Du mit Deiner Zeit, bei 1. mit Deinem Geld.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

topa_LE

Zitat von: MadMax-FHEM am 02 Oktober 2022, 09:32:22
Aber nun läuft es ja wieder?
Schritte DIESMAL wenigstens notiert!? ;)

Ja, das alte System mit Buster ;-)

Stimme Euch beide auch zu, war auch kein Vorwurf gegen FHEM. Bin völlig zufrieden damit.
Wollte nur eben anmerken, das ein FHEM-Backup/Restore auf ein neues BullsEye OS nicht so ohne weiteres gelingt.

Notizen!  :D , Tja wann ich das noch alles wüsste, was innerhalb von 7 Jahren alles zusätzlich auf die SD-Card gebrutzelt wurden?!

Ja, Otto hatte da mal etwas ... , finde es leider nicht.

Habe es gestern nach etlichen Stunden dann aufgegeben, das parallele System mit BullsEye zu laufen zu kriegen.
Was mich eben nur wundert ist, das das WebGUI :8083 nicht mal aufrufbar ist.

Welche Tools (installer etc.) sind das denn, um mal festzustellen welche Pakete/Abhängigkeiten für Bullseye nachinstalliert werden müssen?

Wäre ja nicht schlecht, so dann eben es doch lauffähig zu bekommen. (Irgendwann muss man es ja tun)

Wie gesagt, ist jetzt kein kleines FHEM, da ist schon jede Menge drin.

topa_LE

Noch der Nachtrag zu den Fehlern:

Aktuell noch der hier:

reload: Error:Modul 99_myUtils deactivated:
Can't locate Email/MIME.pm in @INC (you may need to install the Email::MIME module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at ./FHEM/99_myUtils.pm line 70, <$fh> line 16.
BEGIN failed--compilation aborted at ./FHEM/99_myUtils.pm line 70, <$fh> line 16.



Alle anderen haben ich bereinigt durch diverse Nachinstallationen. Ob nun wegen des o.g Fehlers das WebGUI nicht geht, weiß ich nicht.

rudolfkoenig

ZitatOb nun wegen des o.g Fehlers das WebGUI nicht geht, weiß ich nicht.
Nicht wegen diesem Fehler.
DIe Ursache kann man aber mit Sicherheit im FHEM-Log sehen.
Irgendwo :)