NEWS
Upgrade von Debian 10 'Buster' auf 11 'Bullseye'
-
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....
-
@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 mitcd /etc sudo grep -rl buster .gefunden.
Vielleicht tritt das noch bei anderen Installationen hier im Forum auf. -
@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 mitcd /etc sudo grep -rl buster .gefunden.
Vielleicht tritt das noch bei anderen Installationen hier im Forum auf. -
@thomas-braun
Super, lass ich nochmal drüberlaufen.
Danke! -
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. -
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.@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.
-
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.@buggybeast Das "dhcp Problem" lässt sich durch eine einfach Korrektur in einer Datei beheben. Wozu der Aufwand?
-
@buggybeast Das "dhcp Problem" lässt sich durch eine einfach Korrektur in einer Datei beheben. Wozu der Aufwand?
@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 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.@markus78224 Interessant. Was hat er denn dann noch ausgeworfen im Log?
Ich habe die gleiche Config, nur mit einem PI 4. -
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.Heute gab es ein Update des dhcpcd5 Pakets.
Ich gehe davon aus, das damit das Thema keins mehr ist. -
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! -
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!@io_laurent sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
Kann es sein, dass dies mit dem Update zusammenhängt?
Jein. Kann mit dem USB-Adapter (und dem USB3) zusammenhängen.
Drüben 'beim Kofler' wurde das schon besprochen:https://kofler.info/usb-boot-fuer-den-raspberry-pi-4/
In der cmdline.txt kann man u. U. quirks für seinen Adapter setzen.
-
@io_laurent sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
Kann es sein, dass dies mit dem Update zusammenhängt?
Jein. Kann mit dem USB-Adapter (und dem USB3) zusammenhängen.
Drüben 'beim Kofler' wurde das schon besprochen:https://kofler.info/usb-boot-fuer-den-raspberry-pi-4/
In der cmdline.txt kann man u. U. quirks für seinen Adapter setzen.
@thomas-braun sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
Danke @Thomas-Braun, aber ich verstehe das leider nicht.
Ich boote den raspi auch von ner sd-Karte, die lahme Platte hängt nur als Medienspeicher am raspi, von der wird nicht gebootet.
Und von "quirks" habe ich noch nie gehört und weiß überhaupt nicht, was du damit meinst.
Eventuell noch ne kleine Hilfe?
Vielen Dank! -
@thomas-braun sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':
Danke @Thomas-Braun, aber ich verstehe das leider nicht.
Ich boote den raspi auch von ner sd-Karte, die lahme Platte hängt nur als Medienspeicher am raspi, von der wird nicht gebootet.
Und von "quirks" habe ich noch nie gehört und weiß überhaupt nicht, was du damit meinst.
Eventuell noch ne kleine Hilfe?
Vielen Dank!Das steht in den Kommentaren dort:
Normen
- SEPTEMBER 2020 UM 9:40 UHR
Hallo,
Das kann an den Adaptern liegen. Ich habe zwei USB to SATA Adapter. Einer von Sabrent und einen von Startech. Der Sabrent zeigt auch sehr lange den Bootbildschirm und bootet auch sehr langsam. Der Startech rast nur so ins Betriebssystem mit der gleichen SSD. Hatte mal gelesen dass das an den Controllern in den Adaptern liegt und der Pi nicht zu jedem Controller 100% Kompatibel ist und dann halt bei manchen Adaptern langsamer ist als von SD Karte.
Die 'quirks' für deinen Adapter musst du dir dann u. U. im auch dort verlinkten Forum zusammensuchen. Oder einen kompatiben Adapter verwenden.
https://forum-raspberrypi.de/forum/thread/47876-magische-usb-sata-adapter-und-wo-sie-zu-finden-sind/
USB3 würde ich im Übrigen gar nicht verwenden am Raspberry4. Die sind nur zur Deko verlötet, scheint mir.
-
Das steht in den Kommentaren dort:
Normen
- SEPTEMBER 2020 UM 9:40 UHR
Hallo,
Das kann an den Adaptern liegen. Ich habe zwei USB to SATA Adapter. Einer von Sabrent und einen von Startech. Der Sabrent zeigt auch sehr lange den Bootbildschirm und bootet auch sehr langsam. Der Startech rast nur so ins Betriebssystem mit der gleichen SSD. Hatte mal gelesen dass das an den Controllern in den Adaptern liegt und der Pi nicht zu jedem Controller 100% Kompatibel ist und dann halt bei manchen Adaptern langsamer ist als von SD Karte.
Die 'quirks' für deinen Adapter musst du dir dann u. U. im auch dort verlinkten Forum zusammensuchen. Oder einen kompatiben Adapter verwenden.
https://forum-raspberrypi.de/forum/thread/47876-magische-usb-sata-adapter-und-wo-sie-zu-finden-sind/
USB3 würde ich im Übrigen gar nicht verwenden am Raspberry4. Die sind nur zur Deko verlötet, scheint mir.
@thomas-braun Vielleicht habe ich mich missverständlich ausgedrückt, aber ich verstehe das mit dem Adapter nicht. Ich habe diese Platte https://www.seagate.com/de/de/consumer/backup/backup-plus-desk/
ohne irgendwelche Adapter direkt an den raspi angesteckt.
Und vorher lief die Platte ja auch fast zwei Jahre problemlos am USB3 Port (auch wenn der nur Deko ist, lief gut).
Daher, eventuell noch ne andere Idee?
Vielen Dank!
Support us
685
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge