[Bullseye] : Kernel Panic - nach Update von Buster

[tscott]

Hallo Leute,

ich habe heute das Upgrade von Buster zu Bullseye gemacht und leider startet der Kernel nicht mehr.
Es kommt ein 'Kernel Panic' Error nach zwei Sekunden. Das Problem ist wohl ein fehlender Kerneltreiber-Module "i950".

Was kann man da machen? Ist Neuinstallation die einzige Option?
Ich habe vor dem upgrade noch eine Datei basierte Sicherheitskopie von dem ganzen Rechner gemacht. Da der Rechner nun gar nicht mehr hoch fährt habe ich auch keine Idee wie ich diese einspielen könnte.
Vor dem OS Start kann man im GRUB-Startmenü einen Kernel auswählen. Mit der Zeit haben sich so etwa 7 Stück angesammelt (pro Kernelversion einmal 'normal' und einmal eine 'recovery' (sic!) Version). Aber keiner von denen läuft nun hoch.

Ich kann leider auch kein log oder ähnliches beisteuern da der Rechner ja nun nicht mehr bootet und es daher keine Konsole gibt. Allenfalls ein abfotografierter Bildschirm wäre noch eine Möglichkeit.

Ciao
Tom

[Blackbox]

Debian Live und chroot sollte doch möglich sein.
Damit sollte eine Reparatur möglich sein.

Aber ohne konkrete Fehlermeldungen ist das ein Schreiten im Nebel.

[kalle123]

Ich habe vor dem upgrade noch eine Datei basierte Sicherheitskopie von dem ganzen Rechner gemacht. Da der Rechner nun gar nicht mehr hoch fährt habe ich auch keine Idee wie ich diese einspielen könnte.

Womit gemacht?

Fährt der Rechner denn noch über ein System Knoppix o.ä. auf nem Live USB Stick hoch?

cu KH

[tscott]

Ich habe hier noch zwei Bilder zu dem Fall.

gallery/image/3566
Das Bild zeigt ganz oben dass die i915 Firmware nicht geladen werden kann.Alles weitere verstehe ich leider nicht so wirklich.

gallery/image/3565
Das Bild zeigt welche (Buster-)Kernels sich inzwischen so angesammelt haben.

Ich hoffe das hilft ein bisschen.

Zu den Fragen:

Ich habe vor dem upgrade noch eine Datei basierte Sicherheitskopie von dem ganzen Rechner gemacht.

Womit gemacht?

Mit 'rsync' auf einer externen ext4 Festplatte.

Fährt der Rechner denn noch über ein System Knoppix o.ä. auf nem Live USB Stick hoch?

Der Rechner fährt mit einer Installations-CD (Buster) hoch. Ich *könnte* damit neu installieren. Ein Live System müsste ich mir aber erstmal aus dem Netz ziehen. Auch ein neues Bullseye Installations-Image, falls ich neu installieren muß, müßte ich mir erstmal downloaden.

Ciao
Tom

[schwedenmann]

Hallo

Vor dem OS Start kann man im GRUB-Startmenü einen Kernel auswählen. Mit der Zeit haben sich so etwa 7 Stück angesammelt (pro Kernelversion einmal 'normal' und einmal eine 'recovery' (sic!) Version). Aber keiner von denen läuft nun hoch.

auch keiner der 7 recovery-Einträge ?


Ansomnsten mal mehr input

1. welche Hardware
2. Partitionsschema und wieviel Platz noch auf /boot und / frei ist


mfg
schwedenmann

[tscott]

Hallo

Vor dem OS Start kann man im GRUB-Startmenü einen Kernel auswählen. Mit der Zeit haben sich so etwa 7 Stück angesammelt (pro Kernelversion einmal 'normal' und einmal eine 'recovery' (sic!) Version). Aber keiner von denen läuft nun hoch.

auch keiner der 7 recovery-Einträge ?

Nein, kein einziger.

Ansomnsten mal mehr input

1. welche Hardware

