Bullseye

[Otto123]

Vermutlich verstehe ich da etwas falsch, ich komme gedanklich da eher auf Tage bis Wochen: Ein RPi4 mit neuem bullseye bestücken und dann FHEM völlig neu aufsetzen? Oder die bisherige FHEM-Installation dann übertragen? Wie meinst Du es konkret?

Guten Morgen,

ich meinte erstmal nur eine frische Basis Installation zum Testen. Du warst Dir ja offenbar unsicher mit den angefragten Dateien, die hättest Du damit doch schnell gehabt. Das Längste an der Installation ist apt full-upgrade - das bräuchte man aber nicht machen, wenn man nur Zugriff auf die originalen Dateien config.txt und cmdline.txt in einem funktionierenden System haben will. Damit der HMUART funktioniert ändere ich nur die Datei config.txt (serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen) und deaktiviere den serial-getty@ttyAMA0.service. Beim Raspi4 darf die Temperaturkontrolle des Lüfters nicht aktiv sein!
Zu Deinen beiden zusätzlichen Einträgen in der config.txt kann ich nicht sagen, die habe ich bisher nicht gebraucht.

Ich habe zum "Update des Systems" durch Neuinstallation und Backup/Restore von FHEM schon oft geschrieben (Einstieg), das ist mMn der besser Weg. Dieser Vorgang dauert irgendwas von maximal ein paar Stunden - auf alle Fälle viel weniger als anschließendes Troubleshooting.

[Beta-User]

Weiterer Effekt, möglicherweise Seiteneffekt: FHEM stürzt nun oft ab, geschätzt 10x in 24h. (FHEM wird bei mir über systemd gestartet, wie im Wiki vorgeschlagen. Auch da hakt es: Bei Systemstart kommt FHEM nicht immer hoch.)

Nun ist die ernsthafte Frage: Wo fange ich eigentlich an?

Wenn FHEM abschmiert, liegt es entweder daran, dass systemd der Ansicht ist, es müßte FHEM neu starten (=> keine Log-Einträge), oder es wird irgendeine Funktion aufgerufen, die es nicht gibt (undefined subroutine-Einträge im Log), oder es wird sonst was gemacht, was (so) nicht geht ("unescaped left brace"? => log).

Hatten wir jetzt scheinbar ein paar Mal, wobei bei den bisherigen Fällen meistens eine Unzahl von Log-Einträgen da war, um die man sich auch schon zu buster-Zeiten hätte kümmern können (eigentlich: sollen).

An sich ist bullseye - abgesehen von der Perl-Version) auch nicht anders als buster, insbesondere systemd war auch dort der default.

Klingt für mich nach Hängern wegen nicht erreichbaren Diensten im Netzwerk (uU. wirklich ein Seiteneffekt von den crypt-Abhängigkeiten, was dann dem/den Maintainer(n) zu melden wäre, damit die das fixen.

[curt]

Wenn FHEM abschmiert, liegt es entweder daran, dass systemd der Ansicht ist, es müßte FHEM neu starten (=> keine Log-Einträge),

Kann ich das etwas hinauszögern?
Du erwähnst im Wiki-Eintrag eine Verzögerung. Aber greift die im vorliegenden Fall? Oder macht der einfach nur eine Pause während des Neustarts?

oder es wird irgendeine Funktion aufgerufen, die es nicht gibt (undefined subroutine-Einträge im Log), oder es wird sonst was gemacht, was (so) nicht geht ("unescaped left brace"? => log).
Hatten wir jetzt scheinbar ein paar Mal, wobei bei den bisherigen Fällen meistens eine Unzahl von Log-Einträgen da war, um die man sich auch schon zu buster-Zeiten hätte kümmern können (eigentlich: sollen).

Keine derartigen Fehlermeldungen. Keine Massen an Logeinträgen. Lediglich nicht erreichbare Devices (waren schon vorher nicht erreichbar) und halt die Wetterstation (via Wlan). Den Staubsauger muss ich erstmal verbose 5 setzen, daher kann ich dazu im Moment nichts sagen.

An sich ist bullseye - abgesehen von der Perl-Version) auch nicht anders als buster, insbesondere systemd war auch dort der default.

