gelöst: Filesystem read-only

  • Hallo,

    mir scheint, ich habe mit Buster ein ähnliches Problem wie Nach Upgrade auf Stretch nur noch read-only.

    Ich habe zwei PI3B+ mit dem In-Place Upgrade aus Upgrade Your Raspberry Pi to Raspbian Buster, Without Losing Data auf Buster umgestellt.

    Nachdem es nun nach einiger Zeit einige Merkwürdigkeiten gibt, ist mir nun aufgefallen, dass die Zeit nicht passt und darüber bin ich dann darauf gestossen, dass bei beiden das root-Filesystem read-only ist.

    Code
    /dev/mmcblk0p7 on / type ext4 (ro,relatime)
    Code
    EXT4-fs (mmcblk0p7): INFO: recovery required on readonly filesystem
    EXT4-fs (mmcblk0p7): write access will be enabled during recovery
    usb 1-1: new high-speed USB device number 2 using dwc_otg
    Indeed it is in host mode hprt0 = 00001101
    EXT4-fs (mmcblk0p7): recovery complete
    EXT4-fs (mmcblk0p7): mounted filesystem with ordered data mode. Opts: (null)
    VFS: Mounted root (ext4 filesystem) readonly on device 179:7.
    devtmpfs: mounted

    Das macht dann natürlich eine Menge Probleme

    Code
    ddclient[709]: FATAL:    Cannot create file '/var/cache/ddclient/ddclient.cache'. (Read-only file system)
    lightdm[1002]: Could not chown user data directory /var/lib/lightdm/data/lightdm: Error setting owner: Read-only file system
    pihole-FTL[2601]: Failed to set capabilities on file `/usr/bin/pihole-FTL' (Read-only file system)
    systemd[2675]: stubby.service: Failed at step CACHE_DIRECTORY spawning /bin/sleep: Read-only file system
    systemd[2675]: stubby.service: Failed to set up special execution directory in /var/cache: Read-only file system
    apt.systemd.daily[22813]: /usr/lib/apt/apt.systemd.daily: 320: /usr/lib/apt/apt.systemd.daily: cannot create /var/lib/apt//daily_lock: Read-only file system

    usw.

    Hat Jemand eine Idee, was da passiert ist und wie man das retten kann?

  • Hast Du da NOOBS dauf?

    Ich würde erst einmal (falls noch nicht geschehen) ein Backup ziehen, dann nachsehen, ob der Platz auf der mSD reicht, dann mal die logs nach ungewöhnlichen Einträgen absuchen und danach einen file system check machen.

  • Den Betreff habe ich geändert. Es scheint an einem defekten FS auf einem der RPi 3 B+ zu liegen.
    Auszug von dmesg:

    Damit ist /boot/cmdline.txt nicht schreibbar. Wie bekomme ich denn nun den file system check angestoßen?

    Ja, da ist NOOBS drauf.

  • Vorneweg: Wenn dir irgendwelche Daten auf der SD-Karte wichtig sind, ist spätestens jetzt der passende Zeitpunkt, diese wegzusichern.

    die "cmdline.txt" siehst du ja auch, wenn du dir das Filesystem der SD-Karte unter Windows ansiehst. Dort solltest du die cmdline.txt beschreiben können.

    in besagter txt-Datei fügst du am Ende der Zeile noch ein Leerzeichen und folgendes hinzu:

    Code
    fsck.mode=force

    Dann sollte der Raspberry im Bootvorgang normalerweise die SD-Karte auf Fehler prüfen...

    Dran denken, die Änderung in der cmdline.txt später rückgängig zu machen, sonst prüft der Raspberry bei jedem Neustart erneut das Dateisystem...

  • Dann sollte der Raspberry im Bootvorgang normalerweise die SD-Karte auf Fehler prüfen...

    Was er auch tat.

    Zitat
    EXT4-fs (mmcblk0p7): mounted filesystem with ordered data mode.
    Opts: (null) EXT4-fs (mmcblk0p7): recovery complete

    Allerdings würde ich vermuten, dass die µSD Karte bereits im Sterben liegt. Backup und ersetzen tippe ich mal.

  • Manuelles reparieren mit e2fsck geht nur, wenn das FS nicht gemountet ist. Das betrifft die Partition 7 (und Partition 6 FAT-boot ? mit fsck.fat).

    Da Du noch Partitionen frei hast, kannst Du versuchen mit einem dort installierten BS (z.B. Raspbian-Light) die Filesysteme auf P7 und P6 manuell zu reparieren. Ein manuelles Reparieren ist immer dann erforderlich, wenn die Reparatur eine manuelle Bestärigung erfordert. < man e2fsck >

    Vielleicht bekommst Du am ro gemounteten FS aber auch schon eine (brauchbare) Ausgabe von < sudo e2fsck -fvn /dev/mmcblk0p7 >

    Manchmal hilft auch schon den Repairbefehl, der nur einmal beim Booten ausgeführt wird, mehrmals (>5 mal) hintereinander auszuführen <sudo e2fsck -fvp /dev/mmcblk0p7 >

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hallo RTFM,

    "sudo e2fsck -fvn /dev/mmcblk0p7" liefert:

    Sieht das nicht gut aus?

  • Du hast das vom laufenden System aus gestartet, das funktioniert so nicht. Wenn Dein NOOBS noch ein anderes System mitbentsprwchenden Programmen zum Reparieren starten kann, nutze dieses und versuche, mmcblk0p7 von dort aus zu reparieren.

  • Du hast das vom laufenden System aus gestartet, das funktioniert so nicht. Wenn Dein NOOBS noch ein anderes System mitbentsprwchenden Programmen zum Reparieren starten kann, nutze dieses und versuche, mmcblk0p7 von dort aus zu reparieren.

    Hallo STF,

    da ist noch ein KODI drauf. Da ist /dev/mmcblk0p7 auch ro gemounted.

    Gibt es boot-Optionen, um das FS rw zu setzen und zu reparieren?

  • Kannst du eine andere mSD Karte mit Raspbian lite beschreiben, Deine Karte (nach Backup) im Kartenleser ans gestartete lite andocken und dann den Reparaturversuch starten. Wie, steht in #6 von RTFM...

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!