Steht in dem ersten Bild von meinem vorherigen Post:
Es ist ein "ZOTAC ZBOX-CI329NANO". Sehr beliebt für kleine Heimserver. Hat zwei Ethernet Schnittstellen. Wenig Stromverbrauch.

2. Partitionsschema und wieviel Platz noch auf /boot und / frei ist

/dev/sda1 primär 20GB f ext4 /boot
/dev/sda2 primär 200GB f ext4 /
/dev/sda5 primär 200GB f ext4 /home
/dev/sda6 primär 50GB f ext4 /var
/dev/sda7 primär 30GB f ext4 /tmp
/dev/sda8 primär 12.1GB Swap Swap

Es ist noch überall jede Menge Platz ohne Ende. Ich kann das jetzt natürlich nicht so sagen aber es ist sowohl auf /boot als auch auf '/' so gut wie nichts benutzt. Ich kann das jetzt nur nicht belegen da der Rechner ja nicht hoch läuft.

UPDATE:
Ich habe jetzt auch ein bisschen weiter gelesen. Scheinbar fehlt die Firmware 'i915/glk_dmc_ver1_04' im Verzeichnis '/lib/firmware'.
Aber warum gerade jetzt? Das hatte doch mit Buster alles funktioniert.

Jetzt die großen zwei Fragen: Wo bekomme ich das her? Und wie bekomme ich das in das Verzeichnis '/lib/firmware'? Ich nehme an mit einem Live-System, richtig? Und dann /dev/sda2 mounten und da in das Verzeichnis spielen, richtig?

Ciao
Tom

[MSfree]

Jetzt die großen zwei Fragen: Wo bekomme ich das her?

Code: Alles auswählen

apt-get install firmware-misc-nonfree

allerdings muß dafür in /etc/apt/sources.list contrib und non-free eingetragen sein.

Ich nehme an mit einem Live-System, richtig?

Ist dein System denn überhaupt eines mit graphischer Oberfläche?

Ich würde eines der Recoveries mit dem Cursor anfahren, dann in Grub auf "e" tippen, damit kannst du den Starteintrag ändern. Dann hängst du an die Kernelzeile noch nomodeset an und versuchst, damit zu booten. Dann kommt die Kiste zwar nicht im Graphikmodus hoch, oder in einem primitiven, langsamen VGA-Modus, aber immerhin solltest du damit den oben genannten Befehl ausführen können.

[tscott]

Jetzt die großen zwei Fragen: Wo bekomme ich das her?

Code: Alles auswählen

apt-get install firmware-misc-nonfree

allerdings muß dafür in /etc/apt/sources.list contrib und non-free eingetragen sein.

Ich nehme an mit einem Live-System, richtig?

Ist dein System denn überhaupt eines mit graphischer Oberfläche?

Ich würde eines der Recoveries mit dem Cursor anfahren, dann in Grub auf "e" tippen, damit kannst du den Starteintrag ändern. Dann hängst du an die Kernelzeile noch nomodeset an und versuchst, damit zu booten. Dann kommt die Kiste zwar nicht im Graphikmodus hoch, oder in einem primitiven, langsamen VGA-Modus, aber immerhin solltest du damit den oben genannten Befehl ausführen können.

Danke für den Tipp. Das werde ich morgen nach der Arbeit ausprobieren und berichten.
Zur Frage: Mein System hat xfce, also ja eine grafische Oberfläche.
Aber jetzt habe ich mal ne Frage: Was machen die Recovery Kernels anders gegenüber dem Original?
Für heute ist erstmal Feierabend.

Ciao
Tom

[MSfree]

Was machen die Recovery Kernels anders gegenüber dem Original?

Da wird der selbe Kernel, aber mit anderen Startparametern gestartet. In meinem Fall (Bullseye) ist der normale Sart mit

Code: Alles auswählen

/boot/vmlinuz-5.10.0-11-amd64 root=UUID=c[...]c ro  quiet

der Recovery-Modus mit

Code: Alles auswählen

/boot/vmlinuz-5.10.0-11-amd64 root=UUID=c[...]c ro single 

