Booten auf entfernter Maschine sichern

13/11/2011 - 16:57 von Andreas Kohlbach | Report spam
Ich habe einen entfernten, nicht wirklich produktiven, Linux (Ubuntu
Oneiric, wo ich das Upgrade schon durchlaufen ließ, aber noch nicht
bootete) Server, wo neben dem Upgrade auch schon einige Kernel-Updates
ins Land gingen. Das letzte Mal gebootet hatte ich im Sommer (Uptime
etwas um 60 Tage).

Ich werde beim Einloggen via ssh auch schon seit langem mit

*** /dev/sda1 will be checked for errors at next reboot ***

begrüßt. Auch wenn es keine (sichtbaren) Probleme mit dem Dateisystem
(ext3) gibt, will er das ja immer nach einigen Tagen Uptime machen.

Ich will sicher stellen, dass er sauber durch bootet, und nicht
ggf. einen Einlog-Prompt wirft, um Dinge manuell fixen zu müssen. Dabei
ist es eher zweitrangig, ob das in einem "etwas" kaputten Dateisystem
endet, solange er nur bootet und ich remote-access danach habe. Sonst
müsste ich erst dort hin, was mit Kosten und Zeit verbunden ist.

Ich könnte mir drei Szenarios vorstellen:

1. shutdown mit -r -f (Skip fsck on reboot), falls er das überhaupt
macht, dass gar nicht gecheckt wird.

2. Versuchen, e2fsck am laufenden System zu machen, um zumindest zu sehen,
ob es Probleme geben könnte. Da er gebootet ist, kann ich ja "helfen",
wenn er es allein nicht schafft. Zumindest aber vielleicht Hinweise
bekommen, ob es Probleme geben würde.

3. Das Checken und ggf. Reparieren ohne jegliches Zutun meinerseits
erzwingen. Geht das überhaupt?

Ich finde in der e2fsck man page:

-p Automatically repair ("preen") the file system. This option
will cause e2fsck to automatically fix any filesystem problems
that can be safely fixed without human intervention. If e2fsck
discovers a problem which may require the system administrator to
take additional corrective action, e2fsck will print a
description of the problem and then exit with the value 4
logically or'ed into the exit code. (See the EXIT CODE section.)
This option is normally used by the system's boot scripts. It
may not be specified at the same time as the -n or -y options.

Das sieht nicht gut aus. Und was ist mit "or'ed into the exit code"
gemeint?

Ich würde den 2. Punkt hier favorisieren.
Andreas
Linux: The choice of a GNU generation.
 

Lesen sie die antworten

#1 Christoph Mehdorn Weber
13/11/2011 - 17:34 | Warnen spam
Hallo!

* Andreas Kohlbach :

2. Versuchen, e2fsck am laufenden System zu machen, um zumindest zu sehen,
ob es Probleme geben könnte.



Falls du mit "mount -o remount,ro /" Erfolg hast, kannst du
danach relativ problemlos einen fsck im laufenden Betrieb machen.

3. Das Checken und ggf. Reparieren ohne jegliches Zutun meinerseits
erzwingen. Geht das überhaupt?



Mein Debian kennt die Variable "FSCKFIX" in "/etc/default/rcS",
mit der man das erzwingen kann. Aus der Manpage:

| When the root and all other file systems are checked, fsck is
| invoked with the -a option which means "autorepair". If there
| are major inconsistencies then the fsck process will bail out.
| The system will print a message asking the administrator to
| repair the file system manually and will present a root shell
| prompt (actually a sulogin prompt) on the console. Setting this
| option to yes causes the fsck commands to be run with the -y
| option instead of the -a option. This will tell fsck always to
| repair the file systems without asking for permission.

Christoph

Kino ohne Popcorn ist wie Salz ohne Suppe.
(Volker Birk)

Ähnliche fragen