Debian: Nach Update auf Trixie liegen die Kernel-Images am falschen Ort

[Photon]

Hallo Community,

ich habe gestern einem Bekannten beim Update von Debian 12 auf 13 geholfen. Nach dem Update konnte das System nicht booten sondern sprang direkt ins UEFI. Es hat sich herausgestellt, dass aus irgendeinem Grund alle Kernel-Images (die vmlinuz- und die .img-Dateien) nach /boot/efi umgezogen sind und nicht mehr in /boot waren. Nachdem wir diese Dateien via chroot händisch nach /boot kopiert haben, bootet das System nun.

Natürlich ist das keine sinnvolle Lösung, weil nach weiteren Updates die entsprechenden Dateien neuer Kernels wahrscheinlich wieder in den falschen Ordner geschrieben werden. Hat jemand eine Idee, was da schief gelaufen ist und was man dagegen tun könnte?

Die Partitionierung ist wie üblich: Eine Partition für /, eine für /home und eine kleine FAT32-Partition für /boot/efi.

Danke für alle Tipps!
Photon

 

[konkretor]

Hast du Secureboot an? Wie hast das update gemacht, klassiche über apt?

So etwas ähnliches habe ich hier gefunden, das war noch mit dem RC1 installer

https://www.reddit.com/r/debian/comments/1krfytz/debian_13_trixie_rc1_installer_doesnt_seem_to/

 

[Photon]

Hast du Secureboot an?

Frag ich den Bekannten, die Maschine steht bei ihm und ich kann es nicht sofort überprüfen. Er gibt mir in einer knappen Stunde Bescheid und ich melde mich nochmal mit der Info!

Wie hast das update gemacht, klassiche über apt?

Genau!

So etwas ähnliches habe ich hier gefunden, das war noch mit dem RC1 installer

Danke für den Tipp, dann müssen wir wohl abwarten, was er über die Secure Boot Einstellung sagt!

 

[Photon]

Nachtrag: Nein, Secure Boot ist deaktiviert gewesen, war also leider nicht das Problem...

 

[floTTes]

Welcher bootloader? grub-efi-amd64? Ist /etc/fstab korrekt? Was für ein FS hat /boot bzw. hier /?

sudo dpkg-reconfigure grub-efi-amd64 nachdem /etc/fstab überprüft wurde. /boot/efi muss nicht mehr gemounted werden. Das übernimmt jetzt eigentlich systemd ... nach /efi.

 

[Photon]

Welcher bootloader? grub-efi-amd64?

Genau!

Ist /etc/fstab korrekt?

Interessanterweise wird die vfat-Partition nach /boot und nicht nach /boot/efi gemountet. Ich weiß leider nicht, ob das vor dem Update schon so war oder beim Update irgendwas durcheinander gekommen ist, gehe aber vom Ersteren aus. Keine Ahnung, wie es davor funktioniert hat...

Was für ein FS hat /boot bzw. hier /?

/boot ist wie gesagt vfat und / ist ext4.

sudo dpkg-reconfigure grub-efi-amd64 nachdem /etc/fstab überprüft wurde. /boot/efi muss nicht mehr gemounted werden. Das übernimmt jetzt eigentlich systemd ... nach /efi.

Wie sollte denn die fstab Stand heute aussehen?

Danke für den Input!

 

[konkretor]

Ich würde nochmals ne Runde Updates installieren.
Es gibt schon die ersten fixes, da wird auch systemd mit uefi gepatcht
https://www.debian.org/News/2025/20250906

 

[Photon]

@konkretor Danke, geb ich weiter, wobei wahrscheinlich beim Update via apt eh schon die neusten Versionen aller Pakete installiert worden sind...

Ergänzung (6. September 2025)

Was ist denn der richtige Mountpoint für die FAT-Partition, /boot oder /boot/efi? Ich dachte immer, es wäre /boot/efi und bin etwas irritiert, dass es in der Debian-Installation auf einmal /boot ist...

 

[NameHere]