Und wenn man das mit nomodeset durchführen will, ändert man den Recovery-Modus in

Code: Alles auswählen

/boot/vmlinuz-5.10.0-11-amd64 root=UUID=c[...]c ro nomodeset single 

(die UUID habe ich gekürzt, um die Zeilen nicht zu lang werden zu lassen)

[willy4711]

Aber jetzt habe ich mal ne Frage: Was machen die Recovery Kernels anders gegenüber dem Original?

Ich denke dass das auch nicht funktioniert ??
Sonst:
Es wird in den Singel User Mode gebootet. -----> Ohne Eingabe des Root PW
Bei mir:

/boot/vmlinuz-5.15.0-3-amd64 root=UUID=c7ef160f-b124-4aab-9480-a2b9b5055db2 ro single

Es werden dabei praktisch keinen Dienste gestartet

Kannst dir ja mal das Target und den Service anschauen:

Code: Alles auswählen

~$ ls -A /lib/systemd/system/ |grep rescue
rescue.service
rescue.target
rescue.target.wants

Edit:
Könnte auch sein das nur das Programm

Code: Alles auswählen

/lib/systemd/systemd-sulogin-shell

sein, das dann mit dem Parameter --force aufgerufen wird (Ohne Root-PW).

Was ich auch nicht verstehe ist das "ro".
Ich kann in diesem Modus problemlos installieren und Updates machen.
Wird wohl irgendwo "eliminiert" und in "rw" geändert.

[tscott]

Was machen die Recovery Kernels anders gegenüber dem Original?

Da wird der selbe Kernel, aber mit anderen Startparametern gestartet. In meinem Fall (Bullseye) ist der normale Sart mit

Code: Alles auswählen

/boot/vmlinuz-5.10.0-11-amd64 root=UUID=c[...]c ro  quiet

der Recovery-Modus mit

Code: Alles auswählen

/boot/vmlinuz-5.10.0-11-amd64 root=UUID=c[...]c ro single 

Und wenn man das mit nomodeset durchführen will, ändert man den Recovery-Modus in

Code: Alles auswählen

/boot/vmlinuz-5.10.0-11-amd64 root=UUID=c[...]c ro nomodeset single 

(die UUID habe ich gekürzt, um die Zeilen nicht zu lang werden zu lassen)

Danke nochmal für die Zusatzinformationen. Das ist sehr aufschlussreich und hilft die Zusammenhänge zu verstehen. Ich habe den Start mit 'nomodeset' noch nicht ausprobieren können (muß arbeiten), aber ich werde berichten was dann passiert ist.

Eine Frage brennt mir aber noch auf den Fingern:
Warum verlangt der neue Kernel *jetzt, nach dem Upgrade von Buster zu Bullseye*, die Firmware 'i915/glk_dmc_ver1_04'? Warum hat das ohne mit Buster sehr gut funktioniert?
Und warum wurde diese Firmware beim Upgrade nicht einfach mit installiert wenn die so dringend benötigt wird? Hinweis: In /etc/apt/sources.list ist bei mir definitiv *immer* contrib und non-free gesetzt.

Ciao
Tom

[MSfree]

Warum hat das ohne mit Buster sehr gut funktioniert?

Die Firmware wurde auch vorher schon benötigt. Spätestens seit der integrierten Graphiklösung Intel HD-Grafik 530, also bei den Core-i ab Skylake (ca. 2015), ist diese nötig und wurde auch bereits für Debian Wheezy benötigt. Das ist also nichts neues und schon gar nichts plötzliches.

Warum das bei dir "gut" ohne Firmware funktioniert hat, kann ich nur vermuten. Grundsätzlich funktionieren die absoluten Basisfunktionen der Intel Graphikhardware auch ohen Firmware. Aber sobald irgendwelche Graphikeffekte darzustellen sind, wie z.B. Fenster minimieren/maximieren mit Animation, wird die Firmware benötigt. Hättest du Gnome als Desktop, wäre das schon sehr viel früher aufgefallen.

