Kernel-Panic nach Update

[tabletennisskisrugby]

Hallo Leute!
Ich verwende Debian-Trixie und update meinen Computer jede Woche. Dieser ist über 12 Jahre alt und es hat bisher alles super funtkioniert. Ich starte mit UEFI, habe zwei Partitionen (FAT32-UEFI 100MB, BTRFS) auf meiner internen Sata und verwende das Dateisystem BTRFS. Es gibt 2 Subvolumes @root und @daten. In @root befindet sich das komplette Betriebssysten, inklusive boot-Verzeichnis.

Vorhin habe ich ein Update durchgeführt, aber danach ist der PC nicht mehr hochgefahren, siehe Bild unten. Zudem habe ich auch einen USB-Stick, auf welchem sich im Prinzip dasselbe System befindet, mit welchem ich regelmäßig Backups durchführe. Mit dem kann ich das System auf der Sata vor dem Update wiederherstellen und danach geht wieder alles.

Der Computer schreibt zu Beginn ganz kurz (viel kürzer als sonst nur 1 Sekunde) "Loading initial ramdisk ..." raus und danach erscheint die Kernel-Panic. Es wurde vom Kernel 6.9.7 auf den 6.9.12 upgedatet, aber wenn ich im Grub-Menu den alten Kernel auswähle, bekomme ich denselben Fehler.
Ich werde aus dem Fehler nicht ganz schlau, den einerseits scheint es ein Problem mit dem Initramfs-Archiv zu geben und anderererseits gibt es anscheinend ein Problem mit dem Parameter "subvol", so als könne @root nicht eingehängt werden.

Ich würde mich über eure Hilfe freuen und wir können nichts kaputt machen.
Wenn noch notwendige Infos fehlen, gebt mir bitte Bescheid.

Vielen Dank im Voraus.
LG Martin

[kreuzschnabel]

Sieht irnkwie aus, als sei das initramfs nicht richtig geschrieben worden. Er kriegt das erst nicht geöffnet und dann die Subvolumes nicht gemountet (ohne initramfs kann er mit btrfs nicht viel anfangen).

Läuft wohl darauf hinaus, von einem Livesystem zu starten und mit chroot noch ein update-grub laufen zu lassen.

--ks

(Hat mal jemand Chris Mason verklickert, dass sich „btrfs“ absolut scheiße tippen lässt? Vier Buchstaben hintereinander, für die der linke Zeigefinger zuständig ist.)

[towo]

Wenn Du ein Problem mit der initrd vermutest, was soll dann update-grub richten?

[tabletennisskisrugby]

Das habe ich bereits auprobiert. Ich bin mit dem USB-Stick hochgefahren, habe die Sata in /mnt eingehängt und folgende Befehle ausgeführt. Beim Booten kam der Fehler abermals:

Code: Alles auswählen

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.9.12-amd64
update-initramfs: Generating /boot/initrd.img-6.9.7-amd64
chroot /mnt update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.9.12-amd64
Found initrd image: /boot/initrd.img-6.9.12-amd64
Found linux image: /boot/vmlinuz-6.9.7-amd64
Found initrd image: /boot/initrd.img-6.9.7-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
chroot /mnt grub-install
x86_64-efi wird für Ihre Plattform installiert.
Installation beendet. Keine Fehler aufgetreten.
umount -R -v /mnt/sys
umount: /mnt/sys unmounted
umount /mnt/proc
umount /mnt/dev/pts
umount /mnt/dev

[kreuzschnabel]

Wenn Du ein Problem mit der initrd vermutest, was soll dann update-grub richten?

gnarf, ja. update-initramfs wärs gewesen.

--ks

[tabletennisskisrugby]

Hallo Zusammen!

Ich fasse nochmal zusammen und habe Folgendes ausprobiert, um die Verwirrung komplett zu machen:
1. Ich habe ein laufendes, funktionierendes System auf einem PC.
2. Nach einem Update bekomme ich die obige Kernel-Panic.
3. Dieses Linux-System, welches nicht mehr läuft habe ich nun auf einen USB-Stick gespielt und dort eingerichtet.
4. Wenn ich nun von dem USB-Stick boote, bekomme ich ebenfalls diese Kernel-Panic.
5. Wenn ich denselben USB-Stick an einem anderen PC anstecke, bootet das Linux-System problemlos.

