Raspberry Pi OS Updates machen rpi-clone & co unbrauchbar: Problem & Lösungen erklärt

[DMW007]

In den letzten Tagen erleben Nutzer des Raspberry Pi OS 12 eine böse Überraschung: Das Einspielen der APT-Aktualisierungen per sudo apt update && sudo apt upgrade führt dazu, dass manche Programme nicht mehr funktionieren. Beispielsweise erstellt rpi-clone nur noch kaputte Klone, die in BusyBox statt dem Raspberry Pi OS starten. Hintergrund sind zwei Änderungen, die meiner Wahrnehmung nach bislang kaum beachtet wurden. Zum einen hat sich die Verzeichnisstruktur in /boot beim Raspberry Pi OS 12 geändert - Es wurde ein Unterordner /boot/firmware eingeführt. Dort liegen nun Dateien wie config.txt und cmdline.txt, die zuvor direkt in /boot gespeichert wurden. Es gab eine Übergangslösung, wodurch in einigen Fällen auch die alten Pfade nutzbar waren. Diese hat das Raspberry Pi OS jedoch Ende Januar 2024 mit einem aktualisierten APT-Paket entfernt. Direkte Änderungen an den Dateien sind eher etwas für fortgeschrittene Anwender. Allerdings sind einige Programme betroffen, die intern diese Dateien verwenden bzw. Änderungen vornehmen. Das ist einigen sicher nicht bewusst, sofern man die tiefere Funktionsweise nicht kennt.

Dieser Beitrag fasst zusammen, was die beiden Dateien cmdline.txt und config.txt machen und welche Änderungen es genau gab. Außerdem demonstriere ich am quelloffenen rpi-clone Skript, wie man das Problem mit etwas Bash-Wissen selbst lösen kann. Wer das nicht hat, wird in vielen Fällen trotzdem von der OSS-Gemeinschaft profitieren: Während ich diesen Beitrag erstellt habe, waren bereits andere Open Source Entwickler dabei, das Problem ebenfalls zu lösen.

Zum kompletten Beitrag im U-Labs Portal

[U-Labs YouTube]

Kommentar von @andreabc1469:
super Info, wusste ich nicht

[U-Labs YouTube]

Kommentar von @jensschroder8214:
eine Link zu erstellen ist eine übliche Maßnahme, wenn Dateien umziehen, auf diese weiter zugreifen zu können.

[DMW007]

Theoretisch ist das eine super Idee, wenn es alle Programme berücksichtigen würden. Insbesondere bei sed finde ich es daher schade, dass das im Standard nicht der Fall ist. Damit wäre das Problem sicher schon deutlich entschärft. Man kann nun dagegen argumentieren: Volle Macht dem Entwickler. Manche haben ja den Grundsatz, ein Programm soll nur das tun, was explizit angegeben wird, um nicht überraschende Ergebnisse zu liefern. Dagegen wiederum lässt sich streiten, ob das folgen eines Symlink Standard sein sollte. Viele Entwickler werden den wahrscheinlich nicht verwendet haben, weil sie ihn nicht kennen und/oder nicht mit einem Umzug der Dateien gerechnet haben. Die liegen seit ich denken kann in /boot. Im schlimmsten Falle führt das nicht mal zu einer Fehlermeldung wie bei rpi-clone.

Die daraus gelernte Lektion sollte sein, so etwas möglichst zu erwarten und bei den genutzten Werkzeugen zu prüfen. Der bessere Ansatz wäre in meinen Augen, den Einhängepfad zur /boot Partition gar nicht hart zu kodieren. Sondern z.B. aus der /etc/fstab auszulesen:

$ grep fat /etc/fstab 
PARTUUID=caad1b0f-01  /boot/firmware  vfat    defaults          0       2

[U-Labs YouTube]

Antwort von @zwixx259:
Das Problem ist, ein symlink kann schneĺl zu einem Sicherheitsrisiko werden. Weswegen viele Tools es nur dann akzeptieren, wenn der Benutzer es explizit wünscht.

[DMW007]

Raspberry Pi OS Nutzer aufgepasst: Eine Aktualisierung des raspberrypi-sys-mods Pakets von Ende Januar 2024 kann für Probleme sorgen. Sie entfernt symbolische Verknüpfungen zu mehreren wichtigen Dateien in der /boot Partition. Diese sind bereits seit dem Raspberry Pi OS 12 in einen Unterordner namens "firmware" umgezogen. Einige Programme funktionieren daher möglicherweise nicht mehr richtig und müssen ebenfalls aktualisiert werden. Beispiele dafür sind rpi-clone oder auch der Einrichtungsassistent von DietPi. Wer mit z.B. sudo apt update && sudo apt upgrade seine Pakete jüngst auf den aktuellen Stand gebracht hat oder bringt, ist potenziell betroffen. Zum Kurzvideo auf YouTube.

[U-Labs YouTube]

Kommentar von @s1freiherr583:
Hallo Daniel, vielen Dank für das Video. Apropos Raspberry Pi Boot. Könntest du ein Video über das Netzwerkbooten (nicht Netzwerkinstallation) eines Raspberry Pi machen? Vielleicht mit dnsmasq oder etwas ähnlichem?

[DMW007]

Hi! Habe ich auf meine Themenliste aufgenommen, danke für den Vorschlag

[U-Labs YouTube]

Kommentar von @SierraX369:
Aufgefallen ja betroffen nicht wirklich

[U-Labs YouTube]

Kommentar von @avalon_64:
Es scheint aber nicht alle Raspberrry Pi OS Versionen zu betreffen, ich habe vor ein paar Tagen einen Raspberry Pi 3 neu installiert (07.02.2024). Da bekam ich noch Debian 11.9 bei dem es noch kein /boot/firmware gibt.