Und warum wurde diese Firmware beim Upgrade nicht einfach mit installiert wenn die so dringend benötigt wird?

Die wird nur dann aktualisiert, wenn du bereits Firmware installiert hattest. Automatisch wird Firmware jedenfalls nicht installiert.

Ich bin mir bei deinem Problem auch gar nicht so sicher, ob es überhaupt mit der Graphik zusammenhängt. Wie gesagt, der reine Textmodus sollte immer funktionieren.

Funfact: ich habe am Wochenende einen alten iMac von 2006 Debian Bullseye verpaßt. Der ist auch beim Booten abgestürzt, lustigerweise aber nicht immer. Ich dachte auch erst an ein Graphikproblem, bei dem ich mit nomodeset experimentiert habe, verbaut ist da aber eine Radeon X1600. Letzten Endes war es aber ein völlig anderes Kernelmodul, das gezickt hat.Seit ich das geblacklistet habe, läuft die Kiste. Es wäre hier aber sinnlos, dieses Kernelmodul zu benennen, denn das hatte sicher nur bei dem iMac mit seinem EFI (nicht UEFI und auch nicht BIOS) nicht funktioniert.

[tscott]

... Letzten Endes war es aber ein völlig anderes Kernelmodul, das gezickt hat.Seit ich das geblacklistet habe, läuft die Kiste.

Ich vermute auch dass es womöglich ein anderes Modul ist. Aber wie hast du das heraus gefunden? Ich vermute mit einem Live-Linux booten und sich das dmesg angucken, oder?
Kann man dem System mit einem Installationsmedium einen "Default"-Kernel unterjubeln? Also gibt es quasi die Option "Installieren --> nur Kernel installieren" ??

[novalix]

Ich bin mir bei deinem Problem auch gar nicht so sicher, ob es überhaupt mit der Graphik zusammenhängt. Wie gesagt, der reine Textmodus sollte immer funktionieren.

Der Einschätzung schliesse ich mich an.
Nach der Meldung über die fehlende Firmware wird der Boot-Prozess ja noch fortgeführt. Das root filesystem wird als "clean" erkannt.
Ich vermute Deine initial ramdisks sind im Eimer.
Du müsstest also in ein Live-System booten, in die Installation chrooten und von dort aus die Situation verstehen und reparieren.
Es müssen alle notwendigen Partitionen eingebunden werden (/home kannst Du aussen vor lassen).
Als erstes wäre zu überprüfen, ob *tatsächlich* noch ausreichend Platz in den Partitionen vorhanden ist.
Der nächste Schritt wäre imho den Paketmanager um seine Einschätzung zu bitten:

Code: Alles auswählen

apt* update && apt* upgrade

[MSfree]

Aber wie hast du das heraus gefunden? Ich vermute mit einem Live-Linux booten und sich das dmesg angucken, oder?

Wie gesagt, der Rechner ist mit dem Bullseyekernel hin und wieder hochgefahren. Ich habe dann die Ausgaben auf dem Bildschirm, bei denen erfolgreich gebootet wurde, mit den Ausgaben verglichen, die beim Absturz kamen. Das hat mich letztlich auf das Problem gebracht. Da ich auch nicht der einzige Betroffene war, habe ich auch per Suchmaschine ein paar Foren mit entsprechenden Threads gefunden.

[tscott]

Guten Abend

Heute nach der Arbeit habe ich den Tipp mit dem nomodeset ausprobiert. Leider ohne Erfolg. Der Rechner stürzt jetzt zwar etwas später ab aber letztendlich mit genau denselben Meldungen wie auf dem Bild ein paar Threads weiter oben.

Aber ein Memory Stick mit einem 11.2 Bullseye Live-Linux lässt sich problemlos starten. Nun würde ich gerne genau den Kernel der da auf dem Stick drauf ist auf den Rechner ins GRUB2 integrieren um den Rechner damit zu booten. Ich muß gestehen dass ich noch nie Plattenpartitionen in ein Live-System eingebunden habe. Ein Versuch die Plattenpartitionen sda1 und sda2 nach /mnt bzw. /mnt/boot scheiterte da das gesamte Live Linux scheinbar Read only ist.
Frage: Wie kann ich die beiden Partitionen mounten um dort den Kernel des Live Systems mit chroot zu integrieren?