Dies irritiert mich etwas, denn es sieht für mich fast so aus, als ob nach dem Update irgendwas mit der Hardware nicht mehr zusammenspielt.
Vielleicht hat jemand noch eine Idee.
Vielen Dank im Voraus.
LG

[mat6937]

... an einem anderen PC anstecke, bootet das Linux-System problemlos.

... ob nach dem Update irgendwas mit der Hardware nicht mehr zusammenspielt.

Wie unterscheiden sich diese PCs?

[tabletennisskisrugby]

Sie unterscheiden sich in jedem Hardware-Punkt.
Um es kurz zu machen: Der mit Kernel-Panic ist 12 Jahre alt, hat einen I7 und DDR3-Speicher. Grafik Onboard und SATA-SSD.
Der andere ist ein AMD 2 Jahre alt, DDR4, Sata-SSD, PCIE-Grafik.

Was mich bei der Kernel-Panic ebenfalls stutzig macht, ist diese Fehlermeldung: fuseblk: Unknown parameter 'subvol'
Es sieht so aus, als hätte er mit dem BTRFS ein Problem. Ich habe nun weitere Versuche angestellt. Auf dem besagten USB-Stick habe ich nun anstatt eines BTRFS-Dateisystems ein ext4 angelegt. Der Hochlauf hat nun ohne Probleme funktioniert, auch auf dem 12 Jahre alten PC.
Um dieses Mysterium zusammenzufassen: 12 Jahre alter PC + Update + BTRFS-Dateisystem = Kernel-Panic

Wenn eine der 3 Bedingungen nicht erfüllt ist, dann funktioniert das System einwandfrei.
Meine Vermutung ist, dass nach dem Upate irgendwas zu Beginn eventuell nicht mehr korrekt erkannt wird, aber warum der Parameter "subvol" nicht erkannt wird, wenn BTRFS verwendet wird, ist mir ein Rätsel.
Lg

[MSfree]

Was mich bei der Kernel-Panic ebenfalls stutzig macht, ist diese Fehlermeldung: fuseblk: Unknown parameter 'subvol'

https://forums.gentoo.org/viewtopic-p-8 ... 4f6865643d

Es sieht so aus, als hätte er mit dem BTRFS ein Problem.

Wie alt ist denn das btrfs auf dem fraglichen Rechner? btrfs entwickelt sich ständig weiter und es kann durchaus sein, daß ein neuer Kernel mit einem alten btrfs zu Problemen führt.

Obwohl, ich habe vor kurzem ein Debian Buster, das auf btrfs installiert ist, über Bullseye auf Bookworm hochgezogen, ohne dabei Probleme zu haben. Das Dateisystem besteht also schon seit ca. 5 Jahren. btrfs habe ich damals auch nur deshalb genommen, weil es das einzige Dateisystem in Debian ist, das transparent komprimieren kann und die SSD in dem fraglichen Rechner nur 4GB winzig ist. Dank Kompression paßt Debian dann auf etwa 1.3GB. (Der Rechner ist jetzt 16 Jahre alt)

[thunder11]

Code: Alles auswählen

Found linux image: /boot/vmlinuz-6.9.12-amd64
Found initrd image: /boot/initrd.img-6.9.12-amd64
Found linux image: /boot/vmlinuz-6.9.7-amd64
Found initrd image: /boot/initrd.img-6.9.7-amd64

Das ist aber ein Uralt Kernel von Trixie
Z.Z, ist 6.10.4. aktuell
Bitte mal

Code: Alles auswählen

ls -al /boot

Irgendwas auf Hold gesetzt ?
upgrade oder full-upgrade durchgeführt ?

[tabletennisskisrugby]

Hallo Leute!
Ich habe heute wieder ein Update versucht, ohne Erfolg.


Um eure Fragen zu beantworten:
Nach dem Update sind die Files "initrd.img-*" um einiges größer.

Code: Alles auswählen

# Vor dem Update
ls -la /boot
insgesamt 87477
drwxr-xr-x 1 root root      176 12. Jul 12:09 .
drwxr-xr-x 1 root root      248  5. Jul 13:37 ..
-rw-r--r-- 1 root root   275522 27. Jun 20:37 config-6.9.7-amd64
drwx------ 3 root root      512  1. Jän 1970  efi
drwxr-xr-x 1 root root      108  5. Jul 13:37 grub
-rw-r--r-- 1 root root 79671756 12. Jul 12:09 initrd.img-6.9.7-amd64
-rw-r--r-- 1 root root       83 27. Jun 20:37 System.map-6.9.7-amd64
-rw-r--r-- 1 root root  9615296 27. Jun 20:37 vmlinuz-6.9.7-amd64
# Nach dem Update
ls -la /boot
insgesamt 519717
drwxr-xr-x 1 root root       346 23. Aug 09:50 .
drwxr-xr-x 1 root root       248 23. Aug 09:47 ..
-rw-r--r-- 1 root root    276641 12. Aug 20:18 config-6.10.4-amd64
-rw-r--r-- 1 root root    275522 27. Jun 20:37 config-6.9.7-amd64
drwx------ 3 root root       512  1. Jän 1970  efi
drwxr-xr-x 1 root root       108 23. Aug 09:49 grub
-rw-r--r-- 1 root root 256329886 23. Aug 09:50 initrd.img-6.10.4-amd64
-rw-r--r-- 1 root root 255977033 23. Aug 09:48 initrd.img-6.9.7-amd64
-rw-r--r-- 1 root root        83 12. Aug 20:18 System.map-6.10.4-amd64
-rw-r--r-- 1 root root        83 27. Jun 20:37 System.map-6.9.7-amd64
-rw-r--r-- 1 root root   9693120 12. Aug 20:18 vmlinuz-6.10.4-amd64
-rw-r--r-- 1 root root   9615296 27. Jun 20:37 vmlinuz-6.9.7-amd64

"rootfstype=btrfs" habe ich in /etc/default/grub eingetragen. Die Fehlermeldung mit dem "subvol" ist verschwunden.

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="quiet rootfstype=btrfs"

Hier ist die Version des BTRFS-Dateisystems:

Code: Alles auswählen

 dpkg -l | grep btrfs
ii  btrfs-progs                           6.6.3-1.2+b1                                            amd64        Checksumming Copy on Write Filesystem utilities

So sieht mein Updateaufruf aus:

Code: Alles auswählen

apt update && apt --solver 3.0 full-upgrade && apt autoremove && apt clean

Und "apt-mark showhold" zeigt keine Pakete, die auf Hold stehen würden.

Gebt mir bitte Bescheid, wenn ihr noch mehr Infos benötigt, bzw. wenn euch noch etwas einfällt.
Vielen Dank im Voraus.
LG Martin

[MSfree]

Hallo Leute!
Ich habe heute wieder ein Update versucht, ohne Erfolg.

Dann schau mal in die erste Zeile deines Screenshots. Deine initrd ist kaputt!
Dann kann das natürlich nicht funktionieren.

[tabletennisskisrugby]

Ich weiß, es sieht so aus, aber warum fährt dann dasselbe Linux-System, wenn ich es auf einen USB-Stick spiele, auf einem anderen Computer ohne Probleme hoch, nur auf diesem alten PC nicht und es macht auch nur dann Probleme, wenn BTRFS verwendet wird?
Wenn es nur an der "initrd" liegen würde, dürfte der Hochlauf auch auf keinem anderen PC funktionieren und dies unabhängig vom verwendeten Dateisytem.
LG

[MSfree]

Ich weiß, es sieht so aus, aber warum fährt dann dasselbe Linux-System, wenn ich es auf einen USB-Stick spiele,

Weil dort eine andere, neu erzeugete und intakte initrd verwendet wird.

Wenn es nur an der "initrd" liegen würde, dürfte der Hochlauf auch auf keinem anderen PC funktionieren und dies unabhängig vom verwendeten Dateisytem.

Die initrd wird doch für jeden Computer individuell erzeugt. Woher weißt du, daß dieselbe initrd verwendet wird?

[thunder11]

Bootet den der alte Kernel noch (6.9.7-amd64) oder beide nicht mehr?

wenn Kernel 6.9.7-amd64 noch funktioniert, würde ich mit dem funktionierenden Kernel in den Rettungsmodus booten
und dann

Code: Alles auswählen

update-initramfs -c -k 6.10.4-amd64

versuchen

[tabletennisskisrugby]

Die initrd wird doch für jeden Computer individuell erzeugt. Woher weißt du, daß dieselbe initrd verwendet wird?

Weil ich das System auch auf einen USB-Stick gespielt habe und versucht habe zu booten. Wenn ich vom alten Computer hochfahre, habe ich eine Kernel-Panic, wenn ich den USB-Stick abziehe und von einem anderen Computer hochfahre, funktioniert der Hochlauf.