Was ist denn der richtige Mountpoint für die FAT-Partition, /boot oder /boot/efi? Ich dachte immer, es wäre /boot/efi und bin etwas irritiert, dass es in der Debian-Installation auf einmal /boot ist...

auf der boot/efi (FAT32) Partittion landet nur das nötigste um zu booten.
Die initrd.img , vmlinuz und config Datein sind unter /boot auf der / Partition

debian trxie auf testing upgrade vor kurzem gemacht. Deswegen auch der 6.16er Kernel.

 

[Photon]

Ja genau, deshalb ist mir unerklärlich, wie die ganzen Dateien nach /boot/efi gekommen sind... Wahrscheinlich waren sie auf der FAT-Partition, die durch die fstab nach /boot gemountet worden ist. Und diese Partition wird jetzt aber durch systemd nach /boot/efi gemountet, sodass die Dateien darauf in /boot/efi statt /boot landen. Wenn diese Vermutung stimmt, dann ist das Problem eigentlich gelöst und neue Kernel werden in Zukunft korrekt nach /boot geschrieben.

 

[Photon]

Nachtrag: Ich denke, meine Erklärung aus dem vorherigen Post war nahezu richtig. Offenbar wurde der fstab-Eintrag trotz systemd-Mount nach /efi auch irgendwie berücksichtigt. Der Versuch, einen neuen Kernel zu installieren schlug fehl, weil die efi-Partition vollgelaufen ist.

Wir haben jetzt die Partition gesäubert, also alle vmlinuz und .img Dateien dort händisch gelöscht (vorher unmounten und unter /mnt mounten, um zu sehen, welche Dateien wirklich drauf sind). Dann den fstab-Eintrag gelöscht, sodass systemd nun die Partition nach /efi gemountet hat.

Fehler, die weiterhin bestehen:

• grub-install meldet, dass er das Efi-Verzeichnis nicht finden kann. Wenn man ihn mit "grub-install --efi-directory=/efi" ausführt, läuft er aber durch.
• update-grub kann nur mit vollem Pfad /usr/sbin/update-grub aufgerufen werden, weil /usr/sbin nicht in $PATH enthalten ist.

 

[floTTes]

Soweit ich weiß, ist EFI-System-Partition als /boot der heutige moderne Stand. Allerdings scheinen das nicht alle Distros so zu handhaben.
Ob der /efi-auto-Mount Standard von systemd oder nur debian ist, weiß ich auch nicht.

Du kannst es als auto-Mount unter /efi lassen und fixen mit:
sudo ln -s /efi /boot/efi

/usr/sbin ist bei debian nicht im Standard-User-$PATH enthalten. Erst mit sudo kannst du auf den vollen Pfad verzichten:
sudo update-grub sollte gehen.

 

[TomH22]

update-grub kann nur mit vollem Pfad /usr/sbin/update-grub aufgerufen werden, weil /usr/sbin nicht in $PATH enthalten ist.

Das ist kein Fehler in debian, sondern gewollt. „normale“ user sollen keine Programme in sbin (z.B. auch ifconfig, etc.) aufrufen. Bisschen idiotisch, aber leicht in .profile oder .bashrc änderbar.

 

[floTTes]

ifconfig

HAHA ... wie oldskool bist du denn.

Bisschen idiotisch, aber leicht in .profile oder .bashrc änderbar.

Hatte ich auch überlegt, aber debian hat seine Wurzeln doch eher bei "lieber sicher als bequem". Ich hab's dann also doch gelassen.

 

[TomH22]

HAHA ... wie oldskool bist du denn.

Unix Nutzer seit 1986….
Nutze ich aber in der Regel nur zur Anzeige, ist schneller eingegeben als „ip addr show“, in der Regel reicht ifc <tab>, aber keine Sorge meine Systeme laufen schon mit NetworkManager und konfigurieren das Netzwerk automatisch.

Aber wenn man auf etwas experimentelleren Platformen unterwegs ist, wie hier: https://www.computerbase.de/forum/t...bian-trixie-auf-dem-visionfive-2-sbc.2249632/