Das letzte dist-upgrade *auf* buster sorgte dafür, dass das bei mir nicht so ist (war); ich habe das vor Wochen händisch eingepflegt.

Klingt für mich nach Hängern wegen nicht erreichbaren Diensten im Netzwerk (uU. wirklich ein Seiteneffekt von den crypt-Abhängigkeiten, was dann dem/den Maintainer(n) zu melden wäre, damit die das fixen.

Mal schauen ob ich Ottos Weg anteste; da wäre das dann wohl konkretisierbar.
Danke für Deine Nachricht.

[Otto123]

Du kannst die Zeiten im unitfile anpassen - start verzögern, restart verzögern
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)

Aber mir ist nicht klar wo es bei dir wirklich klemmt. Wenn dein altes System auf gleicher Hardware unter Buster läuft, muss es auch unter bullseye laufen.
Es gab mMn noch keinen Fall wo auftretende Effekte wirklich etwas mit Bullseye zu tun hatten.

[curt]

ich meinte erstmal nur eine frische Basis Installation zum Testen. Du warst Dir ja offenbar unsicher mit den angefragten Dateien, die hättest Du damit doch schnell gehabt.

Das hätte nicht gereicht. Denn als blanke Installation ohne FHEM wäre nicht sicher, ob die Eintragungen hmUART freigeben. Mal abgesehen davon, dass bei mir die RPI4 auch nicht am Baum wachsen; es gibt ganz offensichtlich Unterschiede zwischen 3/3+ und 4; es gibt international so einige Beiträge dazu.

Hinzu kommt, dass das System eigentlich ja laufen soll, mit möglichst wenig Unterbrechungen: Einerseits rein statistische Datenerfassung, andererseits nervt schon die Teuerste: Draußen seien doch nicht nur 18°C...

Damit der HMUART funktioniert ändere ich nur die Datei config.txt (serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen) und deaktiviere den serial-getty@ttyAMA0.service.

Und genau das reichte nicht, da bin ich mir sicher. Denn diese Konstellation hatte ich; er gab aber hmUART nicht frei. also nach dem dist-upgrade auf bullseye. Erst mit den von mir veröffentlichten Änderungen wollte er wieder - wie gesagt RPi4.

Ich habe zum "Update des Systems" durch Neuinstallation und Backup/Restore von FHEM schon oft geschrieben (Einstieg), das ist mMn der besser Weg. Dieser Vorgang dauert irgendwas von maximal ein paar Stunden - auf alle Fälle viel weniger als anschließendes Troubleshooting.

Den Weg würde ich ggf. gehen wollen, ich sehe aber ein Problem - verstehe mich bitte wirklich nicht falsch: Deine Abhandlung erschließt sich mir nicht völlig. Ist auch logisch: Du hast mit Deinem fachlichen Stand geschrieben, setzt ab und an etwas voraus. Ich darf fragen: Wäre es möglich, dass wir (ggf. in einem anderen Thread) Deine Anleitung mal theoretisch durchgehen, ich also Fragen zu einzelnen Schritten stellen darf?

Danke für Deine Hilfsbereitschaft.

[curt]

Aber mir ist nicht klar wo es bei dir wirklich klemmt. Wenn dein altes System auf gleicher Hardware unter Buster läuft, muss es auch unter bullseye laufen.

Ich gehe davon aus, dass es dieses eine crypt-Modul von Perl [Name nicht momentan] ist, was fehlt. Ich habe noch nicht genau mit buster verglichen, ich vermute, dass es das für bullseye nicht mehr gibt. Das würde bedeuten, dass die Fehlermeldung des Xiaomi-Saugers (scheint ja bei anderen Saugern ähnlich, siehe S.2 des Threads) schlicht falsch ist. - Es könnte reichen, das fragliche Modul via Cpan reinzukloppen; das möchte ich aber möglichst vermeiden: Aus meiner Sicht würde man sich langfristig so richtig probleme reinholen.

Ja, Du hast aus meiner Sicht völlig recht: Das kann eigentlich nicht allzuviel sein. Das ist doch kein Hexenwerk.

[Otto123]