wenn Kernel 6.9.7-amd64 noch funktioniert, würde ich mit dem funktionierenden Kernel in den Rettungsmodus booten
und dann

Ich habe heute das Linux-Sytem auf der internen Sata-Platte des Computer upgedatet, dabei wurden "initrd.img-6.9.7-amd64" und "initrd.img-6.10.6-amd64" neu geschrieben. Danach konnte ich von beiden Kernels nicht mehr booten.
Allerdings habe ich jetzt etwas ganz Freches gemacht, nämlich die "initrd.img-6.9.7-amd64" vom zuvor laufenden System in das Kernel-Panic-System hineinkopiert und plötzlich konnte ich vom 6.9.7 booten.
Ich habe dann, wie empfohlen, folgenden Befehl erfolgreich ausgeführt.

Code: Alles auswählen

update-initramfs -c -k 6.10.6-amd64

Danach erschien die Kernel-Panic beim "6.10.6" beim Starten immer noch.

LG

[thunder11]

Ich habe dann, wie empfohlen, folgenden Befehl erfolgreich ausgeführt.

Code: Alles auswählen

update-initramfs -c -k 6.10.6-amd64

Danach erschien die Kernel-Panic beim "6.10.6" beim Starten immer noch.

Wo kommt denn Kernel 6.10.6-amd64 her ? Ich sehe ihn nicht bei deine bisherigen Ausführungen

# Nach dem Update

Code: Alles auswählen

ls -la /boot
insgesamt 519717
drwxr-xr-x 1 root root       346 23. Aug 09:50 .
drwxr-xr-x 1 root root       248 23. Aug 09:47 ..
-rw-r--r-- 1 root root    276641 12. Aug 20:18 config-6.10.4-amd64
-rw-r--r-- 1 root root    275522 27. Jun 20:37 config-6.9.7-amd64
drwx------ 3 root root       512  1. Jän 1970  efi
drwxr-xr-x 1 root root       108 23. Aug 09:49 grub
-rw-r--r-- 1 root root 256329886 23. Aug 09:50 initrd.img-6.10.4-amd64
-rw-r--r-- 1 root root 255977033 23. Aug 09:48 initrd.img-6.9.7-amd64
-rw-r--r-- 1 root root        83 12. Aug 20:18 System.map-6.10.4-amd64
-rw-r--r-- 1 root root        83 27. Jun 20:37 System.map-6.9.7-amd64
-rw-r--r-- 1 root root   9693120 12. Aug 20:18 vmlinuz-6.10.4-amd64
-rw-r--r-- 1 root root   9615296 27. Jun 20:37 vmlinuz-6.9.7-amd64

[tabletennisskisrugby]

Ich versuche das Sytem upzudaten. Wenn dies fehlschlägt, lade ich das alte Backup mit Kernel "6.9.7" zurück, damit ich damit wieder arbeiten kann.
Nach gut einer Woche versuche ich wieder ein Update und dann wird automatisch der neueste Kernel installiert.
Dadurch entsteht die Abweichung von 6.10.4, 6.10.6 usw.

[thunder11]

Hast du eine separate Boot-Partition ?
Wenn ja wie viel Paltz ist da noch

Code: Alles auswählen

lsblk -f

oder

Code: Alles auswählen

df -h|grep -v ^tmpfs

[MSfree]

Weil ich das System auch auf einen USB-Stick gespielt habe und versucht habe zu booten. Wenn ich vom alten Computer hochfahre, habe ich eine Kernel-Panic, wenn ich den USB-Stick abziehe und von einem anderen Computer hochfahre, funktioniert der Hochlauf.

Das ist eines der Probleme, wenn man Debian auf einem USB-Stick installiert. Es ist eben nicht garantiert, daß der Stick portabel ist und auf jedem beliebigen Rechner bootet.

Die Meldung in deinem Screenschot:

Code: Alles auswählen

Unable to mount root fs on unknown block (0,0)

deutet jedenfalls darauf hin, daß die Block-Devices deiner beiden Rechner sich nicht identisch durchnummerieren.

[tabletennisskisrugby]

Hallo Leute!
Um es vorweg zu nehmen, ich habe das Problem gelöst, aber ich hätte es ohne eure Hilfe nicht geschafft. Vielen Dank dafür.
Ich beziehe mich nun auf den 12 Jahre alten PC mit interner Sata, also kein USB-Stick mehr oder ein anderer Rechner.

