Nach dem erneuten Aufsetzen meines Nextcloud-Pis fiel mir zum ersten Mal eine weitere Änderung bei Raspberry Pi OS auf, diesmal geht es um den /boot Mountpoint.
/boot
Die erste Partition auf einer MicroSD Karte mit Raspberry Pi OS enthält alle Dateien, um deinen Raspberry Pi zu starten. Dazu gehören klassischerweise
- das Kernelimage
- cmdline.txt
- config.txt
- start.elf
- sowie einige weitere Dateien.
Diese Partition mit VFAT Dateisystem wurde bisher immer unter /boot gemounted. Da dies aber auch andere Betriebssysteme wie z.B. DietPi OS tun, konnte es in einer Multiboot Umgebung zu Konflikten kommen.
neuer Mountpoint
In Vorbereitung auf die Debian Hauptversion Trixie, auf der der nächste Raspberry Pi OS Release basieren wird, ist schon aus Kompatibilitätsgründen eine Anpassung notwendig.
Daher finde ich auf meinem Nextcloud Pi die erste Partition der System-NVME unter /boot/firmware gemounted.
In der Regel macht das keinen großen Unterschied. Nur Scripte, die mit /boot arbeiten sollten entsprechend angepasst werden.
Bestandsaufnahme
Mich interessiert natürlich, auf welchen meiner Raspis schon mit dem neuen Mountpoint konfiguriert sind.
In der Regel werden neue Raspis bei mir immer mit dem denselben Standard-Image von Raspberry Pi OS 5 geflashed, dass ich mir vor zwei Jahren gebaut habe. Ausnahme ist die Nextcloud Installation.
Raspberry Pi 5
Zunächst schaue ich mir mal die Raspberry Pi 5 mit NVME Laufwerk an. Bei diesen ist durchweg die Migration bereits gelaufen. Allerdings ist der älteste davon von 2024.
Beim 5er mit MicroSD Karte, den ich dieses Jahr in das KKBS Gehäuse gebaut habe, untersuche ich die Speicherkarte in einem anderen Rechner und finde dort kein firmware Verzeichnis auf der ersten Partition vor.
Raspberry Pi 4
Ich konnte keinen 4er Modell bei mir finden, bei dem die erste Partition unter /boot/firmware gemounted ist.
| Raspi | Modell | Drive | Inbetriebnahme | neuer Mountpoint? |
|---|---|---|---|---|
| Nextcloud | 5 | NVME | 2025 | ja |
| Homeassistant | 5 | MicroSD | 2024 | |
| Pineberry Pi | 5 | NVME | 2024 | ja |
| Argon Thrml | 5 | MicroSD | 2024 | nein |
| KKBS | 5 | MicroSD | 2025 | nein |
| Stack | 4 | MicroSD | 2023 und 2024 | nein |
| frink-Cluster | 4 | MicroSD | 2021 | nein |
| Datenbank | 4 | SATA M.2 | 2023 | nein |
| Homeserver | 4 | SATA M.2 | 2023 | nein |
Migrationsauslösung
Als nächstes stellte sich mir die Frage, über welchen Mechanismus die Umstellung ausgelöst wird. Zunächst dachte ich an natürlich an den Upgrade-Mechanismus von apt, konnte den aber schnell ausschließen. Auch das Update des Bootloaders änderte nichts.
Überrascht war ich, nachdem ich den KKBS Raspi gestartet habe. Obwohl die externe Analyse der MicroSD Karte das firmware Verzeichnis nicht zeigte, war es nach dem Einloggen vorhanden und der neue Mountpoint aktiv.
Damit ist erwiesen, dass die Migration während des Boot Prozess geschieht. Da das Dateidatum von /boot/firmware auf den 01.01.1970 gesetzt ist, passiert das, bevor der Raspi die aktuelle Uhrzeit aus dem Internet synchronisiert hat.
/etc/fstab
Die Änderung betrifft nur den Mountpoint an sich, nicht aber die Partitionen auf dem Medium.
Vergleichen wir mal den alten Eintrag für die Bootpartition in der /etc/fstab auf der MicroSD Karte
PARTUUID=e3e56579-01 /boot vfat defaults 0 2mit dem gleichen Eintrag nach der Migration
PARTUUID=e3e56579-01 /boot/firmware vfat defaults 0 2manuelle Anpassung
Ich wollte jetzt versuchen, einen Raspberry Pi 4 genau so um zu stellen. Der Prozess scheint sehr einfach zu sein:
- /boot/firmware Verzeichnis erstellen.
- Die Dateien in /boot in das neue Verzeichnis kopieren
- /etc/fstab auf den neuen Mounpoint umstellen.
Ich habe es mehrfach probiert und bin damit jedes mal gescheitert. Nach der Umstellung ist der Raspi nicht wieder gestartet. Ich vermute, dass der Bootloader des Raspberry Pi 4 immer von der ersten Partition der MicroSD Karte booten möchte. Der Eintrag der fstab interessiert zu dem Zeitpunkt nicht.
Der 4er Pi benötigt diese Migration auch nicht unbedingt, während dies durch den PCIe Bus beim Raspberry Pi 5 durchaus Sinn ergibt.
Neuinstallation
Zu guter Letzt will ich sehen, was ich auf einem frisch geflashtem Raspberry Pi OS vorfinde, Ich starte also den Imager und flashe Raspberry Pi OS 64-bit für den Raspberry Pi 4B auf die Speicherkarte.
Fazit
Seit wann diese Änderung verwendet ist, kann ich nicht genau sagen, da ich neue Raspis in der Regel mit meinem eignen Standardimage flashe.
Durch die Änderung wird die Boot-Partition besser von der Root-Partition getrennt und es wird sehr viel einfacher, den Raspi zu einem Multiboot System auf dem du verschiedene Betriebssysteme wechselseitig starten kannst, umzurüsten. Das werde ich vermutlich bald mal ausprobieren.
Ob und wann auch der Raspberry Pi 4 umgestellt wird, ist nicht absehbar und vielleicht auch nicht wirklich sinnvoll.
