Das Einhängen des Dateisystems beim Booten schlägt fehl, ist aber bei manueller Einhängung in Ordnung

Das Einhängen des Dateisystems beim Booten schlägt fehl, ist aber bei manueller Einhängung in Ordnung

Ich bin mir nicht sicher, wann/warum das passiert ist, aber ich habe ein RAID-Array in meinem eingegeben, /etc/fstabdas beim Booten gemountet wird /mnt/data. Bis heute war alles in Ordnung, und das ist schon seit mehreren Jahren so!

Wie dem auch sei, ich habe den Server heute neugestartet (CentOS 7) und er ging in den "Notfallmodus". Nach der Überprüfung journalctrlwaren folgende Einträge vorhanden:

Feb 01 13:04:45 CentOS7 systemd[1]: Mounting /mnt/data...
Feb 01 13:04:45 CentOS7 mount[819]: mount: /dev/md126 is already mounted or /mnt/data busy
Feb 01 13:04:45 CentOS7 systemd[1]: Failed to mount /mnt/data.

Wenn ich jedoch die Zeile entferne /etc/fstabund neu starte (wodurch der Computer normal startet), die Zeile dann erneut eingebe und ausführe, mount -awird die Bereitstellung ordnungsgemäß durchgeführt.

Gibt es einen Grund, warum der Bootvorgang fehlschlägt?

Ich habe errors=continueder Zeile eine Option hinzugefügt /etc/fstab, die einen Neustart im Notfallmodus verhindert (und seltsamerweise das Laufwerk trotzdem mountet – vermutlich in einem späteren Schritt), aber da es andere Mounts gibt, die ich beim Booten ausführen möchte und die davon abhängen, dass dieses zuerst gemountet wurde, würde ich wirklich gerne eine richtige Lösung finden.

Antwort1

Ohne die fstab-Datei kann ich nicht viel sagen, aber wenn das Mounten einer Festplatte fehlschlägt, wechselt das System in den Notfallmodus.
Sie können dies verhindern, indem Sie die Option nofail hinzufügen. Dadurch wird die Festplatte NICHT gemountet und der Bootvorgang wird trotzdem fortgesetzt, wenn beim Mounten ein Fehler auftritt.

Eine häufige Ursache für diesen Fehler ist die Referenzierung einer Festplatte als /dev/sdX. Wenn andere Festplatten angeschlossen sind, kann dies zu einem Versuch führen, eine andere Festplatte zu mounten, was aufgrund bestimmter Optionen fehlschlagen kann.

Möglicherweise kann ich Ihnen weitere Einzelheiten mitteilen, wenn Sie eine fstab-Datei bereitstellen.

Antwort2

Dafür kann es verschiedene Gründe geben:

  • /etc/mtabimmer noch vorhanden, da vorher kein ordnungsgemäßes Herunterfahren erfolgte?

  • /dev/md128ist tatsächlich schon in ein anderes Verzeichnis gemountet?

  • etwas anderes ist montiert/mnt/data

Am besten lassen Sie das System hochfahren (z. B. indem Sie das Root-Passwort eingeben, wenn Sie dazu aufgefordert werden) und prüfen, was passiert. Die Ausgabe des mountBefehls wäre hilfreich.

verwandte Informationen