Um zu Beginn eure Fragen zu beantworten:
Ich habe eine FAT32-Efi-Partition mit 100MB und eine 1TB Partition mit btrfs, mit dem Subvolume @root und @daten.

Code: Alles auswählen

root@c1:/home# lsblk -f
NAME   FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                              
├─sda1 vfat   FAT32 SYS_UEFI B0D2-C566                              94,1M     4% /boot/efi
└─sda2 btrfs        SYS_Root c72e4c96-fa78-4bf9-b310-58b17708b34c  514,8G    46% /media/daten
                                                                                 /
sr0                                                                              

Code: Alles auswählen

root@c1:/home# blkid -o list
device                                     fs_type         label            mount point                                    UUID
---------------------------------------------------------------------------------------------------------------------------------------------------------------
/dev/sda2                                  btrfs           SYS_Root         (in use)                                       c72e4c96-fa78-4bf9-b310-58b17708b34c
/dev/sda1                                  vfat            SYS_UEFI         /boot/efi                                      B0D2-C566

Code: Alles auswählen

root@c1:/home# mount
..
/dev/sda2 on / type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=256,subvol=/@root)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda2 on /media/daten type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=257,subvol=/@daten)
..

Code: Alles auswählen

root@c1:/home# df -h | grep -v ^tmpfs
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            7,7G       0  7,7G    0% /dev
/dev/sda2       954G    438G  515G   46% /
efivarfs        320K     11K  305K    4% /sys/firmware/efi/efivars
/dev/sda2       954G    438G  515G   46% /media/daten
/dev/sda1        99M    4,3M   95M    5% /boot/efi

Lösung:
Da es so aussieht, als wäre die Datei "initrd.img-6.10.6-amd64" defekt, dachte ich mir, ich versuche es mit einer anderen Kompression.
Dazu habe ich die Datei "/etc/initramfs-tools/initramfs.conf" vor dem Update umgeändert und den Eintrag auf "COMPRESS=xz" gestellt.
Das System fährt jetzt ohne Probleme hoch. Sobald ich jedoch den Eintrag auf "COMPRESS=zstd" zurückstelle und die Datei "initrd.img-6.10.6-amd64" neu schreibe und neu starte, bekomme ich wieder die Kernel-Panic.
Warum "zstd" plötzlich nicht mehr funktioniert, ist mir ein Rätsel, vielleicht habt ihr eine Erklärung dafür, denn ich gehe den Sachen gerne auf den Grund.
Die Hauptsache ist jedoch, dass es jetzt funktioniert.

Ich wünsche euch ein schönes Wochenende.
LG

[user8111]

Warum "zstd" plötzlich nicht mehr funktioniert, ist mir ein Rätsel, vielleicht habt ihr eine Erklärung dafür, denn ich gehe den Sachen gerne auf den Grund.

Ich vermute, dass das zstd-Packet beim Update aus irgemdeinem Grund gelöscht wurde. Es ist ja nicht Teil der Standard-Debian Installation.

Mach doch mal apt install zstd und schaue, ob das der Fall ist.

[MSfree]

Ich vermute, dass das zstd-Packet beim Update aus irgemdeinem Grund gelöscht wurde.

In dem Fall gibt es vom mkinitramfs eine Warnung, daß zstd nicht gefunden wurde und stattdessen gzip verwendet wird.

[Sandersbeek]

Hallo,

ich habe ein ähnliches Problem aber bin mit Deb12 und den Backports unterwegs (Meine Laufwerke sind alle auf EXT4).

Nach dem Kernel Update hab ich beim Starten des Laptops auch eine Kernel-Panic, kann aber über das Grub-Menü mit dem Kernel davor (x86_64 Linux 6.9.10+bpo-amd64) Starten und Normal Arbeiten.

Ich halte mein System auch stets Aktuell also mach ich jeden Tag nach dem Starten ein Update (sudo apt update && sudo apt full-upgrade -y)

Was mir aufgefallen ist das der neue Kernel nicht Konfiguriert werden kann (wird nach jedem full-upgrade erneut versucht). Ich warte nun ob es irgendwann mal gefixt wird, so lang nehm ich noch den 6.9.10 Kernel.

Vielleicht Hilft mein Verlauf eine Lösung für den Thread Ersteller zu finden:

Code: Alles auswählen

Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  linux-headers-6.9.7+bpo-common linux-kbuild-6.9.7+bpo
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
linux-image-6.10.6+bpo-amd64 (6.10.6-1~bpo12+1) wird eingerichtet ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.10.6+bpo-amd64.
Sign command: /lib/modules/6.10.6+bpo-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j16 modules KERNEL_UNAME=6.10.6+bpo-amd64................(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.10.6+bpo-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/535.183.01/build/make.log for more information.
Sign command: /lib/modules/6.10.6+bpo-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
applying patch cc_version_check-gcc5.patch...patching file conftest.sh

applying patch bashisms.patch...patching file conftest.sh

applying patch 0001-some-power-management-features-were-not-yet-in-Linux.patch...patching file conftest.sh

applying patch 0033-refuse-to-load-legacy-module-if-IBT-is-enabled.patch...patching file nvidia-modeset/nvidia-modeset-linux.c
patching file nvidia/nv.c

applying patch 0034-fix-typos.patch...patching file nvidia-uvm/uvm.h
patching file nvidia-uvm/uvm_perf_thrashing.c
patching file nvidia/nv.c

applying patch fragile-ARCH.patch...patching file Makefile

applying patch conftest-verbose.patch...patching file Kbuild

applying patch use-kbuild-compiler.patch...patching file Makefile
patching file Kbuild

applying patch use-kbuild-flags.patch...patching file Kbuild
patching file nvidia/nvidia.Kbuild
patching file Makefile
patching file nvidia-modeset/nvidia-modeset.Kbuild

applying patch conftest-prefer-arch-headers.patch...patching file conftest.sh


Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j16 modules KERNEL_UNAME=6.10.6+bpo-amd64........(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.10.6+bpo-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-tesla-470/470.256.02/build/make.log for more information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.10.6+bpo-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: Fehler beim Bearbeiten des Paketes linux-image-6.10.6+bpo-amd64 (--configure):
 »installiertes post-installation-Skript des Paketes linux-image-6.10.6+bpo-amd64«-Unterprozess gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-image-amd64:
 linux-image-amd64 hängt ab von linux-image-6.10.6+bpo-amd64 (= 6.10.6-1~bpo12+1); aber:
  Paket linux-image-6.10.6+bpo-amd64 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes linux-image-amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-headers-6.10.6+bpo-amd64:
 linux-headers-6.10.6+bpo-amd64 hängt ab von linux-image-6.10.6+bpo-amd64 (= 6.10.6-1~bpo12+1) | linux-image-6.10.6+bpo-amd64-unsigned (= 6.10.6-1~bpo12+1); aber:
  Paket linux-image-6.10.6+bpo-amd64 ist noch nicht konfiguriert.
  Paket linux-image-6.10.6+bpo-amd64-unsigned ist nicht installiert.

dpkg: Fehler beim Bearbeiten des Paketes linux-headers-6.10.6+bpo-amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-headers-amd64:
 linux-headers-amd64 hängt ab von linux-headers-6.10.6+bpo-amd64 (= 6.10.6-1~bpo12+1); aber:
  Paket linux-headers-6.10.6+bpo-amd64 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes linux-headers-amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
 linux-image-6.10.6+bpo-amd64
 linux-image-amd64
 linux-headers-6.10.6+bpo-amd64
 linux-headers-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

[user8111]

Was mir aufgefallen ist das der neue Kernel nicht Konfiguriert werden kann (wird nach jedem full-upgrade erneut versucht). Ich warte nun ob es irgendwann mal gefixt wird, so lang nehm ich noch den 6.9.10 Kernel.

Das liegt an dem veralteten Nvidia-Treiber den du installiert hast, der ist nicht mit Kernel 6.10 kompatibel und wird es auch nie sein. Bis sich da was ändert werden Monate vergehen, da selbst der nächste etwas neuere Treiber in den Debian-Quellen, der widerrum seit Monaten in experimental ist, ebenfalls nicht kompatibel ist.

Daher hier eine Anleitung für das Update über das Nvidia-APT Respository:
https://linuxcapable.com/de/installiere ... uf-debian/

Abschnitt "Methode 2: Installieren Sie Nvidia-Treiber über PPA"

Sofern du Wayland verwendest, lohnt sich der neuere Treiber sowieso, da er zB. die Kompatibilität der Browser-HW-Videobeschleunigung erheblich verbessert etc.