Der Test ob der hmuart läuft ist eine Definition in einem frischen fhem.
Ich habe schon 2 Mal einen Pi 4 mit hmuart für Freunde in Aktion gesetzt . Das Ergebnis steht so im Wiki, mehr war da nicht.
Aber egal das hast Du ja gelöst.

Du brauchst auch keinen zweiten oder dritten Pi, einfach einen USB Stick und von dem booten - geht entspannt. Ein funktionierendes neues System hast Du ja derzeit nicht , also betreibe das erste und nimm dir Zeit die Umstellung vorzubereiten.
Klar kannst Du gerne zum Backup und Restore fragen, ich werde den Thread schon finden 

Wegen dem crypt Modul schau ich morgen mal.

[curt]

Danke erstmal @Otto123.
Wenn ich (vmtl.) morgen die alte SD-Card einsetze, werde auch ich genauer nach dem fraglichen Crypt-Modul schauen. Vorher will ich aber von der neuen (also dist-upgrade)-Installation einiges dokumentieren.

Anm: Ganz so einfach ist die Sache mit dem Booten bei mir nicht: Das gute Stück ist so verbaut, dass alle Antennen optimal liegen ... im Ergebnis ich vermittels Leiter Kunststücke vollführen muss ...

[curt]

Ich komme gerade von der Leiter ... buster läuft erstmal wieder. Inzwischen kann ich Unterschiede nennen - unabhängig davon, ob die relevant sein könnten:

Code: [Auswählen]

dpkg --get-selections "*" > dateiname.txt
grep perl dateiname.txt > perl-dinge.txt

Dann

Code: [Auswählen]

diff buster-perl.txt bullseye-perl.txt |grep "<"

< libcompress-raw-bzip2-perl install
< libcompress-raw-lzma-perl install
< libcompress-raw-zlib-perl install
< libfcgi-perl install
< libperl5.28:armhf install
< libxml-parser-perl install
< perl-modules-5.24 install
< perl-modules-5.28 install

Alle existieren nun als *:armhf in bullseye. libperl und perl-modules als 5.32.

Anm: Ich kann nicht mit völliger Sicherheit sagen, ob ich irgendwann vom Pfad der Tugend abkam und doch mal via cpan etwas einspielte ...

Nachtrag: Doch, mit Hilfe von https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html kann ich das:

Code: [Auswählen]

# for M in `perldoc -t perllocal|grep Module |sed -e 's/^.*" //'`; do V=`perldoc -t perllocal|awk "/$M/{y=1;next}y" |grep VERSION |head -n 1`; printf "%30s %s\n" "$M" "$V"; done |sort
                    Crypt::ECB     *   "VERSION: 2.22"
                        CryptX     *   "VERSION: 0.069"
              ExtUtils::Config     *   "VERSION: 0.008"
             ExtUtils::Helpers     *   "VERSION: 0.026"
        ExtUtils::InstallPaths     *   "VERSION: 0.012"


Da grinsen mich also zwei Crypt-Module an - von denen ich allerdings nicht sagen kann, ob irgend ein FHEM-Modul darauf zurückgreift.

[MadMax-FHEM]

Also nun muss ich doch mal

Mein fhem läuft mit dem Xiaomi-Modul und Sauger auf Bullseye und davor auf Buster und davor auf Stretch usw.

Allerdings steige ich IMMER "frisch" um.
Von Dist-Upgrade halte ich nichts.
Irgendwas klappt nicht (und man merkt es vielleicht nicht mal [sofort]) und dann kommen irgendwelche Fehler/Dinge und man weiß nicht woher und wo suchen...

Und ab und an werden auch Grundlegende Dinge gändert, z.B. initd -> systemd

Gut sowas gab es von Buster -> Bullseye wohl nicht, trotzdem.

Und ich mag CPAN auch nicht aber für das Xiaomi Modul komme ich an folgendem (immer noch nicht) vorbei:

Code: [Auswählen]

sudo cpan install Crypt::Cipher::AES

Alle anderen Libs bzgl. Xiaomi gehen mittlerweile per apt.
EDIT: z.B. sudo apt install libcrypt-cbc-perl

Bzgl. der rijndael habe ich folgendes bei mir notiert:

Code: [Auswählen]

sudo apt install libcrypt-rijndael-perl (u.a. Homematic AES)

Die Lib heißt zwar ähnlich dem was beim Xiaomi-Modul angegeben ist, reicht aber nicht...

Und wenn ein Umzug auf ein neues System so ein Akt ist, dann stimmt am Backup-/Restore-Konzept etwas nicht (meine Meinung).

Bei mir ist es egal, ob ich auf dasselbe OS und dieselbe HW restore oder komplett neu Aufsetze auf neuer HW und/oder neuem OS(-Version).

Habe ich schon viele Male gemacht aber immer neu/frisch.

Vielleicht hilft das mit CPAN (ja mag ich auch nicht) schon mal bzgl. des Xiaomi-Moduls...

EDIT: ich habe zwar (auf diesem PI) kein HMOD-PCB-Aufsteckmodul aber ein EnOcean-PI-Aufsteckmodul, also selbes "Schnittstellen-Problem" und auch das läuft problemlos. (aber neu aufgesetzt und die Schritte meiner Backup-/Restore-Notizen abgearbeitet).

Gruß, Joachim

[Otto123]

Anm: Ganz so einfach ist die Sache mit dem Booten bei mir nicht: Das gute Stück ist so verbaut, dass alle Antennen optimal liegen ... im Ergebnis ich vermittels Leiter Kunststücke vollführen muss ...

Da habe ich mal was vorbereitet
https://heinz-otto.blogspot.com/2021/02/bootstick-fur-den-raspberrypi.html

Und meine Notizen decken sich mit Joachim seinen

72_XiaomiDevice cpan:   JSON Digest::MD5 Crypt::CBC Crypt::ECB Crypt::Cipher::AES oder Crypt::Rijndael_PP debian paket   libjson-perl libdigest-md5-perl libcrypt-cbc-perl libcrypt-ecb-perl   Anmerkung die rote gibt es nur über CPAN                                                                  

[curt]

Und wenn ein Umzug auf ein neues System so ein Akt ist, dann stimmt am Backup-/Restore-Konzept etwas nicht (meine Meinung).

Da ich bislang dist-upgrade nutzte, kann ich diesen Satz nicht auflösen. Wie muss es denn sein, damit es stimmt?

Neues System aufsetzen, möglichst alle Bibliotheken und Module installieren, dann FHEM installieren. Abschließend /opt/fhem auf die neue Installation kopieren ... oder noch anders?

[MadMax-FHEM]

Da ich bislang dist-upgrade nutzte, kann ich diesen Satz nicht auflösen. Wie muss es denn sein, damit es stimmt?

Neues System aufsetzen, möglichst alle Bibliotheken und Module installieren, dann FHEM installieren. Abschließend /opt/fhem auf die neue Installation kopieren ... oder noch anders?

Naja das eine ist Distupgrade nutzen, hat ja nichts mit Backup/Restore zu tun.

Was wäre denn, wenn dir dein System kaputt geht/gegangen wäre?
Wie kommst du dann wieder auf die Beine?

Ja, deine Schritte so in etwa:

Neue Plattform aufsetzen (ich habe dazu einen PI rumfliegen/ist aber kein Muss, verkürzt nur die Stillstandszeit).
Dann alle Pakete installieren (nehme ich aus meinen Notizen, Otto hat da wohl auch ein Script für   ).
Vorbereitungen durchführen, z.B. HMUART-Zeugs etc.
fhem installieren.

Dann beim alten System fhem-Backup (Anmerkung: /opt/fhem/.ssh wird NICHT mitgesichert, falls also Verbindungen OHNE PW-Eingabe oder alexa-fhem/gassistant etc. verwendet wird auch den Ordner sichern! Wichtig: Rechte usw. beachten, da ist ssh etwas "empfindlich": tar bietet sich an).

Dann den alten Rechner runterfahren, neue Plattform starten und fhem-Backup einspielen und starten.

Dann eben im Logfile schauen, ob doch irgendwas (meist ein Perl Paket) vergessen wurde und wenn nicht: fertig...
...wenn doch: schauen was fehlt und installieren...