Update: Ich habs gefunden https://wiki.ubuntuusers.de/chroot/Live-CD/

Ciao
Tom

[MSfree]

Aber ein Memory Stick mit einem 11.2 Bullseye Live-Linux lässt sich problemlos starten. Nun würde ich gerne genau den Kernel der da auf dem Stick drauf ist auf den Rechner ins GRUB2 integrieren um den Rechner damit zu booten.

Der Kernel auf dem Live-System ist der gleiche wie der, der bei der Installation von Bullseye installiert wird. Unterschiede sind maximal ein paar auf dem Live-System weggelassene Kernelmodule und/oder Bootparameter.

Wenn du dich mit chroot in das installierte System begibst, kannst du dort mal die Journals durchforsten, um zu sehen, was da schief geht.

Und da du ja eine ganze Sammlung an Partitionen auf deiner Platte hast, solltest du die auch genauso mounten, daß nach dem chroot die Umgebung zur Verfügung steht, wie nach einem normalen Boot.

Wenn du also /dev/sda2 auf /mnt gemountet hast, mußt du /dev/sda5 nach /mnt/home mounten, /dev/sda6 nach /mnt/var und /dev/sda7 nach /mnt/tmp, bevor du dein chroot ausführst. Dann solltest du unbedingt nochmal schauen, ob nicht doch eines der Dateisysteme voll ist (auch wenn du das weiter oben bestreitest).

Nachdem sich bei dir ja schon so einige Kernel angesammelt haben, gehe ich davon aus, daß du noch nie

Code: Alles auswählen

apt-get clean

und auch noch nie

Code: Alles auswählen

apt autoremove --purge

ausgeführt hast, was mich vermuten läßt, daß eine deiner Partitionen schlicht keinen Platz mehr hat. Das könnte dann auch erklären, warum dein Kernel nicht bootet, dem könnte nämlich das ein oder andere Modul fehler, weil z.B. das Erstellen der initrd unvollständig war....

[tscott]

Guten Abend ihr lieben Liebenden,

so schnell werdet ihr mich nicht los...

Also auf gehts zur nächsten Runde. Ich bin nun schon wieder etwas weiter mit meinem Problem und habe jetzt das Bullseye Live System gestartet und die Platte mit den ganzen Partitionen eingehangen. Ich schreibe übrigens auch mit dem Live-System gerade diesen Post. Das sieht dann so aus:

Code: Alles auswählen

user@debian:/mnt/boot$ mount
:
:
/dev/sda1 on /mnt/boot type ext4 (rw,relatime)
/dev/sda2 on /mnt type ext4 (rw,relatime)
/dev/sda6 on /mnt/var type ext4 (rw,relatime)
/dev/sda5 on /mnt/home type ext4 (rw,relatime)
/dev/sda7 on /mnt/tmp type ext4 (rw,relatime)
/dev/sda1 on /mnt/boot type ext4 (rw,relatime)

Und dann hier noch - weil mir nicht geglaubt wird dass da noch ohne Ende Platz ist - die Belegung: (unwichtige ausgeblendet)

Code: Alles auswählen

user@debian:/mnt/boot$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1        19G    477M   17G    3% /mnt/boot
/dev/sda2       183G    5,8G  168G    4% /mnt
/dev/sda6        46G    4,6G   39G   11% /mnt/var
/dev/sda5       183G     13G  161G    8% /mnt/home
/dev/sda7        28G     45M   26G    1% /mnt/tmp
:
:

Aber leider kann ich kein chroot machen. Wenn ich das aufrufe, dann kommt ganz lapidar:

Code: Alles auswählen

user@debian:/$ sudo chroot /mnt
Speicherzugriffsfehler

Nun habe ich mir die ganzen Kernels angesehen die da so aufgelaufen sind mit der Zeit:

Code: Alles auswählen

user@debian:/mnt/boot$ ls -lisa
insgesamt 431360
     2     4 drwxr-xr-x  4 root root     4096  8. Feb 18:12 .
     2     4 drwxr-xr-x 19 root root     4096  6. Feb 12:32 ..
    13   204 -rw-r--r--  1 root root   206269 28. Nov 2020  config-4.19.0-13-amd64
    18   204 -rw-r--r--  1 root root   206242 30. Jan 2021  config-4.19.0-14-amd64
    22   204 -rw-r--r--  1 root root   206242 19. Mär 2021  config-4.19.0-16-amd64
    27   204 -rw-r--r--  1 root root   206214 18. Jul 2021  config-4.19.0-17-amd64
    30   204 -rw-r--r--  1 root root   206267 29. Sep 18:53 config-4.19.0-18-amd64
    34   232 -rw-r--r--  1 root root   236056  8. Dez 16:21 config-5.10.0-10-amd64
    38   232 -rw-r--r--  1 root root   236045 18. Jan 15:54 config-5.10.0-11-amd64
525313     4 drwxr-xr-x  5 root root     4096  6. Feb 12:32 grub
    40 36652 -rw-r--r--  1 root root 37527943  6. Feb 12:30 initrd.img-4.19.0-13-amd64
    16 35380 -rw-r--r--  1 root root 36227075 16. Jan 2021  initrd.img-4.19.0-13-amd64.old-dkms
    33 36656 -rw-r--r--  1 root root 37533705  6. Feb 12:31 initrd.img-4.19.0-14-amd64
    36 36672 -rw-r--r--  1 root root 37550558  6. Feb 12:31 initrd.img-4.19.0-16-amd64
    17 36668 -rw-r--r--  1 root root 37544203  6. Feb 12:31 initrd.img-4.19.0-17-amd64
    42 36672 -rw-r--r--  1 root root 37550183  8. Feb 18:13 initrd.img-4.19.0-18-amd64
    41 36672 -rw-r--r--  1 root root 37550183  6. Feb 12:37 initrd.img-4.19.0-18-amd64.old-dkms
    25 36840 -rw-r--r--  1 root root 37721893  8. Feb 18:12 initrd.img-4.19.0-18-amd64_sav
    37 40756 -rw-r--r--  1 root root 41733261 28. Dez 14:10 initrd.img-5.10.0-10-amd64
    21 40968 -rw-r--r--  1 root root 41950028  6. Feb 12:38 initrd.img-5.10.0-11-amd64
    11    16 drwx------  2 root root    16384  3. Jan 2021  lost+found
    12  3340 -rw-r--r--  1 root root  3419998 28. Nov 2020  System.map-4.19.0-13-amd64
    15  3344 -rw-r--r--  1 root root  3420599 30. Jan 2021  System.map-4.19.0-14-amd64
    20  3344 -rw-r--r--  1 root root  3421023 19. Mär 2021  System.map-4.19.0-16-amd64
    26  3344 -rw-r--r--  1 root root  3421235 18. Jul 2021  System.map-4.19.0-17-amd64
    24  3344 -rw-r--r--  1 root root  3423029 29. Sep 18:53 System.map-4.19.0-18-amd64
    32     4 -rw-r--r--  1 root root       83  8. Dez 16:21 System.map-5.10.0-10-amd64
    29     4 -rw-r--r--  1 root root       83 18. Jan 15:54 System.map-5.10.0-11-amd64
    14  5160 -rw-r--r--  1 root root  5283056 28. Nov 2020  vmlinuz-4.19.0-13-amd64
    19  5156 -rw-r--r--  1 root root  5278960 30. Jan 2021  vmlinuz-4.19.0-14-amd64
    23  5164 -rw-r--r--  1 root root  5287168 19. Mär 2021  vmlinuz-4.19.0-16-amd64
    28  5164 -rw-r--r--  1 root root  5287168 18. Jul 2021  vmlinuz-4.19.0-17-amd64
    31  5168 -rw-r--r--  1 root root  5291264 29. Sep 18:53 vmlinuz-4.19.0-18-amd64
    35  6684 -rw-r--r--  1 root root  6841280  8. Dez 16:21 vmlinuz-5.10.0-10-amd64
    39  6692 -rw-r--r--  1 root root  6849216 18. Jan 15:54 vmlinuz-5.10.0-11-amd64

