UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Jan1]

@homoran
Nein, da das auf was ganz anderes bezogen war ;)

Ok, kurz erklärt wie ich hier rein gerutscht bin. Achtung absolutes OT!!!
Ich hatte ein paar Sonoff Geräte und war eigentlich glücklich. Dann war da was mit Tasmota und die schöne Steuerung über die App war nicht mehr, also mal fragen was man dann machen kann. Erster Anlauf war Domotiz und das war echt nix für mich, also was gibts da noch und IObroker wurde genannt. OK, Die Sonoff Dinger mit Tasmota rein und schön war. Aber hm, was sind das für viele Adapter und was machen die? Mal anklicken und wie lustig, da tauchen plötzlich Geräte auf, die ich schon lange zu Hause habe.

Ok, Spieltrieb wurde geweckt und was ist denn Blockly, ah damit lassen sich die Geräte auch noch zusammen schalten, wie geil.

Lange Rede kurzer Sinn, für das was ich es wollte ist IOBroker eigentlich overkill, aber wenn man mal rein gestolpert ist nutzt man das eben. Ich hätte mir das ohne die Sonoff nie angeschaut, ob das jetzt was kostet oder eben nicht, spielte zu dem Zeitpunkt überhaupt keine Rolle.

Einen habe ich noch, ich habe ein pro Account, obwohl ich den nicht brauche, nur weil ich das hier nicht für ganz umme haben möchte.

So, Schluss mit OT und zurück zum Thema ;)

[saeft_2003]

@jan1 sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':

@opensourcenomad
Ein paar Spezis gibts immer, wobei ein versemmelter Restor meist nicht am am Backup liegt.
Wenn das Backup vom Adapter erstellt wurde und die Größe halbwegs realistisch ist ( 4-7 MB sollten normal sein), dann kann man davon ausgehen, dass das Backup auch ein Backup ist.

Also mein backup vom backitup adapter hat 80 MB. Da ich am umsteigen bin auf bullseye habe ich das eingespielt und hat alles geklappt...

[Jan1]

@saeft_2003
Dann hast wohl uneinheitlich viele Scripte und VIS Views drin. Ein "normales" Backup ist nie so groß, weil eben nur Einstellungen gesichert werden.
Kannst aber gerne mal schreiben, was da alles drin, damit das so groß wird, da wirklich normal ist das nicht, wenn nicht die zwei genannten Punkte bei Dir zutreffen. Bei so großen Backups besteht auch die Gefahr, das der RAM nicht reicht, zumindest mal auf kleiner HW ;)

Aber selbst damit hat es geklappt und das ist das wichtigste dabei.

[saeft_2003]

@jan1

Ja alleine die skripte sind 30MB, VIS dürfte auch nochmal einen großen Teil ausmachen. Die Hardware sollte kein Problem sein. Läuft als VM mit 5GB RAM auf einem NUC10i3 😊

[Jan1]

@saeft_2003
und schon ist geklärt warum Dein Backup so groß ist und trotzdem "normal" ist ;)

[Josh]

@thomas-braun Habe jetzt auch das Upgrade auf meinem ioBroker-Master im LXC-Container und auf einem meiner RPi3-Slaves vollzogen.

Bei letzterem bin ich auch in den hier im Forum bereits mehrfach genannten DHCP-Fehler hängen geblieben.

Weil ich vorher ein Image von der SD-Karte gezogen habe, konnte ich leicht ein Rollback machen und einen neuen Versuch starten.

Wichtig ist, dass vor dem Reboot folgende Datei angepasst wird:

sudo nano /etc/systemd/system/dhcpcd.service.d/wait.conf

alt:

[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

neu:

[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w

Wie man sieht, hat sich der Pfad zum dhcp-Dienst geändert und muss angepasst werden.

Vielleicht kann man das in der obigen Anleitung ergänzen.

[Thomas Braun]

@josh

Kann ich auf meinen Systemen nicht nachstellen.

[Josh]

@thomas-braun Ja, das glaube ich, denn Du bist ja nicht in den Fehler gelaufen. Aber alle (?), die den DHCP-Fehler beklagten, würde es vermutlich weiter bringen.

EDIT:
Zweiter Slave: gleicher Fehler --- gleiche Lösung.

Vielleicht hilft's ja einem...

[Thomas Braun]

@josh

Hast du in raspi-config den Punkt auf 'warten' eingestellt?

1 System Options       Configure system settings
 S6 Network at Boot   Select wait for network connection on boot

Ich warte bei meinen Systemen nicht, deswegen gibt es bei mir auch die Datei nicht.

[Josh]

@thomas-braun Ich habe dort nichts geändert. Es sind also die Standardeinstellungen drin. Und da wird wahrhaftig auf das Netzwerk gewartet. Sehr interessant....

[ente34]

@thomas-braun
Vielen Dank für Deine Anleitung, ich habe sie leider zu spät gefunden.
Habe mich vor drei Wochen hier entlang gehangelt.
Allerdings musste ich noch buster durch bullseye in
./apt/sources.list.d/nodesource.list
./apt/sources.list.d/influxdb.list
ersetzen.
Die Dateien habe ich mit

cd /etc
sudo grep -rl buster .

gefunden.
Vielleicht tritt das noch bei anderen Installationen hier im Forum auf.

[Thomas Braun]

@ente34

sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/*

erledigt das.

[ente34]

@thomas-braun
Super, lass ich nochmal drüberlaufen.
Danke!

[buggybeast]

Hallo zusammen
ich hatte auch Probleme nach dem Upgrade, so dass der PI nicht mehr im Netzwerk zu finden war, sehr wahrscheinlich auch das DHCP Problem.
Zum Glück hatte ich ein komplettes Backup. Nach drei Versuchen hat folgendes bei mir zum Erfolg geführt.

Vor dem sudo apt full-upgrade:
sudo apt install libgcc-8-dev gcc-8-base
Nach dem full-upgrade:
sudo apt -f install (dies sollte mit 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert quittiert werden, ansonsten nochmal full-upgrade)
sudo rpi-update (ob das wirklich notwendig war, keine Ahnung, ist bei mir aber auber durchgelaufen, trotz Warnung)
Vor dem Reboot habe ich dann noch:
sudo apt autoremove und
sudo apt autoclean ausgeführt. (keine Ahnung, ob das ein Unterschied ist ;-) )

Nach dem sudo reboot war mein PI dann sauber im Netz und alles lief :-)
Vielleicht hilft es ja dem ein oder anderen noch.

[Thomas Braun]

@buggybeast sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':

sudo rpi-update

Ist böse. Nicht machen.

sudo apt -f install

Ist auch böse. Auch nicht machen.

[JoergH]

@buggybeast Das "dhcp Problem" lässt sich durch eine einfach Korrektur in einer Datei beheben. Wozu der Aufwand?

[Markus78224]

@joergh said in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':

@buggybeast Das "dhcp Problem" lässt sich durch eine einfach Korrektur in einer Datei beheben. Wozu der Aufwand?

Zumindest bei mir hatte diese Korrektur das Problem nicht gelöst. Mein Raspi läuft ohne SD Karte mit nur einer SSD. Hatte die Datei 2 mal geprüft und der Pfad war dann auch wie hier beschrieben gespeichert.
Hab dann neu installiert und das Backup zurück gespielt.

[JoergH]

@markus78224 Interessant. Was hat er denn dann noch ausgeworfen im Log?
Ich habe die gleiche Config, nur mit einem PI 4.

[Thomas Braun]

@buggybeast

Heute gab es ein Update des dhcpcd5 Pakets.
Ich gehe davon aus, das damit das Thema keins mehr ist.

[io_laurent]

Hallo @Thomas-Braun,
vielen Dank für die Anleitung, hat auf den ersten Blick alles bestens funktioniert.
Allerdings (Kurzform): meine externe Platte am Raspi ist seit dem Update extrem langsam.
Ausführlich: Ich hab auf dem Raspi auch Plex laufen, die Medien dafür sind auf einer externen Platte an USB 3 angeschlossen. Habe Dateien immer von meinem Mac per ftp auf die externe Platte des raspi kopiert. Vor dem Bullseye-Update ging das recht flott, nach dem Update habe ich einen Transferrate von ca 100kb/s (ich hoffe das stimmt, ich werfe bit und byte gerne durcheinander, aber auf alle Fälle seeeeeehhhhhr langsam).
Kann es sein, dass dies mit dem Update zusammenhängt? Ich habe nämlich sonst nix verändert.
Auch habe ich die ext. Platte testweise direkt an meinem Mac angeschlossen, da rennt sie wie eh und je.
Für Hinweise oder Hilfe zur Behebung wäre ich sehr dankbar und sei bitte nachsichtig, bin ne Linux-Pfeife der Sorte Kommandos copy&paste.
Vielen Dank!