[gelöst] Upgrade von Buster auf Bullseye funktioniert nicht

[Draal]

Hallo Zusammen,

auf der Suche nach einem performanten Betriebssystem wollte ich mich von Win 10 abwenden.
Zuvorige Versuche ein Debian System aufzusetzen, misslangen an einer unrund laufenden Netzwerkkarte (onboard).
Dieses Problem wurde mittels eines BIOS Updates beseitigt.

In der Folge wurde ein Debian Buster über eine Netinstaller CD installiert, nur das Grundsystem mit Werkzeugen. Das System lief stabil. Anschliessend habe ich apt von buster auf testing eingestellt, weil da doch schon etwas mehr Performance drinsteckt.
Die Pakete wurden nach apt upgrade auch heruntergeladen und installiert. Der daraufhin veranlasste reboot erzeugte eine kernel panic.

Hardware:
ASRock N68C-GS4 FX
AMD FX(tm)-4300 Quad-Core 3,8 GHz
Radeon HD 7700
SanDisk 512 GB SSD

Ich hab mir schon überlegt LMDE zu installieren, jedoch greift diese Distribution ja auf de testing Repos zu und wird wohl auch nicht laufen.

Vielleicht weiss jemand hier ja, was ich tun könnte.

Viele Grüße

draal

[DeletedUserReAsG]

Der daraufhin veranlasste reboot erzeugte eine kernel panic.
[…]
Vielleicht weiss jemand hier ja, was ich tun könnte.

Im Begleittext der Meldung des Kernel steht, was diesen Zustand verursacht hat. Dies könntest du nun lesen und ggf. hier posten – möglicherweise ist’s einfach zu beheben.

Was gerade bei so alten Sachen auf jeden Fall gemacht werden sollte: den Microcode für die CPU installieren und beim Booten laden.

Dass Bullseye allerdings performanter als Buster sein soll, erscheint mir ohne konkrete Details allerdings auch eher auf Wunschdenken zu basieren …

[willy4711]

Die Pakete wurden nach apt upgrade auch heruntergeladen und installiert.

Wenn du wirklich nur apt upgrade gemacht hast, brauchst du dich nicht wundern.
Mögliche Rettung:
Rettungsmodus aufrufen (erweiterte Optionen), falls der noch startet.
dann

Code: Alles auswählen

apt update && apt full-upgrade

Ansonsten würde ich eine Neuinstallation machen, bevor ich da weiter rumprobiere.
Und dann gleich Testing, falls du meinst, das zu brauchen.

Für deine Grafik-Karte brauchst du firmware-amd-graphics und firmware-linux

Allerdings musst du vorher deine sources.list um contrib non-free ergänzen.

Eine funktionierende surces.list kannst du mit diesem Tool erstellen:
https://debgen.simplylinux.ch/
Anleitung gibt es auch noch hier:
https://wiki.debian.org/SourcesList

[Draal]

Danke für die Hinweise,

Microcodes fand ich leider nur für Intel CPUs. Für den Rest war ich vermutlich zu ungeduldig. Hätte ja auch den Rechner über den Buster Kernel starten können.

Ich habe einen Server im Heimnetz laufen, auf Testing und muss ihn manchmal bemühen per ffmpeg eine h265 Datei in h264 umzurechnen. Dabei erwiesen sich die Testing Kernels als ca. 20% schneller. Kann ich aber nun nicht belegen.

Danke auch für den Hinweis auf die Firmware zur Grafikkarte. Die sources.list meines Servers steht bei mir seit ca. 15 Jahren auf Testing, was dieser problemlos geschluckt hat. Lediglich bei den anderen operativen Systemen (Desktop und Schlepptop) fiel mal KDE über einen längeren Zeitraum aus und so wurden sie wieder gewindowsst.

Derzeit läuft Testing mit KDE auf einer VM Box. Mach mal gelöst.

[Blackbox]

Microcodes fand ich leider nur für Intel CPUs.

Dann hast du leider nur unzureichend gesucht.
Dieses Paket amd64-microcode stellt den Microcode für AMD CPUs zur Verfügung.

Lediglich bei den anderen operativen Systemen fiel mal KDE über einen längeren Zeitraum aus und so wurden sie wieder gewindowsst.

Solche Einlassungen kann will ich gar nicht nachvollziehen.

[willy4711]

Microcodes fand ich leider nur für Intel CPUs.

Für deine Grafik-Karte brauchst du firmware-amd-graphics und firmware-linux

Code: Alles auswählen

$ ~$ apt depends firmware-linux
firmware-linux
  Hängt ab von: firmware-linux-free
  Hängt ab von: firmware-linux-nonfree (= 20200918-1)
  Empfiehlt: intel-microcode
  Empfiehlt: amd64-microcode

Hatte schon seinen Grund

[Draal]

Lediglich bei den anderen operativen Systemen fiel mal KDE über einen längeren Zeitraum aus und so wurden sie wieder gewindowsst.

Solche Einlassungen kann will ich gar nicht nachvollziehen.

Naja, ist schon Jahre her.
Keine Zeit, Kinder etc.

Auf jeden Fall haben die microcodes und die firmware die Entscheidung herbeigeführt. Bullseye läuft jetzt, nicht in der VM Box, sondern auf dem Rechner.

Vielen Dank nochmal.