Wichtige Info dazu: Am 06.02.2022 ~12:35 hatte ich besagtes Bullseye Update gemacht. Man sieht mehrere Kernel und initrd's und einer davon trägt die Endung "old-dkms" vom 6.2.. Also habe ich die Originale 'initrd.img-4.19.0-18-amd64' in 'initrd.img-4.19.0-18-amd64_sav' umbenannt und stattdessen die 'initrd.img-4.19.0-18-amd64.old-dkms' an die Stelle 'initrd.img-4.19.0-18-amd64' kopiert und werde gleich neu booten... Aber erstmal muß ich ja diesen Post hier abschicken, denn sonst ist der ja weg. Also bis morgen zur Auflösung. Ich muß dann erstmal was essen.

Ciao
Tom

[tscott]

Hallo,

heute einen Tag später muß ich leider melden dass das auch nicht funktioniert hat.
Heute werde ich versuchen den Kernel von der Live-CD dem defekten System über zu helfen. Mal sehen ob das klappt.

Bis dann
Tom

[tscott]

Hallo nochmal,

jetzt zitiere ich mich sogar selbst

Heute werde ich versuchen den Kernel von der Live-CD dem defekten System über zu helfen. Mal sehen ob das klappt.

...das hat aber auch nicht geklappt.

Ich habe nun wieder das komplette Buster Backup eingespielt. Der Rechner bootet jetzt wieder und läuft wie vorher aber ist nun leider wieder 'Bullseye' mit 550 wartenden Upgrades die aber den Rechner wieder zerstören. So ein Mist...

Was nu?

Ciao
Tom

[mcb]

Du könntest ja (erstmal) bei Buster bleiben, sofern der etwas geringere Securitysupport o.k. ist. -> sources.list auf buster setzen.

[rhHeini]

Dann hast Du ja die Gelegenheit mal genau hinzusehen was da installiert ist. Ich würd Dir raten mal die Kernel aufzuräumen, nur den neuesten oder maximal 2 zu behalten.

Dann ein Blick in die sources.list: ist da contrib non-free an allen Einträgen dran? Wenn nein, ergänzen. Wenn ja:

Code: Alles auswählen

# apt update
# apt full-upgrade
# apt list firmware*

Rolf

[tscott]

Ich würd Dir raten mal die Kernel aufzuräumen, nur den neuesten oder maximal 2 zu behalten.

Geht das mit 'apt autoremove; apt clean'?

Dann ein Blick in die sources.list: ist da contrib non-free an allen Einträgen dran? Wenn nein, ergänzen. Wenn ja:

Code: Alles auswählen

# apt update
# apt full-upgrade
# apt list firmware*

Was macht 'apt list firmware*'?

Danke
Tom

[rhHeini]

apt autoremove entfernt die Pakete die bei einem Upgrade als auto-remove-fähig angezeigt werden. Wenn die Kernel da nicht gelistet werden, ist ein apt remove paketname fällig, z.B. apt remove linux-image-4.19.0-13-amd64 entfernt den 13ner.

Was macht 'apt list firmware*'?

Probiers aus, es passiert nichts schlimmes. Versuch macht kluch. Außerdem gibt es man-pages ....

Rolf

[tscott]

Guten Abend,

ich bin nun wieder etwas weiter gekommen. Ich habe festgestellt, dass der Kernel-Panic von einem nicht vollständig ausgeführten 'apt full-upgrade' kam. Ich würde den Thread hier gerne als "root cause found" abschliessen. Dafür mache ich aber einen neuen auf. Titel: "[apt] 'full-upgrade' bricht ab' - Was nun?

Ciao
und vielen Dank für die Hilfe bei dem Thema
Tom