Wie kann ich vermeiden, dass Meldungen wie "fsck manuell ausführen" angezeigt werden, während ich mit Systemzeitänderungen experimentiere?

18

Ich arbeite mit einem System, bei dem Benutzer nach Belieben mit Datum und Uhrzeit herumspielen können und bei dem Neustarts willkürlich erfolgen können. Dies ist in Ordnung, abgesehen von einer Sache: Wenn es einen großen Zeitsprung nach hinten gibt, wird beim Neustart der folgende Fehler angezeigt:

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

… Und dann bleibt der Start hängen und wartet auf Benutzerkonsolen-Eingaben. Selbst wenn der Konsolenzugriff erfolgt ist, muss ein Root-Kennwort eingegeben werden, um fortzufahren.

Dies ist entschieden weniger als ideal. Gibt es eine Möglichkeit, die Überprüfung zu überspringen oder zu erzwingen, dass sie beim Neustart automatisch ausgeführt wird?

Google hat nur Hilfe bereitgestellt, bei der fsck manuell ausgeführt werden muss, wenn / wenn dies getroffen wird. Dies ist nicht das, wonach ich suche. Manuelles Ausführen von fsck nach dem Einstellen der Zeit funktioniert nicht, da das Dateisystem zu diesem Zeitpunkt noch gemountet ist und nur das vollständige Deaktivieren von fsck nicht optimal ist.

Ich benutze RedHat 6.

Update : Die Lösung, mit der ich derzeit arbeite, ist, fstab zu hacken, um die fsck-Prüfung beim Neustart zu deaktivieren. Ich habe versucht, die letzte Bereitstellungszeit auf den Datenträgern mit zu bearbeiten debugfs, was für ext3-Laufwerke gut funktioniert, auf ext4 jedoch inkonsistent zu scheitern scheint.

— ich und
quelle

15

Ich wollte Hacking vorschlagen e2fsck, um die spezifischen Überprüfungen für eine letzte Ladezeit oder die letzten Schreibzeiten in der Zukunft zu deaktivieren. Diese werden in definierten problem.c / problem.h und verwendet in super.c . Bei der Suche habe ich festgestellt, dass E2fsprogs 1.41.10 eine neue Option /etc/e2fsck.confnamens broken_system_clock hinzufügt . Dies scheint genau das zu sein, was Sie brauchen, und da Sie Red Hat Enterprise Linux 6 verwenden, sollten Sie 1.41.12 haben, das diese Option enthält. Von der Manpage:

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

Ja, die Manpage kann "Heuristik" nicht buchstabieren. Hoppla. Aber vermutlich funktioniert der Code trotzdem. :)

— mattdm
quelle

Das sieht fantastisch aus, außer dass die Manpage impliziert, dass es nur ext2 und ext3 betrifft, und ich verwende eine Kombination aus ext3 und ext4. Trotzdem werde ich es jetzt versuchen, als ob es funktioniert, es ist genau das , wonach ich suche.

— me_and

1

Es klappt! Einschließlich auf ext4. Vielen Dank!

— me_and

1

Ich bezweifle, dass es eine Möglichkeit gibt, diese Prüfung zu entfernen, abgesehen von der Änderung des Quellcodes. Alle Fehler von fsck zu ignorieren klingt gefährlich. Was, wenn es ein anderes Problem gab?

Daher schlage ich die folgende Problemumgehung vor: Ändern Sie die Boot-Skripte, um das Systemdatum auf einen späteren Zeitpunkt zu setzen (z. B. 2038-01-18 auf einem 32-Bit-Computer), bevor Sie fsck ausführen, und lesen Sie es von der Hardware zurück Uhr danach ( hwclock --hctosysmit mehr Optionen je nach Hardware und Verwendung von GMT in der Hardware-Uhr)

— Gilles 'SO - hör auf böse zu sein'
quelle

Würde dies nicht bedeuten, dass es beim nächsten Mal ein Fenster geben würde, in dem wir den gleichen Fehler erneut finden könnten? dh die letzte Mount-Zeit ist 2038-01-18. Wenn also auch die aktuelle Zeit darauf eingestellt ist, gibt es eine Race-Bedingung, in der wir (soweit es das System betrifft) versuchen, vor dem letzten Mount erneut zu mounten.

— me_and

@me_and: Ja, leider hilft mein Kludge nicht gegen böswillige Benutzer. Wenn Sie dagegen sind, scheint es die beste Option zu sein, fsck zu patchen.

— Gilles 'SO - hör auf böse zu sein'

0

Dies hört sich so an, als ob es in einer virtuellen Maschine ausgeführt werden sollte, in der Sie mehr Kontrolle haben (oder einfach zu einem Snapshot zurückkehren können).

— jamespo
quelle

Das Ausführen in einer VM ist für uns keine Option, und in jedem Fall bedeutet das Zurücksetzen auf einen Snapshot, dass alle anderen vom Benutzer eingerichteten Zustände entfernt werden.

— me_and

0

Hier ist eine Lösung, die für mich großartig funktioniert hat:

Erstellen Sie /etc/e2fsck.conf:

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}

Mehr zu diesem Fix hier:

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html

— GoinOff
quelle