Die einfachste Methode Bootprobleme zu identifizieren ist einen Monitor an die Raspberry anzuschliessen und die Meldungen auf dem Bildschirm zu lesen.
Hat man aber keinen Monitor zur Hand oder betreibt die Raspberry bewusst als headless System - also ohne Monitor - da die Raspberry als Server betrieben wird und deshalb kein Monitor notwendig ist und hat plötzlich Bootprobleme, gibt es einen Weg, die Bootprobleme auch ohne angeschlossenen Monitor zu analysieren.
Erforderlich dazu ist ein Linuxsystem mit angeschlossenem Monitor als Analysesystem. Mit einem Linux USB ISO Bootimage kann auch ein Windowsrechner temporär mit einem Linux booten und dazu genutzt werden. Natürlich geht das auch mit einer weiteren Raspberry mit RaspbianOS. Das Systemgerät, welches das OS mit der Rootpartition enthält (z.B. die SD Karte oder die SSD) wird dann auf dem Analysesystem angeschlossen und auf das Systemlog zugegriffen und gelesen.
Zuallererst muss das Systemgerät an dem Analysesystem angeschlossen werden. Mit lsblk zeigt sich was angeschlossen ist.
pi@raspberrypi-trixie64-lite:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 2G 0 loop
sda 8:0 0 3,6T 0 disk
├─sda1 8:1 0 512M 0 part
└─sda2 8:6 0 32G 0 part
mmcblk0 179:0 0 7,4G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 6,9G 0 part /
zram0 254:0 0 2G 0 disk [SWAP]In diesem Falle wurde von einer SD Karte /dev/mmcblk0 gebootet und /dev/sda ist die USB Platte von dem System, welches nicht mehr bootet. Die USB Platte wird nun an /mnt read only gemounted. Exisitiert dieser Mountpoint nicht ist er mit sudo mkdir -p /mnt erst einmal zu erstellen und dann mit sudo mount -o ro /dev/sda2 /mnt zu mounten.
Falls automount aktiv ist und /dev/sda2 deshalb schon automatisch gemounted wurde muss die Rootpartition vorher mit sudo umount /dev/sda2 erst einmal umounted werden. Das ist ersichtlich wenn die Zeile mit /dev/sda2 in der obigen Ausgabe irgendwas. z.B. /media/pi/ stehen hat.
Danach ist zu prüfen ob ein Journal existiert mit ls /mnt/var/log/journal/. Ist dieses Verzeichnis leer oder existiert es nicht sind folgende Aktionen notwendig:
- Mit sudo mount -o remount,rw /dev/sda2 die Rootpartition am Analysesystem zum Schreiben mounten
- Erstellen des Verzeichnisses mit sudo mkdir -p /mnt/var/log/journal
- Änderung der Zeile Storage= in /mnt/etc/systemd/journal.conf auf Storage=auto falls es dort noch nicht so steht. Falls ein * am Anfang der Zeile steht ist dieser zu entfernen.
- Mit sudo umount /mnt die Rootpartition am Analysesystem logisch entfernen
- Anschließen des Systemgeräts wieder an die nicht bootende Raspberry und booten, so dass alle Bootmeldungen von systemd in /var/log/journal gelogged werden
- Wiederanschliessen des Systemgerätes an das Analysesystem
raspi-config erlaubt das Journaling ab Trixie zu konfigurieren. Wurde es schon präventiv aktiviert (6->A12->3) sind die vorhergehenden Schritte nicht notwendig.
Nun ist die Systempartition wieder am Analysesystem im nur Lesemodus zu mounten mit sudo mount -o ro /dev/sda2 /mnt
Danach sollte es am Analysesystem wie folgt aussehen:
pi@raspberrypi-trixie64-lite:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 2G 0 loop
sda 8:0 0 3,6T 0 disk
├─sda1 8:1 0 512M 0 part
└─sda2 8:6 0 32G 0 part /mnt
mmcblk0 179:0 0 7,4G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 6,9G 0 part /
zram0 254:0 0 2G 0 disk [SWAP]Nun kann mit folgenden Befehlen das Journal gelesen werden.
1) Die letzten 1000 Zeilen des Systemlogs, die meist die Ursache des erfolglosen Bootprozesses zeigen:
pi@raspberrypi-trixie64-lite:~ $ sudo journalctl /mnt/var/log/journal -n 1002) Das gesamte Systemlog vom letzten Boot:
pi@raspberrypi-trixie64-lite:~ $ sudo journalctl -D /mnt/var/log/journal -b 0Z.B. kann man dann folgende Zeilen finden:
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: dev-disk-by\x2dpartuuid-585051f5\x2d10.device: Job dev-disk-by\x2dpartuuid-58505>
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: Timed out waiting for device dev-disk-by\x2dpartuuid-585051f5\x2d10.device - /de>
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: Dependency failed for media.mount - /media.
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: Dependency failed for local-fs.target - Local File Systems.
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
Jan 10 16:40:29 raspberrypi-bookworm64-lite-regression systemd[1]: media.mount: Job media.mount/start failed with result 'dependency'.die darauf hinweisen, dass in der /etc/fstab eine Partition mit der PARTUUID 585051f5-10 nicht gefunden wird und deshalb der Boot failed. Lösung: Das Gerät anschliessen welches die fehlende Partition besitzt oder nofail als weiteren Parameter in der /etc/fstab für diese Partition eintragen.
Zum Schluss sollte die Zeile Storage=auto in /mnt/etc/systemd/journal.conf auf Storage=volatile wie oben beschrieben, geändert werden damit das Systemlog im Speicher gehalten wird und nicht die SD Karte belastet. Auf Trixie kann das auch mit raspi-config (6->A12->2) einfacher geändert werden.
Wie ganz oben steht ist das Tut noch im Entstehen und nicht final. Lasst es mich erst einmal finalizen. Danach ist jeder Feedback/Korrektur/Erweiterung gerne willkommen.
Habe es korrigiert.
hat jemand einen Vorschlag?
- aber genau dann sollte derjenige, der leider kein