Upgrade von Debian 10 'Buster' auf 11 'Bullseye'

[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!

[Thomas Braun]

@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]

@thomas-braun sagte in Upgrade von Debian 10 'Buster' auf 11 'Bullseye':

https://kofler.info/usb-boot-fuer-den-raspberry-pi-4/

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]

@io_laurent

Das steht in den Kommentaren dort:

Normen

24. 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.

[io_laurent]

@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!

[Thomas Braun]

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

Daher, eventuell noch ne andere Idee?

Nee. Aber das Ding muss ja einen Controller / Adapter haben. Daher die Idee mit den quirks, das dort beobachtete Bild (alles langsam) passt halt zu deiner Beobachtung.