NEWS
Upgrade von Debian 10 'Buster' auf 11 'Bullseye'
-
@thomas-braun said in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
which nodejs node npm && nodejs -v && node -v && npm -v && sudo apt update && sudo apt update && apt policy nodejs
pi@raspberrypi-iob:~ $ which nodejs node npm && nodejs -v && node -v && npm -v && sudo apt update && sudo apt update && apt policy nodejs /usr/bin/nodejs /usr/bin/node /usr/bin/npm v14.18.1 v14.18.1 6.14.15 Holen:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease [15,0 kB] OK:2 https://deb.nodesource.com/node_14.x bullseye InRelease OK:3 http://archive.raspberrypi.org/debian bullseye InRelease Es wurden 15,0 kB in 1 s geholt (13,2 kB/s). Paketlisten werden gelesen… Fertig Abhängigkeitsbaum wird aufgebaut… Fertig Statusinformationen werden eingelesen… Fertig Alle Pakete sind aktuell. OK:1 http://archive.raspberrypi.org/debian bullseye InRelease OK:2 http://raspbian.raspberrypi.org/raspbian bullseye InRelease OK:3 https://deb.nodesource.com/node_14.x bullseye InRelease Paketlisten werden gelesen… Fertig Abhängigkeitsbaum wird aufgebaut… Fertig Statusinformationen werden eingelesen… Fertig Alle Pakete sind aktuell. nodejs: Installiert: 14.18.1-deb-1nodesource1 Installationskandidat: 14.18.1-deb-1nodesource1 Versionstabelle: *** 14.18.1-deb-1nodesource1 500 500 https://deb.nodesource.com/node_14.x bullseye/main armhf Packages 100 /var/lib/dpkg/status 12.22.5~dfsg-2~11u1 500 500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packagespasst so oder?
Ja passt.
Das Video hab ich mir gerade auch mal angeschaut, zumindest wird da mal was vernünftiges erzählt. Eigentlich wird ja auch nur der Forumseintrag vorgelesen... Naja, wer's braucht. Ich lese es lieber selber nach, dann hab ich auch den letzten Stand, der Forumseintrag wurde nämlich unlängst auch leicht angepasst und stimmt nicht mehr mit dem Video überein.
-
@smizi
Das ist ein Video und Lesen ist klar zu bevorzugen ;)Das sieht gut aus und desahlb auch die Frage, was Du da jetzt noch machen wolltest?
-
Ja passt.
Das Video hab ich mir gerade auch mal angeschaut, zumindest wird da mal was vernünftiges erzählt. Eigentlich wird ja auch nur der Forumseintrag vorgelesen... Naja, wer's braucht. Ich lese es lieber selber nach, dann hab ich auch den letzten Stand, der Forumseintrag wurde nämlich unlängst auch leicht angepasst und stimmt nicht mehr mit dem Video überein.
@thomas-braun OK, alles gut.
Eigentlich ist der Mathias auch echt ne gute Hilfe (ich bin leider weniger der Lese-Typ) und daher ist er für mich schon ne Bank!Anyway, nochmals vielen herzlichen Dank für all eure Zeit und Geduld!, gerne wieder und ich muss mich jetzt dann nochmal der Frau widmen :flushed:
Tschüssikowski und bis bald
Markus -
@jan1 ja nix, bin nur noch happy, dass der ioBroker wieder läuft...hat mich ja jetzt schon ein paar graue Härchen und den ganzen Sonntagnachmittag gekostet, aber sei es drum...hoffe, dass ich jetzt erstmal futureproofed bin :blush:
@smizi
Da muss ich Dich leider etwas einbremsen.
Keine Panik, habe nur oben mal gelesen, dass Du keine weitere SD zur Hand hast und das jetzt alles auf der alten runter genudelt hast. Die wird dadurch eben auch nicht besser und deshalb als letzten Rat, kauf ne 64GB Karte, mach ein Image von der jetzigen und mach mit der neuen weiter, dann sollte wirklich Ruhe sein und wenn was anbrennt, hast immer noch die alte SD als Backup zur Hand. -
@smizi
Da muss ich Dich leider etwas einbremsen.
Keine Panik, habe nur oben mal gelesen, dass Du keine weitere SD zur Hand hast und das jetzt alles auf der alten runter genudelt hast. Die wird dadurch eben auch nicht besser und deshalb als letzten Rat, kauf ne 64GB Karte, mach ein Image von der jetzigen und mach mit der neuen weiter, dann sollte wirklich Ruhe sein und wenn was anbrennt, hast immer noch die alte SD als Backup zur Hand.@jan1 sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
kauf ne 64GB Karte
mindestens im Doppelpack
und Markenware! -
@jan1 sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
kauf ne 64GB Karte
mindestens im Doppelpack
und Markenware! -
@homoran
OK, dann sind aber auch keine Backup erstellt worden, oder haben 0k an Größe. Das sollte man dann doch vorher mal checken.
Ich dachte hier ist etwas mehr an Leuten mit Hirn, als bei mir in der Firma, wo ich immer davon ausgehen kann ich hab ein Pfosten vor mir und liege damit zu 99% richtig LOL@jan1 said in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
Ich dachte hier ist etwas mehr an Leuten mit Hirn, als bei mir in der Firma, wo ich immer davon ausgehen kann ich hab ein Pfosten vor mir und liege damit zu 99% richtig
Das habe ich auch mal gedacht. Zwischenzeitlich bin ich an dem Punkt angelangt das die meisten Leute open source vor allem deswegen einsetzen weil es nichts kosten (muss), ergo "Geiz ist geil" Mentalität. Wegen der Nachhaltigkeit oder dem "Recht zu besitzen/reparieren" (also nicht nur die Hardware sondern eben das Komplettpaket) setzen glaube ich nur die wenigsten auf open source.
OK, dann sind aber auch keine Backup erstellt worden, oder haben 0k an Größe. Das sollte man dann doch vorher mal checken.
Nein, man sollte wirklich den restore machen, so wie du. Und zwar nicht weil man "zu viel Zeit hat" sondern um zu überprüfen ob ein Backup auch erfolgreich war.
und genau das bestätige ich damit, auch wenn es aus Langeweile raus gemacht wurde.
Leider klingen deine Aussagen hier im Thread eher wie "Backup funktioniert immer, ich habe ja getestet also könnt ihr euch darauf verlassen".
Wenn man die mit dem Backitup Adapter machen lässt, dann habe ich hier noch von keinem gelesen, dass die nicht funktioniert hätten.
Es wird wahrscheinlich ein paar (hoffentlich wenige) geben die sich darauf verlassen werden und dann in ein paar Wochen/Monate/Jahren einen Thread auf machen "Hilfe, alles futsch!! Mein Backup funktioniert nicht!!"
-
@jan1 said in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
Ich dachte hier ist etwas mehr an Leuten mit Hirn, als bei mir in der Firma, wo ich immer davon ausgehen kann ich hab ein Pfosten vor mir und liege damit zu 99% richtig
Das habe ich auch mal gedacht. Zwischenzeitlich bin ich an dem Punkt angelangt das die meisten Leute open source vor allem deswegen einsetzen weil es nichts kosten (muss), ergo "Geiz ist geil" Mentalität. Wegen der Nachhaltigkeit oder dem "Recht zu besitzen/reparieren" (also nicht nur die Hardware sondern eben das Komplettpaket) setzen glaube ich nur die wenigsten auf open source.
OK, dann sind aber auch keine Backup erstellt worden, oder haben 0k an Größe. Das sollte man dann doch vorher mal checken.
Nein, man sollte wirklich den restore machen, so wie du. Und zwar nicht weil man "zu viel Zeit hat" sondern um zu überprüfen ob ein Backup auch erfolgreich war.
und genau das bestätige ich damit, auch wenn es aus Langeweile raus gemacht wurde.
Leider klingen deine Aussagen hier im Thread eher wie "Backup funktioniert immer, ich habe ja getestet also könnt ihr euch darauf verlassen".
Wenn man die mit dem Backitup Adapter machen lässt, dann habe ich hier noch von keinem gelesen, dass die nicht funktioniert hätten.
Es wird wahrscheinlich ein paar (hoffentlich wenige) geben die sich darauf verlassen werden und dann in ein paar Wochen/Monate/Jahren einen Thread auf machen "Hilfe, alles futsch!! Mein Backup funktioniert nicht!!"
@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.Ich habe schon von Beginn des Backitup Adapter mit diesen Backups restort und könnte mich nicht an ein Problem erinnern. Ebenfalls der Umzug vom Pi auf den Beelink, ohne Probleme und weil das Backup hier eigentlich gar kein Backup ist, sondern "nur" ein Backup der Einstellungen, verwendeter Adapter und Scripte, ist es eben hervorragend geeignet um damit sein System wieder sauber zu bekommen.
Die meiste Arbeit steckt übrigens in den Scripten und die sichere ich noch mal extra, da der Rest eh sehr schnell wieder zusammen geklickt ist. Die gesicherten Scripte habe ich aber auch noch nie benötigt.
Die meisten hier setzten IOBroker wohl ein, weils einfach einfach ist und wissen nicht mal dass es open source ist, somit dürfte das Thema Geiz ist geil wohl auch nicht zutreffen ;)
-
@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.Ich habe schon von Beginn des Backitup Adapter mit diesen Backups restort und könnte mich nicht an ein Problem erinnern. Ebenfalls der Umzug vom Pi auf den Beelink, ohne Probleme und weil das Backup hier eigentlich gar kein Backup ist, sondern "nur" ein Backup der Einstellungen, verwendeter Adapter und Scripte, ist es eben hervorragend geeignet um damit sein System wieder sauber zu bekommen.
Die meiste Arbeit steckt übrigens in den Scripten und die sichere ich noch mal extra, da der Rest eh sehr schnell wieder zusammen geklickt ist. Die gesicherten Scripte habe ich aber auch noch nie benötigt.
Die meisten hier setzten IOBroker wohl ein, weils einfach einfach ist und wissen nicht mal dass es open source ist, somit dürfte das Thema Geiz ist geil wohl auch nicht zutreffen ;)
@jan1 sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
somit dürfte das Thema Geiz ist geil wohl auch nicht zutreffen
falsch!
eine gute (nicht Systemübergreifende) Software mit den Fähigkeiten kostet richtig Geld.
Fang mal bei Mediola an -
@jan1 sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
somit dürfte das Thema Geiz ist geil wohl auch nicht zutreffen
falsch!
eine gute (nicht Systemübergreifende) Software mit den Fähigkeiten kostet richtig Geld.
Fang mal bei Mediola an@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 ;)
-
@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.Ich habe schon von Beginn des Backitup Adapter mit diesen Backups restort und könnte mich nicht an ein Problem erinnern. Ebenfalls der Umzug vom Pi auf den Beelink, ohne Probleme und weil das Backup hier eigentlich gar kein Backup ist, sondern "nur" ein Backup der Einstellungen, verwendeter Adapter und Scripte, ist es eben hervorragend geeignet um damit sein System wieder sauber zu bekommen.
Die meiste Arbeit steckt übrigens in den Scripten und die sichere ich noch mal extra, da der Rest eh sehr schnell wieder zusammen geklickt ist. Die gesicherten Scripte habe ich aber auch noch nie benötigt.
Die meisten hier setzten IOBroker wohl ein, weils einfach einfach ist und wissen nicht mal dass es open source ist, somit dürfte das Thema Geiz ist geil wohl auch nicht zutreffen ;)
@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 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...
@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
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.
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 😊
-
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 😊
@saeft_2003
und schon ist geklärt warum Dein Backup so groß ist und trotzdem "normal" ist ;) -
Ich wollte hier mal für Raspberry OS festhalten, wie ich von 'Buster' auf das 'Bullseye'-Release springe.
Gegeben ist ein Pi3 mit 1 GB, der schon etwas länger in einer Schublade lag.
Zunächst den 'Buster' auf den letzten Stand bringen:
pi@raspberrypi:~ $ sudo apt update Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] Get:2 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. Do you want to accept these changes and continue updating from this repository? [y/N]Hier wurden die Repos schon auf den neuen Status 'oldstable' angepasst. Akzeptieren wir natürlich.
Bei mir wurden 180 Pakete zum Upgrade gemeldet.
sudo apt full-upgradeHat mir das System auf den letzten Stand gehoben, da aber auch ein Kernel- und Firmware-Update dabei war starte ich per
sudo reboot noweinmal durch.
Nach dem der Server wieder auf die Beine gekommen ist sollte es ungefähr so aussehen:
pi@raspberrypi:~ $ sudo apt update Hit:1 http://archive.raspberrypi.org/debian buster InRelease Hit:2 https://repos.influxdata.com/debian buster InRelease Hit:3 https://packages.grafana.com/oss/deb stable InRelease Hit:4 https://deb.nodesource.com/node_14.x buster InRelease Hit:5 http://raspbian.raspberrypi.org/raspbian buster InRelease Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date.Also alle Pakete sind auf dem letzten Stand von 'Buster' und auch die einzelnen Repositories/Paketquellen verweisen auf stable oder buster.
Jetzt stellen wir die Quellen auf das aktuelle Release 'bullseye' um. Das macht man entweder von Hand in allen .list-Dateien im Pfad /etc/apt oder mit diesen drei Befehlszeilen:
sudo sed -i 's/buster\/updates/bullseye-security/g' /etc/apt/sources.list sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/*Wie man sieht wurden jetzt alle Datein auf bullseye umgestellt:
pi@raspberrypi:~ $ sudo apt update Hit:1 http://archive.raspberrypi.org/debian bullseye InRelease Hit:2 http://raspbian.raspberrypi.org/raspbian bullseye InRelease Hit:3 https://repos.influxdata.com/debian bullseye InRelease Hit:4 https://packages.grafana.com/oss/deb stable InRelease Hit:5 https://deb.nodesource.com/node_14.x bullseye InRelease Reading package lists... Done Building dependency tree Reading state information... Done 1067 packages can be upgraded. Run 'apt list --upgradable' to see them.1067 Pakete müssen nun aktualisiert werden:
sudo apt full-upgradeDas führt unter Umständen zu einer Fehlermeldung, das eine unmögliche Upgrade-Konstellation herbeigeführt würde. Da dann einfach
sudo apt install gcc-8-baseausführen, dann nochmal
sudo apt updateund dann sollte auch ein
sudo apt full-upgradefunktionieren. Nicht davon irritieren lassen, dass ggf. einige Pakete deinstalliert werden, das ist okay.
Die Frage, ob Services automatisch neugestartet werden sollen beantworten wir mit Ja:
│ │ │ Restart services during package upgrades without asking? │ │ │ │ <Yes> <No> │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘Wenn der erste Schwung durch ist schauen wir per
sudo apt update sudo apt full-upgradenach ob noch etwas ansteht. Das machen wir solange bis keine Pakete mehr zum Upgrade vorgesehen sind:
All packages are up to date.Bei Rückfragen, welche Version der Konfigurationsdateien muss mal reinschauen, ob man da ggf. eigene Anpassungen getätigt hat, ansonsten würde ich die neue Version des Maintainers übernehmen.
Vorsichtshalber schauen wir noch in den dhcpd.service rein.
sudo nano /etc/systemd/system/dhcpcd.service.d/wait.confWenn da alt sowas drin steht:
[Service] ExecStart= ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -wändern wir es auf neu:
[Service] ExecStart= ExecStart=/usr/sbin/dhcpcd -q -wab
Nach einem erneuten
sudo reboot nowbefinden wir uns bei Bullseye:
pi@raspberrypi:~ $ neofetch `.::///+:/-. --///+//-:`` pi@raspberrypi `+oooooooooooo: `+oooooooooooo: -------------- /oooo++//ooooo: ooooo+//+ooooo. OS: Raspbian GNU/Linux 11 (bullseye) armv7l `+ooooooo:-:oo- +o+::/ooooooo: Host: Raspberry Pi 3 Model B Plus Rev 1.3 `:oooooooo+`` `.oooooooo+- Kernel: 5.10.52-v7+ `:++ooo/. :+ooo+/.` Uptime: 4 mins ...` `.----.` ``.. Packages: 1487 (dpkg) .::::-``:::::::::.`-:::-` Shell: bash 5.1.4 -:::-` .:::::::-` `-:::- Terminal: /dev/pts/0 `::. `.--.` `` `.---.``.::` CPU: BCM2835 (4) @ 1.400GHz .::::::::` -::::::::` ` Memory: 65MiB / 923MiB .::` .:::::::::- `::::::::::``::. -:::` ::::::::::. ::::::::::.`:::- :::: -::::::::. `-:::::::: :::: -::- .-:::-.``....``.-::-. -::- .. `` .::::::::. `..`.. -:::-` -::::::::::` .:::::` :::::::` -::::::::::` :::::::. .::::::: -::::::::. :::::::: `-:::::` ..--.` ::::::. `...` `...--..` `...` .:::::::::: `.-::::-`Kleine Nachpflege noch:
sudo apt install build-essential@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.confalt:
[Service] ExecStart= ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -wneu:
[Service] ExecStart= ExecStart=/usr/sbin/dhcpcd -q -wWie 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.
Master: Intel NUC10i5-32GB-1TB_SSD - Proxmox 8.3 - LXC Debian 11
Slave1: RPi3B - ZigBee CC2652P - 10x DS18B20
Slave2: RPi3B - ZigBee CC2538+CC2592
node.js 20.18.1 / NPM 10.8.2 / js-controller 7.0.3 -
@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.confalt:
[Service] ExecStart= ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -wneu:
[Service] ExecStart= ExecStart=/usr/sbin/dhcpcd -q -wWie 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.
Kann ich auf meinen Systemen nicht nachstellen.
-
Kann ich auf meinen Systemen nicht nachstellen.
@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...
Master: Intel NUC10i5-32GB-1TB_SSD - Proxmox 8.3 - LXC Debian 11
Slave1: RPi3B - ZigBee CC2652P - 10x DS18B20
Slave2: RPi3B - ZigBee CC2538+CC2592
node.js 20.18.1 / NPM 10.8.2 / js-controller 7.0.3 -
@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...
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 bootIch warte bei meinen Systemen nicht, deswegen gibt es bei mir auch die Datei nicht.
-
@thomas-braun Ich habe dort nichts geändert. Es sind also die Standardeinstellungen drin. Und da wird wahrhaftig auf das Netzwerk gewartet. Sehr interessant....
Support us
821
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge