Warum startet aktuellester Kernel auf Raspberry nicht?

[san04]

Hallo zusammen,

mich beschäftigt gerade die Frage, ob mein Raspberry Pi (Debian Bookworm) aktuell ist.

Mir ist aufgefallen, dass der aktuellste Kernel nicht gebootet wird:

Code: Alles auswählen

$ uname -a
Linux BackupPi 6.1.0-11-arm64 #1 SMP Debian 6.1.38-4 (2023-08-08) aarch64 GNU/Linux

Code: Alles auswählen

`$ dpkg -l linux*
WARNING: terminal is not fully functional
Press RETURN to continue 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                Version      Architecture Description
+++-===================================-============-============-==============================================
ii  linux-base                          4.9          all          Linux image base package
un  linux-doc-6.1                       <none>       <none>       (no description available)
ii  linux-image-6.1.0-11-arm64          6.1.38-4     arm64        Linux 6.1 for 64-bit ARMv8 machines (signed)
un  linux-image-6.1.0-11-arm64-unsigned <none>       <none>       (no description available)
rc  linux-image-6.1.0-13-arm64          6.1.55-1     arm64        Linux 6.1 for 64-bit ARMv8 machines (signed)
un  linux-image-6.1.0-13-arm64-unsigned <none>       <none>       (no description available)
ii  linux-image-6.1.0-15-arm64          6.1.66-1     arm64        Linux 6.1 for 64-bit ARMv8 machines (signed)
un  linux-image-6.1.0-15-arm64-unsigned <none>       <none>       (no description available)
ii  linux-image-arm64                   6.1.66-1     arm64        Linux for 64-bit ARMv8 machines (meta-package)
un  linux-image-generic                 <none>       <none>       (no description available)
un  linux-initramfs-tool                <none>       <none>       (no description available)
un  linux-kernel-log-daemon             <none>       <none>       (no description available)
un  linux-latest-modules-6.1.0-15-arm64 <none>       <none>       (no description available)
un  linux-perf                          <none>       <none>       (no description available)`

Kam wohl vor 2 Tagen:

Code: Alles auswählen

