[Erledigt] Nach bookworm-trixie-upgrade: "LABEL_RASPIROOT does not exist"

[buhtz]

Ich benötige mal Hilfe bei der Diagnose. Und es sind wohl zwei Probleme, die sich evtl. bedingen.
Habe auch schon eine Idee, was die Ursache ist, aber weiß nicht, wie ich damit umgehen soll.

Ich habe Debian 12 (bookworm) von raspi.debian.org auf einem RaspberryPi 4 (headless) laufen.
Habe dann ein upgrade auf trixie gemacht. Während apt mit dem Kernel oder einer seiner Komponenten beschäftigt war, gab es eine Fehlermeldung (log siehe später). Die hat vermutlich damit zu tun, dass ich vor Jahren für eine USB-WLAN-Antenne einen eigenen Treiber/Modul (rtl8821cu; Quelle müsste die hier gewesen sein: https://github.com/morrownr/8821cu-20210916; dazugehöriger Debian Forum Thread) gebaut hatte. Habe nicht mehr daran gedacht und hätte ihn vermutlich vor dem Upgrade irgendwie entfernen sollen?

Das booten funktioniert jetzt nicht mehr und gibt mir eine unerwartete Meldung, die ich derart interpretiere, dass eine Partition nicht auffindbar ist.

Code: Alles auswählen

ALERT! LABEL=RASPIROOT does not exist. Dropping to a shell!

Der Fehler, der vor dem Booten beim Trixie upgrade auflief sieht so aus.

Code: Alles auswählen

epmod.....
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.0-27-arm64
/etc/kernel/postrm.d/z50-raspi-firmware:
raspi-firmware: deleting obsolete /boot/firmware/vmlinuz-6.1.0-27-arm64 (no longer in /boot)
raspi-firmware: deleting obsolete /boot/firmware/initrd.img-6.1.0-27-arm64 (no longer in /boot)
linux-image-6.11.10-arm64 (6.11.10-1) wird eingerichtet ...
I: /initrd.img is now a symlink to boot/initrd.img-6.11.10-arm64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.11.10-arm64.
Sign command: /lib/modules/6.11.10-arm64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
Building module(s).......................................(bad exit status: 2)
Failed command:
./dkms-make.sh
Error! Bad return status for module build on kernel: 6.11.10-arm64 (aarch64)
Consult /var/lib/dkms/rtl8821cu/5.12.0.4/build/make.log for more information.
dkms autoinstall on 6.11.10-arm64/aarch64 failed for rtl8821cu(10)
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.11.10-arm64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: Fehler beim Bearbeiten des Paketes linux-image-6.11.10-arm64 (--configure):
 »installiertes post-installation-Skript des Paketes linux-image-6.11.10-arm64«-Unterprozess gab den Fehlerwert 11 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-image-arm64:
 linux-image-arm64 hängt ab von linux-image-6.11.10-arm64 (= 6.11.10-1); aber:
  Paket linux-image-6.11.10-arm64 ist noch nicht konfiguriert.

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

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

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

Ich weiß nicht mal, wie ich jetzt auf eine shell komme. Vermutlich kann ich irgendeine Zauberdatei auf der SD-Karte vom Pi an einer anderen Maschine editieren?
Hätte ich den WLAN Treiber vorher entfernen sollen? Oder gäbe es eine andere Möglichkeit so etwas vorzubeugen?

Habe aktuell keinen zweiten Linux Rechner zur Hand. Auf meinem Windows 10 bin ich kein Admin und habe daher auch kein WSL.
Wenn ich die SD-Karte in einen Windows 10 Rechner stecke, tauchen 2 Partitionen auf. Eine "RASPIFIRM" und lesbar. Die zweite hat kein Label und erscheint auch als nicht-formatiert (unter Windows 10). Auf die Datei /var/lib/dkms/rtl8821cu/5.12.0.4/build/make.log habe ich keinen Zugriff, da die scheinbar auf der zweiten Partition liegt.

[MSfree]

Das booten funktioniert jetzt nicht mehr und gibt mir eine unerwartete Meldung, die ich derart interpretiere, dass eine Partition nicht auffindbar ist.

Ohne Linuxrechner wirst du da nicht weiter kommen.

Wenn die Partition allerdings kaputt ist, wird eine Rettung des System schwierig.

Wenn ich die SD-Karte in einen Windows 10 Rechner stecke, tauchen 2 Partitionen auf. Eine "RASPIFIRM" und lesbar. Die zweite hat kein Label und erscheint auch als nicht-formatiert (unter Windows 10).

Die lesbare Partition hat ein VFAT Dateisystem, die ist also unter windows lesbar. Mit Linuxpartitionen kennt sich Windows aber nicht aus und du solltest das auch auf gar keinen Fall versuchen, mit Windows irgendwie hinzubiegen.

Ich sehe als Ursache aber nicht dein Kernelmodul. Das bauen mit DKMS ändert nämlich keine Partitions-IDs. Gut möglich, daß beim Update deine SD-Karte kaputt gegangen ist.

[buhtz]

Danke für deine Antwort.

Ich sehe als Ursache aber nicht dein Kernelmodul. Das bauen mit DKMS ändert nämlich keine Partitions-IDs. Gut möglich, daß beim Update deine SD-Karte kaputt gegangen ist.

OK, das ist doch schon mal ein guter Hinweis, dass es hier scheinbar keinen Zusammenhang gibt.

Mir viel vorhin noch ein, dass ich letzte Nacht vor dem Upgrade natürlich noch ein dd-Image der Karte gemacht habe. Ich könnte es also zurückspielen.

Aber woher weiß ich, ob die Karte in Ordnung ist? Gibt es so eine Art check-disc für SD Karten, mit der ich wirklich jede Zelle testen kann?

[debianoli]

Nimm einfach eine neue SD-Karte und gut ist es. Mehr Aufwand würde ich nicht reinstecken.

Die höchstwahrscheinlich kaputte Karte würde ich neu Partitonieren und Formatieren. Dann sieht man beim Schreiben von Daten, ob die SD-Karte kaputt ist. Nach meiner Erfahrung ist deine abgeraucht, SD-Karten sind nicht besonders robust. Ausnahmen bestätigen die Regel

[MSfree]

Ich würde erstmal schauen, ob du die SD-Karte in einem Linuxrechner normal mounten kannst.

Daß das Ding nicht bootet, ist erstmal normal, das Bauen der initrd ist schließlich fehlgeschlagen. Ich weiß im Moment aber nicht, ob dieses Raspi-Debian sowas wie einen Bootmanager ala grub hat, mit dem man einen älteren Kernel booten kann, der vorherige wird ja noch auf der SD-Karte sein.

[towo]

Nein, auf einem Raspi gibts keinen Grub und deshalb kann man da auch nicht so einfach Kernel über apt installieren oder benutzen.

[MSfree]

Nein, auf einem Raspi gibts keinen Grub

Doch, siehe hier:
viewtopic.php?t=175920

Nachträglich hilft das allerdings wenig.

[buhtz]

OK, sitze jetzt wieder an einem Debian GNU/Linux 12 und habe die SD-Karte via USB-Adapter eingesteckt.
Beide Partitionen werden incl. Label erkannt. Mhm... Interessant ist die letzte Ausgabe von e2label. Könnte das ein Hinweis sein?

Code: Alles auswählen

$ lsblk -o name,mountpoint,label,size,uuid /dev/sdc
NAME   MOUNTPOINT            LABEL      SIZE UUID
sdc                                    59,5G 
├─sdc1 /media/user/RASPIFIRM RASPIFIRM  508M B62D-E64A
└─sdc2 /media/user/RASPIROOT RASPIROOT   59G 23a77be8-5e7d-4310-bb98-edd61ca33a1e

$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 59,48 GiB, 63864569856 bytes, 124735488 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7d9c1e48

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sdc1          8192   1048575   1040384  508M  c W95 FAT32 (LBA)
/dev/sdc2       1048576 124735487 123686912   59G 83 Linux


$ sudo e2label /dev/sdc
e2label: Bad magic number in super-block while trying to open /dev/sdc
Found a dos partition table in /dev/sdc

Ich kann sie mit dem Dateimanager von xfce (Thunar?) auch beide problemlos öffnen.

[MSfree]

´Interessant ist die letzte Ausgabe von e2label. Könnte das ein Hinweis sein?

Code: Alles auswählen

$ sudo e2label /dev/sdc
e2label: Bad magic number in super-block while trying to open /dev/sdc

Nein, e2label braucht die Angabe einer Partition, nicht des raw Devices. Du hast also e2label falsch benutzt.

Code: Alles auswählen

e2label /dev/sdc2

sollte die korrekte Ausgabe produzieren.

[buhtz]

Danke.

Code: Alles auswählen

$ sudo e2label /dev/sdc1
e2label: Bad magic number in super-block while trying to open /dev/sdc1
/dev/sdc1 contains a vfat file system labelled 'RASPIFIRM'

$ sudo e2label /dev/sdc2
RASPIROOT

EDIT: Mhm... Das Bootproblem bleibt bestehen. Bin nicht sicher, was ich jetzt tun soll. Einfach mal das Backup Image zurück spielen, dann den WLAN Treiber deinstallieren und ein neues Upgrade machen?

EDIT2: Das build log in T/var/lib/dkms/rtl8821cu/5.12.0.4/build/ sieht nicht sehr überraschend aus. Die Sourcen sind halt veraltet und kommen vermutlich mit dem neuen Kernel noch nicht klar.

Code: Alles auswählen

DKMS make.log for rtl8821cu-5.12.0.4 for kernel 6.11.10-arm64 (aarch64)
Di 3. Dez 08:00:07 CET 2024
make ARCH=arm64 CROSS_COMPILE= -C /lib/modules/6.11.10-arm64/build M=/var/lib/dkms/rtl8821cu/5.12.0.4/build  modules
make[1]: Verzeichnis „/usr/src/linux-headers-6.11.10-arm64“ wird betreten
  CC [M]  /var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_cmd.o
  CC [M]  /var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_security.o
  CC [M]  /var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_debug.o
  CC [M]  /var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_io.o
In file included from /var/lib/dkms/rtl8821cu/5.12.0.4/build/include/drv_types.h:114,
                 from /var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_cmd.c:17:
/var/lib/dkms/rtl8821cu/5.12.0.4/build/include/rtw_mlme_ext.h:1171:4: warning: no previous prototype for ‘rtw_mesh_set_plink_state_cmd_hdl’ [-Wmissing-prototypes]
 1171 | u8 rtw_mesh_set_plink_state_cmd_hdl(_adapter *adapter, u8 *parmbuf) { return H2C_CMD_FAIL; };
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_cmd.c:1634:6: warning: no previous prototype for ‘free_assoc_resources_hdl’ [-Wmissing-prototypes]
 1634 | void free_assoc_resources_hdl(_adapter *padapter, u8 lock_scanned_queue)
      |      ^~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/rtl8821cu/5.12.0.4/build/core/rtw_cmd.c:2212:4: warning: no previous prototype for ‘rtw_ssmps_wk_hdl’ [-Wmissing-prototypes]
 2212 | u8 rtw_ssmps_wk_hdl(_adapter *adapter, struct ssmps_cmd_parm *ssmp_param)
      |    ^~~~~~~~~~~~~~~~
      
....SNIPPED...


make[3]: *** [/usr/src/linux-headers-6.11.10-common/scripts/Makefile.build:249: /var/lib/dkms/rtl8821cu/5.12.0.4/build/os_dep/linux/usb_intf.o] Fehler 1
/var/lib/dkms/rtl8821cu/5.12.0.4/build/os_dep/linux/usb_ops_linux.c:730:6: warning: no previous prototype for ‘usb_init_recvbuf’ [-Wmissing-prototypes]
  730 | void usb_init_recvbuf(_adapter *padapter, struct recv_buf *precvbuf)
      |      ^~~~~~~~~~~~~~~~
In file included from /var/lib/dkms/rtl8821cu/5.12.0.4/build/include/usb_ops.h:34,
                 from /var/lib/dkms/rtl8821cu/5.12.0.4/build/include/drv_types.h:2027,
                 from /var/lib/dkms/rtl8821cu/5.12.0.4/build/os_dep/linux/usb_ops_linux.c:17:
/var/lib/dkms/rtl8821cu/5.12.0.4/build/include/usb_ops_linux.h:43:49: warning: no previous prototype for ‘usb_read_port_complete’ [-Wmissing-prototypes]
   43 | #define usb_read_port_complete(purb, regs)      usb_read_port_complete(purb)
      |                                                 ^~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/rtl8821cu/5.12.0.4/build/os_dep/linux/usb_ops_linux.c:964:6: note: in expansion of macro ‘usb_read_port_complete’
  964 | void usb_read_port_complete(struct urb *purb, struct pt_regs *regs)
      |      ^~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [/usr/src/linux-headers-6.11.10-common/Makefile:1951: /var/lib/dkms/rtl8821cu/5.12.0.4/build] Fehler 2
make[1]: *** [/usr/src/linux-headers-6.11.10-common/Makefile:236: __sub-make] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-6.11.10-arm64“ wird verlassen
make: *** [Makefile:2501: modules] Fehler 2

[MSfree]

Das sieht doch ganz gut aus.

Mittlerweile habe ich hier mal meinen Raspi 4 mit Debian Bookworm gebootet. Im Verzeichnis /boot/firmware liegt bei mir eine Datei namens config.txt mit dem Inhalt (Kommentare enfernt):

Code: Alles auswählen

arm_64bit=1
enable_uart=1
upstream_kernel=1
kernel=vmlinuz-6.1.0-28-arm64
initramfs initrd.img-6.1.0-28-arm64

/boot ist die erste Partition (die VFAT Partition) deiner SD-Karte. Dort sollte das Unterverzeichnis firmware existieren und da liegt diese config.txt.

Ich würde da frech mal den alten Kernel und die alte initrd eintragen, die Karte in den Raspi setzen und versuchen damit zu booten.

[buhtz]

Hab das Image gelöscht (in Thunar per Shift+Entf Taste). Kein Backup vom Backup.

OK, ich probier das mit dem Kernel. Aktuell läuft sudo badblocks -s -n /dev/sdc noch durch...

[MSfree]

Es ist wirklich so, daß die eingetragenen Kernel und initrd in der config.txt die sind, die gebootet werden. Ich habe das gerade mit meiner config.txt ausprobiert und die vorherigen Kernel/initrd eingetragen. Nach dem Reboot war der eingetragene Kernel gebootet. Das gleiche dann mit dem neuen Kernel.

Es besteht also Hoffnung, deine Kiste mit dem alten Kernel zu booten, dann DKMS zu deinstallieren und danach den neuesten Kernel nochmal zu reinstallieren.

[buhtz]

Puh... So ein blödes Projekt. Riecht alles nach Neuinstallation.

Also badblocks hatte keine Beschwerden. Alles gut.

Hab den Kernel in der config.txt umgestellt, auf jenen welchen, den ich auf der Partition gefunden habe.

Jetzt bleibt der Bildschirm einfach schwarz. Ich sehe nicht einmal den bunten Pi-Startbildschirm.

[MSfree]

Puh... So ein blödes Projekt. Riecht alles nach Neuinstallation.

Du könntest zumindest auf einer zweiten SD-Karte ein provisorisches Debian installieren. Die nicht bootende SD-Karte hängst du dann via Cardreader an einen USB-Anschluß. Die zweite Partition der SD-Karte im Carderader mountest du dann manuell als root z.B. nach /mnt und die erste mountest du anschließend auf /mnt/boot. (sollte die SD-Karte automatisch gemountet werden, mußt du sie natürlich unmounten).

Danach kannst du mit chroot auf /mnt wechseln und versuchen, das Desaster zu richten, z.B. durch Deinstallation von DKMS und Reinstallation des Linuxkernels.

[buhtz]

Chroot und Kernel traue ich mich nicht. Verstehe chroot nicht und mache es wahrscheinlich nur kaputt. In meiner Situation ist der Windows-Move (Neuinstallation) vermutlich das zeitsparendste, zumal die Ursache weiterhin nicht klar ist.

Mich irritiert, dass ich beim Pi jetzt nicht mal mehr den bunten Startbildschirm sehe; auf keinem der beiden HDMI Ports.

EDIT: Es gibt auf raspi.debian.net/tested-images nur ein (scheinbar problembehaftetes) Image für den p400. Und nach ein wenig rum-googlen, habe ich die Vermutung, dass so ein Upgrade von 12 auf 13 aus irgendwelchen Pi-Gründen wohl gar nicht möglich ist. Bin da aber nicht sicher.

[buhtz]

Es scheint (irgendwie) doch zu gehen.

Hab jetzt ein frisches Debian 12 Image von raspi.debian.net geflashed und installiert. Und dann sofort ein Upgrade nach Trixie gemacht. Bootet.
Habe auch schon xfce, xrdp, ssh und co installiert. Geht auch.

Aber ganz rund oder Fehlerfrei scheint es nicht zu sein.

Maus und Tastatur werden am Pi, nach dem Upgrade auf Trixie, nicht erkannt bzw. reagieren nicht. Ich kann die Maschine nur per SSH/RDP bedienen, aber habe eh nix anderes vor.

Ich lasse das jetzt so laufen und versuche bis zum Trixie release zu überleben.

Nebenbei bemerkt, von DietPi gibt es auch schon alpha/beta Trixie images.

https://dietpi.com/downloads/images/