Upgrade von Debian Buster nach Bullseye

[skydiver66]

ok, da steht noch buster drin

deb http://archive.raspberrypi.org/debian/ buster main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ buster main

[skydiver66]

oha, jetzt passiert was

hab den befehl ausgeführt und update/upgrade läuft gerade

[skydiver66]

es ist alles durchgelaufen, hab reboot gemacht und jetzt kann ich mich nicht mehr über terminal einloggen, glaub ich schmeiß das aus dem fenster

[deimos]

Und was genau hast du gemacht? Ich vermute mal nicht das aus der Schritt für Schritt Anleitung, die ich verlinkt habe.
Hattest du eine feste IP konfiguriert? Wenn nein, hat der Pi jetzt vielleicht einfach nur eine andere IP bekommen? Ansonsten: Monitor anschließen.
Oder natürlich destruktiv sein und alles zum Fenster rauswerfen, spart mir auch die Arbeit zu helfen.

[skydiver66]

Doch, hatte die Anleitung benutzt und danach deinen Befehl ausgeführt:

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

dann hab ich apt update/upgrade durchgeführt, was auch ohne Fehler durchgelaufen ist.

Ja, hatte ne feste IP, schaue gerade ob ich es im Netzwerk finde, Ping kam auch nicht mehr an.
Monitor hab ich kein minihdmi adapter mehr, ist defekt.

Mich macht das fertig, bin seit 0800 heute morgen damit am kämpfen... sorry

[Silverstar]

Bullseye hat mich auch vor Herausforderungen gestellt.

Zuerst habe ich ein Upgrade des Buster Images gemacht und dann auch Netzwerkprobleme gehabt, und ich hatte auch nicht die Möglichkeit einen Monitor anzuschließen.
Dann habe ich, da ich den Fehler noch nicht erkannt hatte, direkt mit einem Bullseye image gestartet und die selben Probleme gehabt.

Ein Problem, über das ich gestolpert bin, ist das "neue" Namensschema für Netzwerkinterfaces, welches zwar schon seit Jahren existiert, aber einem erst mit Bullseye auf die Füße fällt, da nun die alte Variante nicht mehr berücksichtigt wird.

Dadurch heißt das Netzwerkinterface plötzlich nicht mehr eth0, sondern z.b. enp2s0 - und damit greift eine Definition von eth0 in /etc/network/interfaces natürlich nicht mehr.

Über die cmdline.txt konnte ich zwar mit hinzufügen von "ip=192.168.x.y" vorübergehend den pi erreichen, aber wohl durch das Umbenennen von eth0 fällt diese Zuweisung nach kurzer Zeit weg und der Host ist nicht erreichbar aber die pivccu teilweise noch

Gelöst habe ich das mit "net.ifnames=0" in der cmdline, sodass das Interface weiterhin eth0 heißt und die Definition für eth0 in der interfaces Datei greift.
Der dhcpcd ist ja deinstalliert und daher gibt's ja auch keine ip via DHCP.

Trotzdem kommt der pi manchmal nicht richtig hoch, sodass der Host nicht erreichbar ist, die RPI-RF-MOD aber blau blinkt, also der pi offenbar bootet.

Klar könnte man die ip für den neuen Namen vergeben, sobald man den irgendwie herausgefunden hat, aber ich habe die Lösung mit dem Kernel Argument zuerst gefunden und das war dann die schnellere Lösung (bis das vielleicht auch irgendwann abgeschafft wird).

Zum Nachlesen bezüglich des "neuen" Namensschemas: https://wiki.debian.org/NetworkInterfaceNames

[skydiver66]

Ja, das würde gut zu meinem Problem passen, der Pi muss gebootet haben da ich auch das Licht der SSD arbeiten gesehen hab.

Es war auch keine Netzwerkadresse erreichbar und da läuft ein VPN, HM, OH, NodeRed, Motioneye etc. drüber, der Netzwerkanschluss war wie tot, nicht mal im Router zu finden.

Dachte erst es läge vlt. daran dass ich ein SSD benutze, hatte im Internet was zu Problemen mit Bullseye und SSDs gefunden, aber mit deine Aussage macht das schon mehr Sinn...

Finde es auch furchtbar, dass man immer sich als Betatester für alles hergeben muss, seit 15 Jahren bastel ich damit schon rum und immer wieder hat man neue Probleme. HM hat sich in den ganzen Jahren, meiner Meinung nach auch nicht wirklich weiterentwickelt.
Es bleibt für immer eine Bastelbude... Wenn du dich dann eine Weile damit nicht beschäftigst, dann weisst du auch oft gar nicht mehr wie du was gemacht hast, man ist damit ja nicht täglich zu gange...

