Fsck auf der Root-Partition auf BBB-basiertem Custom-Board

617
AnkurTank

Wir haben ein auf BeagleBone Black basierendes Embedded Linux Board. Es verfügt über Linux-3.12, 256 MB RAM und 4 GB eMMC mit ext4Dateisystem.

Manchmal stoßen wir auf Dateisystemfehler (selten, aber nicht unmöglich). Wir wollen also nach Dateisystemfehlern suchen und diese beim Booten beheben.
Natürlich möchten wir nicht, dass fsck oder ein anderes Dienstprogramm Daten im Dateisystem zerstört.

Wir haben busybox-basiert SysVinit, /forcefsckfunktioniert also nicht :( Dann habe ich das /etc/fstabfünfte Feld auf 1 gesetzt) ​​und dann fsck -pdas rcSSkript ausgeführt.

Diese Kombination funktioniert für andere rootfsPartitionen als Partitionen. Ich habe dazu einige Fragen.

  1. Gibt es sowieso fsckauf der rootfsPartition zu laufen ?
  2. Kann fsck -pDaten auf der Partition zerstören?
  3. Gibt es einen besseren Weg, um mit dieser Situation umzugehen, meine ich einen Dienst, der den Dateisystemfehler überprüft und korrigiert?
1

1 Antwort auf die Frage

1
dirkt

Normalerweise fragen Desktop-Linux-Distributionen auf SysVinit-Basis nach einem Root-Kennwort, wenn beim Booten Fehler im Root-Dateisystem festgestellt werden. Sie können dies dann verwenden, um fsckauf dem Stamm-FS auszuführen . Ich weiß nicht, ob Ihre eingebettete Distribution dies tut, aber es ist definitiv möglich, sie so zu konfigurieren.

Wenn während des Startvorgangs keine Fehler erkannt werden, können Sie sich als root anmelden, alles beenden, was nicht unbedingt erforderlich ist, das Root-Dateisystem mit einem Schreibschutz versehen und dann fsck ausführen.

Hierbei handelt es sich um das Root-Dateisystem Ihres Blockspeichers, nicht um rootfs . Rootfs ist ein minimales RAM-basiertes Dateisystem, das während des Startvorgangs verwendet wird. Es kann nicht beschädigt werden (es sei denn, Ihr Boot-Kernel-Image ist beschädigt oder Ihr Arbeitsspeicher ist schlecht).

Im Prinzip fsck -psollten nur "sichere" Reparaturen durchgeführt werden. Wenn Sie jedoch wirklich sicherstellen möchten, dass nichts Schlimmes passiert, führen Sie es manuell aus, sodass Sie für jede Aktion aufgefordert werden. Wenn es aus irgendeinem Grund wertvolle Daten im Root-Dateisystem gibt (sollte nicht vorkommen, aber vielleicht tun Sie es), machen Sie zuerst ein Backup dd.

Danke für die Antwort dirkt. Wir verwenden nur root-Benutzer in unserem Board. Multiuser-Systeme sind noch nicht verfügbar. Wir haben nicht einmal Initramfs / Ramdisk, die wir direkt vom Block-Root-Dateisystem booten. AnkurTank vor 7 Jahren 0
Root oder Multiuser spielt keine Rolle, es hängt davon ab, wie der Sysv-Init eingerichtet ist. Moderne Linux-Kernel verfügen über ein in das Image eingebettetes initramfs. Ich weiß nicht, welches Image Sie verwenden. Wenn Sie wirklich mit `/` als (ram-based) rootfs enden, das während des Bootens als root auf modernen Kernels verwendet wird, wie gesagt, gibt es wirklich keine Möglichkeit, die beschädigt werden kann, da sie jedes Mal neu erstellt wird. Wenn Ihr Kernel so eingerichtet ist, dass er ein Blockgerät als Root verwendet, ist das anders. Es hängt alles davon ab, wie Ihr Kernel eingerichtet ist, was ich hier nicht sehen kann. dirkt vor 7 Jahren 0
Ich könnte `fsck -q` von` rcS` (busybox-basiert) ausführen. Damit wurde der Fehler in der aktuellen Root-Partition behoben. Dazu benötigen wir jedoch einen Eintrag in `/ etc / fstab`. Inzwischen bin ich auf der Suche nach möglichen Dateisystemfehlern, um zu prüfen, ob dies durch "fsck" behoben werden kann oder nicht. AnkurTank vor 7 Jahren 0