Für alle Module von Loredo wird nun das Perl Modul "Perl::PrereqScanner::NotQuiteLite" benötigt.
Deshalb können alle diese Module bei mir im Moment nicht geladen werden.
Leider ist das nirgends in einer Ankündigung zu finden.
Ich finde es sehr traurig dass hier neue Abhängigkeiten aufgebaut wurden, ohne dass es ein neues Feature Level gibt.
Jahrelang laufende FHEM Installationen werden so durch ein Update unbrauchbar gemacht da dort neue Installationen von Modulen nicht (bzw. nur sehr aufwändig) möglich sind.
Siehe auch: https://forum.fhem.de/index.php/topic,97897.msg911669.html#msg911669 und https://forum.fhem.de/index.php/topic,97792.msg911676.html#msg911676
Gruß
Dan
Hatte das gleiche Problem und haben den Restore auf den Stand vor dem Update folgendermassen durchgeführt (Shell):
#Wechselt in das Backupverzeichnis
cd /opt/fhem/restoreDir/update/2019-02-26
#Restore von allen Dateien inklusive Unterordner
sudo cp * /opt/fhem/FHEM -r
#Zur Sicherheit den Besitzer wieder auf fhem:dialout ändern
sudo chown -R fhem:dialout /opt/fhem/FHEM
#FHEM Neustart
sudo service fhem restart
Nun aber mal bitte ruhig mit den wilden Pferden.
Das ist keinesfalls Absicht. Ich schaue es mir an.
Bitte aber mal von solchen persönlichen Angriffen abstand nehmen. Die Devise bei FHEM ist nunmal generell: wer täglich ein Update macht, der lebt am Limit. Es gibt bei FHEM keinen doppelten Boden oder eine DEV/PROD Unterscheidung. Damit lebt jeder, der täglich updated.
Du magst in manchen Punkten recht haben ABER ein persönlicher Angriff ist in diesem Thread nicht ansatzweise vorhanden!
ZitatIch finde es sehr traurig dass hier neue Abhängigkeiten aufgebaut wurden, ohne dass es ein neues Feature Level gibt.
Das ist auch deswegen traurig, weil fhem.cfg.demo damit nicht mehr funktioniert, und das soll ohne exotische Module funktionieren.
Das Problem ist, dass in Meta.pm "use Perl::PrereqScanner::NotQuiteLite;" verwendet wird, was beim Start unkonditional ausgefuehrt wird, eval hilft da nicht.
Wenn man use durch require ersetzt, dann scheint es zu funktioneren, allerdings kriegt man weiterhin fette Fehlermeldungen im FHEM-Log, wo dieses seltsame Perl-Modul vermisst wird.
Ich kann hier auch keinerlei persönlichen Angriff erkennen, noch war es als solcher gemeint.
Es war lediglich eine Aufzählung von Fakten! Wer mehr hier reininterpretiert ist selbst Schuld.
Gruß
Dan
P.S. Ich bin nur dafür verantwortlich was ich sage, nicht was Du verstehst! ;)
Ein Fix ist eingecheckt.
Verstehe ich das richtig, dass der fix morgen ab 08:00 per update verteilt wird?
Zitat von: MadMax75 am 26 Februar 2019, 11:36:55
Verstehe ich das richtig, dass der fix morgen ab 08:00 per update verteilt wird?
Ja
Zitat von: Hauswart am 26 Februar 2019, 10:22:28
Hatte das gleiche Problem und haben den Restore auf den Stand vor dem Update folgendermassen durchgeführt (Shell):
cd /opt/fhem/restoreDir/update/2019-02-26
sudo cp * /opt/fhem/FHEM -r
sudo service fhem restart
Moin,
versaust Du Dir damit nicht den Eigentümer der wieder hergestellten Dateien?
restore update/2019-02-26in der FHEM Konsole hätte doch das Gleiche gemacht?
Gruß Otto
Zitat von: Loredo am 26 Februar 2019, 11:27:27
Ein Fix ist eingecheckt.
Habe soeben die Moduldatei (Meta.pm) aus SVN gezogen, das scheint die Probleme zu beheben.
Danke für den schnellen Fix.
Gruß
Dan
Zitat von: Otto123 am 26 Februar 2019, 11:49:22
Moin,
versaust Du Dir damit nicht den Eigentümer der wieder hergestellten Dateien? restore update/2019-02-26in der FHEM Konsole hätte doch das Gleiche gemacht?
Gruß Otto
Da ich FHEM nicht mehr starten konnte, wählte ich diesen Weg. War für mich auf die schnelle der einfachste Weg, der Eigentümer ist nun geändert, aber scheint bei mir weiterhin zu funktionieren.
Ich ergänze aber zur Sicherheit noch:
sudo chown -R fhem:dialout /opt/fhem/FHEM[/code]
Da das ein ziemlich zentrales Thema zu sein scheint: mind. die Meta.pm ausnahmsweise direkt vom svn in update übernehmen?
Sonst werden es vermutlich heute abend wieder 5-10 Threads sein, die das irgendwie zum Thema haben...
Zitat von: Hauswart am 26 Februar 2019, 12:10:52
Da ich FHEM nicht mehr starten konnte, ...
Ach so, dass es so schlimm war hatte ich nicht raus gelesen. ::)
Zitat von: DeeSPe am 26 Februar 2019, 11:50:24
Habe soeben die Moduldatei (Meta.pm) aus SVN gezogen, das scheint die Probleme zu beheben.
Danke für den schnellen Fix.
Gruß
Dan
Kann ich bestätigen.
Wer nicht das Backup einspielen möchte, kann auch folgendes tun:
cd /opt/fhem/FHEM
#Vorabversion von Meta.pm beziehen
wget https://svn.fhem.de/trac/export/18742/trunk/fhem/FHEM/Meta.pm
#Zur Sicherheit den Besitzer auf fhem:dialout ändern
sudo chown -R fhem:dialout /opt/fhem/FHEM/Meta.pm
#FHEM Neustart
sudo service fhem restart
Zitat von: Otto123 am 26 Februar 2019, 12:18:22
Ach so, dass es so schlimm war hatte ich nicht raus gelesen. ::)
Hallo Otto, kein Thema :) Ja FHEM lasst sich aktuell mit dem Update nicht mehr starten. Gruss
Hallo,
ich bekomme leider weiterhin:
2019.02.26 16:55:02 0: Undefined subroutine &FHEM::Meta::Load called at ./FHEM/20_ROOMMATE.pm line 34.
2019.02.26 16:55:02 1: PERL WARNING: Subroutine ROOMMATE_Initialize redefined at ./FHEM/20_ROOMMATE.pm line 13.
2019.02.26 16:55:02 0: Undefined subroutine &FHEM::Meta::Load called at ./FHEM/20_ROOMMATE.pm line 34.
2019.02.26 16:55:02 0: Undefined subroutine &FHEM::Meta::Load called at ./FHEM/20_GUEST.pm line 34.
Obwohl ich die Version aus dem SVN geladen habe.
Kann hier jemand helfen?
Danke vorab
Hast Du das Modul korrekt installiert und dann neu gestartet?
Zitat von: Hauswart am 26 Februar 2019, 12:20:32
Kann ich bestätigen.
Wer nicht das Backup einspielen möchte, kann auch folgendes tun:
cd /opt/fhem/FHEM
#Vorabversion von Meta.pm beziehen
wget https://svn.fhem.de/trac/export/18742/trunk/fhem/FHEM/Meta.pm
#Zur Sicherheit den Besitzer auf fhem:dialout ändern
sudo chown -R fhem:dialout /opt/fhem/FHEM/Meta.pm
#FHEM Neustart
sudo service fhem restart
Ich habe exakt das hier gemacht.
Reicht das nicht aus?
nach einem
restore update/2019-02-26
startet jetzt gar nichts mehr..
Starting fhem...
2019.02.26 17:25:15 1: PERL WARNING: Prototype mismatch: sub main::GetDefAndAttr ($) vs ($;$) at configDB.pm line 164.
2019.02.26 17:25:15 1: Too many arguments for main::GetDefAndAttr at configDB.pm line 469, near "1)"
Compilation failed in require at (eval 11) line 2.
BEGIN failed--compilation aborted at (eval 11) line 2.
Undefined subroutine &main::_cfgDB_Connect called at configDB.pm line 292.
Hallo zusammen,
nur am Rande: Ich habe mich per WinSCP auf den RPi eingeloggt, fhem.cfg und Meta.pm gelöscht. Danach die fhem.cfg aus /restoreDir/update/2019-02-26 und die Meta.pm aus /restoreDir/update/2019-02-26/FHEM wieder an die ursprünglichen Stellen Dupliziert.
Die fhem.cfg nur, da ich in geistiger Umnachtung ein paar Devices "weggespeichert" hatte...
Das ist doch eigentlich der schnellste und unkomplizierteste Weg --> gerade auch, wenn FHEM nicht mehr startet oder nicht? (Da hierbei ja auch Besitzer / Rechte erhalten bleiben).
Viele Grüße
Sascha
Ich habe leider in meinem backup (weder dem FHEM-eigenen Backup, noch in gesondertem Backup) keine Meta.pm
EDIT:
Restore aus altem Backup. Update werde ich dann wohl für die nächste Zeit nicht mehr ausführen..
Zitat von: MarcoEig am 26 Februar 2019, 17:23:47
nach einem
restore update/2019-02-26
startet jetzt gar nichts mehr..
Starting fhem...
2019.02.26 17:25:15 1: PERL WARNING: Prototype mismatch: sub main::GetDefAndAttr ($) vs ($;$) at configDB.pm line 164.
2019.02.26 17:25:15 1: Too many arguments for main::GetDefAndAttr at configDB.pm line 469, near "1)"
Compilation failed in require at (eval 11) line 2.
BEGIN failed--compilation aborted at (eval 11) line 2.
Undefined subroutine &main::_cfgDB_Connect called at configDB.pm line 292.
Du hast zuvor Fhem heute geupdatet? Und dann erst die Workarounds ausprobiert?
Nach dem Restpreis hättest du nochmal Meta aus dem SVN herunterladen sollen.
Ab morgen sollte das Update wieder gehen.
Hallo,
Nachdem ich gestern mit dem update mein System "zerschossen" haben, habe ich soeben wieder ein update ausgeführt.
Residents ist nun weg, kann jedoch angelegt werden.
Wunderground eigentlich das gleiche.
Gibt es eine Möglichekeit die Daten wieder herzustellen oder muss ich Residents und Wunderground wieder neu anlegen?
Bin am übelegen das backup von vo 5 Tagen einzuspielen.
Danke für die Hinweise!
Markus
Schau mal in dein restoreDir Verzeichnis.
Und bitte mit den Grundlagen beschäftigen. Solche Dinge muss man wissen, BEVOR was schief geht.
Zitat von: MadMax75 am 27 Februar 2019, 11:13:33
Hallo,
Nachdem ich gestern mit dem update mein System "zerschossen" haben, habe ich soeben wieder ein update ausgeführt.
Residents ist nun weg, kann jedoch angelegt werden.
Wunderground eigentlich das gleiche.
Gibt es eine Möglichekeit die Daten wieder herzustellen oder muss ich Residents und Wunderground wieder neu anlegen?
Bin am übelegen das backup von vo 5 Tagen einzuspielen.
Danke für die Hinweise!
Markus
Falls Du save gemacht hattest, dann hol doch jetzt mit restore (https://commandref.fhem.de/#restore)einfach deine alte cfg wieder. Zumindest verstehe ich so dein "zerschossen" das fehlerhafte update hat ja nicht wirklich was zerschossen.
Angeregt durch Hauswart seine Scriptzeilen kam mir noch folgende Idee.
Rettungsanker falls FHEM nicht mehr startet:
sudo su # man braucht erhöhte Rechte
n=3 # einfach eine Zahl
cd /opt/fhem # wechseln ins fhem Verzeichnis
# leere fhem.cfg vom SVN holen
sudo wget -q -O fhem$n.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
# Original statefile behalten
sed -i "s/\/fhem.save/\/fhem$n.save/" fhem$n.cfg
perl fhem.pl fhem$n.cfg
Danach hat man ein FHEM mit leerer config, kann aber auf das originale Logfile zugreifen und hat mit restore einfachen Zugriff auf die gesicherten Verzeichnisse.
Am Ende ein shutdown in der FHEM Kommandozeile und weg ist die temporäre FHEM Version wieder.
Könnte man das so ganz allgemein empfehlen oder sehe ich eine Tretmine nicht?
Normalerweise geht sowas auch mit der fhem.cfg.demo - aber genau die ging ja in diesem Fall auch nicht.
Gruß Otto
Hab das Thema auf gelöst gesetzt da es mit dem heutigen Update keine Probleme mehr zu geben scheint.
Gruß
Dan
Zitat von: Loredo am 26 Februar 2019, 10:26:07
Nun aber mal bitte ruhig mit den wilden Pferden.
Das ist keinesfalls Absicht. Ich schaue es mir an.
Bitte aber mal von solchen persönlichen Angriffen abstand nehmen. Die Devise bei FHEM ist nunmal generell: wer täglich ein Update macht, der lebt am Limit. Es gibt bei FHEM keinen doppelten Boden oder eine DEV/PROD Unterscheidung. Damit lebt jeder, der täglich updated.
Tägliches update? Ich hab seit einem Jahr keins mehr gemacht. Wenn sowas dabei rauskommt mach ich nie mehr eins ;-)
Zitat von: martindlg am 27 Februar 2019, 15:59:13
Tägliches update? Ich hab seit einem Jahr keins mehr gemacht. Wenn sowas dabei rauskommt mach ich nie mehr eins ;-)
Erstens hat er gerade nicht dafür plädiert, dauernd ein update zu machen, und zweitens kannst du das halten wie du willst.
Ich gebe nur zu bedenken: Manchmal ändert sich halt auch außerhalb von FHEM was, z.B. das weather. Wenn das passiert, ändert sich das Wetter bei deinem FHEM dann halt nicht mehr...
Will heißen: FHEM ist eine Daueraufgabe (wie jedes HA-System), und je mehr Abhängigkeiten man von "extern" hat, desto eher geht "never touch a running system" halt nicht :P .
Daher: immer mal wieder updates einspielen, dabei -vorher_ schauen, ob es "Aufreger" oder "Neuigkeiten" gab, dann ist es in der Regel kein Problem.
Oder eben damit leben, dass irgendwann der Zeitpunkt ist, um über eine große Renovierung nachzudenken. Das ist dann ggf. richtig aufwändig. Ganz wie im richtigen Leben eben.
Just my2ct.
Zitat von: Beta-User am 27 Februar 2019, 16:06:38Daher: immer mal wieder updates einspielen, dabei -vorher_ schauen, ob es "Aufreger" oder "Neuigkeiten" gab, dann ist es in der Regel kein Problem.
Ich mach relativ häufig updates und bin auch recht gut mit recovery vertraut aber das "vorher" schauen klappt nur bedingt wenn man ne Menge Module im Einsatz hat. Gerade wenn man Abhängigkeiten ändert, kündigt man sowas besser vorher an, sodass man überhaupt ne chance hat bevor es kracht. Oder packt das auch in die CHANGED doku - wo auch der Fix wieder nicht erwähnt ist.
Insofern: Wichtiger wäre eher, dass sich die User mit dem Recovery Modus vertraut machen - das Ankündigen klappt eh nicht.