Finde es auch von HM nen Witz wie manche Sachen gehandelt werden, so hier, das ist ein Funkmodul Bausatz, deshalb null support, backt euch eins und bringt es zum laufen.
Wenn es Leute wie Alex nicht gäbe, wer sollte einem denn da noch helfen? (btw 1000 dank Alex, ich werde es iwann nochmal neu aufsetzen, wenn ich Lust und Zeit finde).

Gruß T

[Silverstar]

Das Problem ist jetzt aber eines, welches von den zugrundeliegenden Betriebssystem kommt und wofür eq3 und Alex nichts können. Bei Einsatz des normalen ccu Images anstatt pivccu wäre das gar nicht aufgetreten.

[skydiver66]

Ja, schon klar, es liegt an der Umstellung des OS, warum weshalb man sowas immer macht? kein Plan... und die Probleme mit der eth0 ist nicht von HM gemacht, trotzdem hätte ich auch mit CCU ein Problem mit dem Smart Home gehabt weil OH darüber läuft, dann vielleicht in einem anderen Forum, bin hier auch nur gelandet wegen dem USB RF und debmatic, so ganz kann man das auch nicht immer trennen alles.

Das Alex nichts dafür kann ist mir bewusst, er ist ja auch immer mega hilfsbereit, mich ärgert nur diese ganze Problematik mit dem Smart Home und wie bei eQ3 oft damit umgegangen wird, teilweise ist man Tage damit beschäftigt und auf fixe ausm Netz angewiesen. Dafür dass eq3 einst die Pioniere in dem Sektor waren, ist das machnchmal ganz schön traurig...

[Monarque]

Hi zusammen,
ich habe auch gerade das gleiche Problem, dass ich heute Debmatic auf Bullseye neu aufsetzen wollte und bei der Installation von Debmatic Fehlermeldungen bekomme, mit denen ich nicht wirklich was anfangen kann.

sudo apt-get update bzw. --fix-missing hab ich probiert, ändert aber nichts am Ergebnis.

Code: Alles auswählen

sudo apt install debmatic -y
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden NEUEN Pakete werden installiert:
  debmatic
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 53,5 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
Holen:1 https://www.debmatic.de/debmatic stable/main arm64 debmatic arm64 3.69.7-105 [53,5 MB]
Fehl:1 https://www.debmatic.de/debmatic stable/main arm64 debmatic arm64 3.69.7-105
  Datei hat eine unerwartete Größe (53451056 != 53452104). Eventuell läuft gerade eine Spiegel-Synchronisierung? [IP: 65.108.197.112 443]
  Hashes of expected file:
   - SHA512:6c4131a4b6b4dcb43425f98a3bc1f3a51495bf1c10b9b44295f5cdb2c427c5d17e38da484bea9bcf9d11a2a4eb6997c8db474362208fc3d45a1009859449f019
   - SHA256:a878538c952a8813f0e97787280a2a327544207e0da306fe42fe5124522ff8fd
   - SHA1:3de91089100a46d3b59bb2156af89f380af1d851 [weak]
   - MD5Sum:11ff6fcdd8a29b9324981adea1d90bc5 [weak]
   - Filesize:53452104 [weak]
E: Fehlschlag beim Holen von https://www.debmatic.de/debmatic/pool/main/d/debmatic/debmatic-3.69.7-105-arm64.deb Datei hat eine unerwartete Größe (53451056 != 53452104). Eventuell läuft gerade eine Spiegel-Synchronisierung? [IP: 65.108.197.112 443]
   Hashes of expected file:
    - SHA512:6c4131a4b6b4dcb43425f98a3bc1f3a51495bf1c10b9b44295f5cdb2c427c5d17e38da484bea9bcf9d11a2a4eb6997c8db474362208fc3d45a1009859449f019
    - SHA256:a878538c952a8813f0e97787280a2a327544207e0da306fe42fe5124522ff8fd
    - SHA1:3de91089100a46d3b59bb2156af89f380af1d851 [weak]
    - MD5Sum:11ff6fcdd8a29b9324981adea1d90bc5 [weak]
    - Filesize:53452104 [weak]
E: Einige Archive konnten nicht heruntergeladen werden; vielleicht »apt-get update« ausführen oder mit »--fix-missing« probieren?

Ist da nur der Debmatic-Server down und ich sollte das einfach später nochmal probieren?
Bin leider nicht der Linux-Crack.