Start-Date: 2023-12-11  06:06:31
Commandline: /usr/bin/unattended-upgrade
Install: linux-image-6.1.0-15-arm64:arm64 (6.1.66-1, automatic)
Upgrade: linux-image-arm64:arm64 (6.1.55-1, 6.1.66-1)
End-Date: 2023-12-11  06:11:13`

Hängt das noch mit der ext4 data corruption Regression zusammen? Der 13-er war offenbar zwischenzeitlich installiert, wurde aber von `autoremove` entfernt, da bin ich unsicher ob es daran lag, dass ich in der Zwischenzeit nicht neugestartet hatte, oder der auch nicht geladen wurde. Den habe ich jetzt nochmal händisch nachinstalliert es wird trotzdem der 11er gebootet.

Jetzt kenne ich GRUB und systemd-boot, aber mit dem Startprozess des Pi habe ich mich bisher nicht auseinandergesetzt. Gefunden habe ich `u-boot-rpi`, das ist allerdings nicht installiert.

Besteht überhaupt handlungsbedarf? Und falls ja, könnt ihr mir einen Tipp geben, wie ich den Bootloader konfiguriere?

---
EDIT:
Hier erscheinen die Kernel:

Code: Alles auswählen

 ~$ ls /boot/
System.map-6.1.0-11-arm64  initrd.img-6.1.0-11-arm64
System.map-6.1.0-13-arm64  initrd.img-6.1.0-13-arm64
System.map-6.1.0-15-arm64  initrd.img-6.1.0-15-arm64
config-6.1.0-11-arm64	  vmlinuz-6.1.0-11-arm64
config-6.1.0-13-arm64	  vmlinuz-6.1.0-13-arm64
config-6.1.0-15-arm64	  vmlinuz-6.1.0-15-arm64
firmware

Hier wiederum nur der 11er:

Code: Alles auswählen

 $ ls /boot/firmware/
COPYING.linux		 fixup_cd.dat
bcm2711-rpi-4-b.dtb	 fixup_db.dat
bcm2711-rpi-400.dtb	 fixup_x.dat
bcm2711-rpi-cm4-io.dtb	 initrd.img-6.1.0-11-arm64
bcm2837-rpi-3-a-plus.dtb  kernel.img
bcm2837-rpi-3-b-plus.dtb  kernel7.img
bcm2837-rpi-3-b.dtb	 start.elf
bcm2837-rpi-cm3-io3.dtb   start4.elf
bcm2837-rpi-zero-2-w.dtb  start4cd.elf
bootcode.bin		 start4db.elf
cmdline.txt		 start4x.elf
config.txt		 start_cd.elf
fixup.dat		 start_db.elf
fixup4.dat		 start_x.elf
fixup4cd.dat		 sysconf.txt
fixup4db.dat		 vmlinuz-6.1.0-11-arm64
fixup4x.dat

Und hier auch nur der 11er:

Code: Alles auswählen

~$ cat /boot/firmware/config.txt 
# Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
arm_control=0x200

enable_uart=1
upstream_kernel=1

kernel=vmlinuz-6.1.0-11-arm64
# For details on the initramfs directive, see
# https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=10532
initramfs initrd.img-6.1.0-11-arm64

Initramfs läuft für alle Kernel fehlerfrei durch:

Code: Alles auswählen

~$ sudo update-initramfs -u -k all     
update-initramfs: Generating /boot/initrd.img-6.1.0-15-arm64
update-initramfs: Generating /boot/initrd.img-6.1.0-13-arm64
update-initramfs: Generating /boot/initrd.img-6.1.0-11-arm64

Nur sudo update-grub gibts halt nicht :'(

[MSfree]

Ich weiß nicht, was da bei dir schiefgelaufen ist.

Tatsächlich steht in deiner /boot/firmware/config.txt noch der alte Kernel samt der alten initrd. Bei meinem Raspi wurde durch

Code: Alles auswählen

apt-get update
apt-get dist-upgrade

nicht nur der 6.1.0-15er Kernel installiert sondern auch die /boot/firmware/config.txt entsprechend aktualisiert.

Ich würde an deiner Stelle die beiden apt-Befehle (siehe oben) ausführen und dann die /boot/firmware/config.txt kontrollieren.

Mit der ext4 data corruption hängt das in deinem Fall definitiv nicht zusammen. Der Fehler wirkt sich ohnehin nur im Zusammenhang mit ganz wenigen Softwarepaketen aus, vornehmlich Datenbanksoftware und selbst dann nur, wenn die Datenbank mit einer ganz speziellen Methode auf die Platte schreibt. Für 99% der Anwender passiert hier gar nichts. Davon abgesehen, betrifft das den 6.1.0-14er Kernel, der bei dir nicht installiert ist und auch nie gebootet wurde, bei dir bootet ja immer noch der ältere 6.1.0-11er.

[san04]

Ich würde an deiner Stelle die beiden apt-Befehle (siehe oben) ausführen und dann die /boot/firmware/config.txt kontrollieren.

Vielen Dank für deine Antwort. Das hatte ich bereits probiert, ohne Erfolg. Hatte mich dann gefragt, ob ich an der config.txt selbst Änderungen vornehmen darf und hätte es wohl auch probiert. Aber da der Kernel auch nicht in /boot/firmware liegt wollte ich nicht riskieren, dass das System dann womöglich gar nicht mehr hochkommt. Wie schaut der Ordner denn bei dir aus?

Mit der ext4 data corruption hängt das in deinem Fall definitiv nicht zusammen.

Das ist ja schon einmal gut zu wissen.

[rhHeini]

Allerdings scheint der 15ner Kernel auch ein paar Hakeleien z.B. mit bestimmten Netzwerkkomponenten zu machen. Schau Dich mal im Forum um. Der scheint auch nicht sauber zu sein.

[MSfree]

Hatte mich dann gefragt, ob ich an der config.txt selbst Änderungen vornehmen darf und hätte es wohl auch probiert.

Wie gesagt, die Datei wurde bei mir beim dist-upgrade automatisch angepaßt.

Aber da der Kernel auch nicht in /boot/firmware liegt

Kernel, initrd, config und System.map liegen, wie bei allen Linuxen üblich, direkt unter /boot.

wollte ich nicht riskieren, dass das System dann womöglich gar nicht mehr hochkommt.

Die SD-Karte deines Raspis läßt sich mit jedem anderen Linuxrechner mounten. Sollte beim Booten also etwas schiefgehen, kannst du die Karte in einem anderen Linuxrechner bearbeiten und Änderungen rückgängig machen.

Du könntest dir sogar eine Notfall-SD-Karte erstellen, mit der du den Raspi booten kannst. Mit einem USB-Cardreader könntest du mithilfe der Notfall-SD die nicht bootende Karte bearbeiten.

Wie schaut der Ordner denn bei dir aus?

Das kann ich dir gerade nicht sagen, bin nicht vor Ort, um nachzuschauen.

[DaCoda]

Ich kenne mich da nicht so gut aus aber mit apt autoremove müsste er doch alle alten Kernel entfernen, so dass er den neuesten booten MUSS?

[san04]

Kernel, initrd, config und System.map liegen, wie bei allen Linuxen üblich, direkt unter /boot.

Danke, wusste nicht, ob diese Konvention für Raspis (mit der etwas eigenen Hardware und dem Bootvorgang) auch gilt.

Sollte beim Booten also etwas schiefgehen, kannst du die Karte in einem anderen Linuxrechner bearbeiten und Änderungen rückgängig machen.

Ja das simmt natürlich, könnte sogar einen Monitor dranhängen, die Vorsicht war mehr in der Faulheit begründet, das nicht tun zu wollen...

Ich kenne mich da nicht so gut aus aber mit apt autoremove müsste er doch alle alten Kernel entfernen, so dass er den neuesten booten MUSS?

Ich kenne das von debianoiden Systemen so, dass immer zwei Kernel bleiben. Deckt sich auch mit diesem System. Ich warte wohl mal einfach ab, was passiert wernn der nächste Kernel kommt... (da das auf der ARM-Schiene wohl nicht so oft passiert muss ich wohl etwas Geduld mitbringen...)