Mit der Methode ist es (mir) ziemlich egal von wo nach wo ich umziehe...
EDIT: oder ob mein System crasht...

Und benötigt max. 30min Downtime (wenn überhaupt).
EDIT: für einen geplanten Umzug. Crash ist nat. eine andere Story, da hat das Aufsetzen auf einem anderen PI keinen Vorteil, weil das System ja schon steht...

Gruß, Joachim

[curt]

Ich atme im Moment durch, studiere Ottos Seiten und atme nochmals durch.
Zwischendurch (fast OT) will ich antworten:

Naja das eine ist Distupgrade nutzen, hat ja nichts mit Backup/Restore zu tun.

Was erstmalig schief ging. Seit Etch mache ich Debian-dist-upgrades verschiedener Systeme, nun ging es erstmals so richtig schief. Da ich nun weiß, wie ich cpan-Pakete wiederfinde, wäre sogar eine Option, diese im bullseye-System einzuspielen und zu schauen, was passiert. Tatsächlich aber hat bei mehreren Systemen das dist-upgrade auf bullseye (Rasperry Pi OS) Ärger gemacht, das fängt schon damit an, dass die mir IPv6 mit Gewalt reindrücken wollen. Zudem ändern die beim upgrade die Netz-Device-Namen, sodass bei statischen IP (/etc/dhcpcd.conf) der Griff ins Leere geht und das System sich ganz wilde IPs ausdenkt. Und falls /etc/network/interfaces existiert, wird das gleich ganz ignoriert, aber das nur am Rande.

Was wäre denn, wenn dir dein System kaputt geht/gegangen wäre?
Wie kommst du dann wieder auf die Beine?

Ich sichere auch im normalen Leben die SD-Card. System runterfahren, SD-Card in Card-Reader, dd if= usw. - Für ein Dist-Upgrade nehme ich eine neue SD-Card, das bisherige System (dd if=) da drauf und los geht es.

Ja, deine Schritte so in etwa:

Die größte Sorge macht mir mein Saugroboter (Xiaomi), da wurschtelt aus irgendwelchen Gründen ein python-Script unterhalb von fhem rum. Ich weiß weder ob man das für den normalen Betrieb überhaupt braucht (erinnerlich ging es um die Initialisierung des Roboters beim Hersteller in China) noch weiß ich, ob das im neuen System wieder hoch kommt. Und ich weiß auch nicht so recht, wen ich da fragen könnte: Meine Vermittlungsversuche im Forum reichten ja nicht einmal dazu, dass der neue Code eines anderen Programmierers in 72_Xiaomi aufgenommen wurden ...

Wenn ich den Mut gefasst habe, werde ich vom Fortgang der Dinge berichten.

[MadMax-FHEM]

Du nutzt doch das Xiaomi-Modul für den Sauger?
Das python Script vermutlich um mal den Token zu bekommen...

Den hast du ja jetzt, solange du den nicht zurück setzt und nicht nur die fhem.cfg kopierst, sondern ein fhem Backup zurück spielst ist das kein Problem.
EDIT: wobei in dem Fall verm. sogar die fhem.cfg reicht...

Habe ich schon etliche Male gemacht (ich ziehe ja schon immer so um wie geschrieben).
(gut, ich habe den Vorteil, dass ich mit "gerootetem" Sauger leichter an den Token komme, falls nötig)

Wenn du schon so lange mittels dist-upgrade hochrüstest, war es, bei den ganzen Änderungen die es gab (ich sprach initd ja schon an ) und du hast weitere genannt, ja eigentlich nur die Frage wann es schief geht.
Hätte auch schon früher sein können...

Aber Backup mit dd (wenigstens offline ) hat ja dann immer Stillstandszeiten und du musst dran denken und es machen...

UND: wenn die SD kaputt ist/geht, kann es sein, dass du bereits Fehler (die halt noch nicht aufgefallen sind) mitsicherst...

Ein fhem Backup kann automatisiert laufen und wenn das dann noch auf einem anderen System (NAS o.ä.) landet, dann ist es sicher und es gibt keine Unterbrechung wg. Backuperstellung....

Ups, sorry, ebenfalls OT und schon ruhig...

Gruß, Joachim