dann ist ifconfig oft eines der ersten Kommandos, dass ich nach dem Booten auf der seriellen(!) Konsole eingebe, um zu schauen ob das System ein laufendes Netzwerkinterface und eine IP Adresse hat.

Man muss natürlich sagen, dass die meisten Programme in sbin sowieso sudo brauchen, insofern ist das mit dem Pfad eigentlich konsequent.

 

[Tanzmusikus]

Soweit ich weiß, ist EFI-System-Partition als /boot der heutige moderne Stand. Allerdings scheinen das nicht alle Distros so zu handhaben.

Bei mir läuft z.B. MX Linux KDE (Debian) in der VM. Die EFI-Partition wird hier standardmäßig nach /boot/efi gemountet. Bei LMDE6, Linux Mint Xfce und auch EndeavourOS ist das ebenso.

Der Pfad sieht dann so aus:
/boot/efi(/EFI/<ggf. Unterordner>), wobei sich das in () auf der EFI-Partition befindet.

 

[TomH22]

Da Debian auf verschiedenen Plattformen und Konfigurationen läuft (z.B. auch ARM oder RISC-V Systeme die direkt den Kernel von U-Boot laden lassen, ohne Grub) gibt es auch verschiedene Orte wo der Kernel liegt. Beim UEFI Boot liegt auf der EFI/Boot Partition tatsächlich nur der UEFI Shim und Grub, bei U-Boot liegt hingegen liegt dort auch der Kernel und das initramfs und noch andere Dinge wie Device Tree Files.

Der Kernel und alle Installations/Update Skript sind im Paket linux-image-<Architektur> also z.B. linux-image-amd64 zusammengefasst. Die Skripte versuchen die aktuelle Boot Konfigration zu erkennen, und dann entsprechend den Kernel und alle anderen notwendigen Files an die richtigen Stellen zu packen, ausserdem helfen dabei noch Programme wie update-grub. Wie ich bei meinem RISC-V Projekt gelernt habe, sind diese Routinen etwas tricky und greifen auch schon mal daneben, wenn die Konfiguration nicht in das Raster passt.

Wahrscheinlich ist beim System des TE genau das passiert.

 

[floTTes]

@Tanzmusikus,
das war bei bullseye und bookworm so auch Standard.
Ich habe trixie noch nicht über den Installer installiert. K.A. wie's da ist.

Ich meine, dass systemd-boot die EFI-Partition in /boot verlangt. Bei mir habe ich das auch so für grub angelegt.

[...] auch EndeavourOS ist das ebenso.

Echt? Manjaro und Arch Linux nutzen doch eher /boot für die EFI-Partition, oder?

 

[Tanzmusikus]

@floTTes
Ja echt! systemd-boot = /boot/efi(/EFI/<XXX>

Ich kann ja mal Debian 13 Trixi als VM installieren & nachschauen, wie's da ist. 😉

 

[TomH22]

Echt? Manjaro und Arch Linux nutzen doch eher /boot für die EFI-Partition, oder?

Wie gesagt das hat damit zu tun, dass bei Debian der Kernel im „logisch“ an der gleichen Stelle ist, also in /boot, unabhängig davon ob er mit auf dem root Filesystem liegt (wie meistens auf PCs) oder auf einer anderen Partition. Würde man die EFI Partition (die ja nur den Bootloader enthält) in /boot mounten, dann würde dieses Schema nicht mehr passen.

Ich habe jetzt keine Erfahrung mit Arch, kann also nicht sagen wie es dort aussieht, aber mein Verständnis der üblichen Linux „Konventionen“ ist, dass die boot-Dateien des Systems, also kernel, initramfs, config und sytem.map, in /boot liegen, die Platform spezifischen „Pre-Boot“ Partitionen (wie eben die EFI System Partition) werden dann unterhalb von /boot gemounted.

Ich habe jetzt auch keine Erfahrung wie mit verschlüsselten root Partitionen umgegangen wird, da noch nicht probiert. Kann Grub direkt davon booten, oder braucht man dann auch eine unverschlüsselte „Boot“ Partition mit dem Kernel und initramfs?