Jak mogę uniknąć komunikatów „Uruchom ręcznie fsck”, umożliwiając eksperymentowanie ze zmianami czasu systemowego?

18

Pracuję z systemem, w którym chcemy pozwolić użytkownikom na zabawę z datą i godziną, jeśli chcą, i gdzie ponowne uruchomienie może nastąpić dowolnie. Jest to w porządku, z wyjątkiem jednej rzeczy: jeśli następuje duży skok w tył, podczas ponownego uruchamiania pojawia się następujący błąd:

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.

… A następnie rozruch zawiesza się, czekając na dane wejściowe konsoli użytkownika, a nawet po uzyskaniu dostępu do konsoli wymaga hasła roota, aby kontynuować.

Jest to zdecydowanie mniej niż idealne. Czy jest jakiś sposób, aby pominąć czek lub zmusić go do automatycznego wykonania po ponownym uruchomieniu?

Google zapewnił tylko pomoc, która wymaga ręcznego uruchomienia fsck, jeśli / kiedy zostanie on trafiony, a nie o to mi chodzi. Ręczne uruchamianie fsck po ustawieniu czasu nie działa, ponieważ system plików jest nadal montowany w tym momencie, a samo wyłączenie fsck jest mniej niż idealne.

Używam RedHat 6.

Aktualizacja : Rozwiązaniem, z którego obecnie korzystam, jest zhakowanie fstab, aby wyłączyć sprawdzanie fsck przy ponownym uruchomieniu. Próbowałem edytować ostatni czas montowania na dyskach debugfs, co działa dobrze w przypadku dysków ext3, ale wydaje się, że zawiesza się niekonsekwentnie na ext4.

— ja i
źródło

15

Zamierzałem zasugerować hakowanie, e2fsckaby wyłączyć szczegółowe kontrole ostatniego czasu montowania lub ostatniego zapisu w przyszłości. Są one zdefiniowane w problem.c / problem.h i używane w super.c . Ale patrząc, odkryłem, że E2fsprogs 1.41.10 dodaje nową opcję o /etc/e2fsck.confnazwie broken_system_clock . Wydaje się, że jest to dokładnie to, czego potrzebujesz, a ponieważ używasz Red Hat Enterprise Linux 6, powinieneś mieć wersję 1.41.12, która zawiera tę opcję. Ze strony podręcznika:

   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.

Tak, strona man nie może przeliterować „heurystyki”. Ups Ale przypuszczalnie kod i tak działa. :)

— mattdm
źródło

To wygląda fantastycznie, z wyjątkiem tego, że strona podręcznika sugeruje, że wpływa tylko na ext2 i ext3, a ja używam kombinacji ext3 i ext4. Mimo to spróbuję teraz, jak gdyby to działało, właśnie tego szukam.

— me_i

1

To działa! W tym na ext4. Dziękuję Ci!

— me_i

1

Wątpię, czy istnieje sposób na usunięcie tej kontroli, bez modyfikowania kodu źródłowego. Ignorowanie wszystkich błędów z fsck brzmi niebezpiecznie, co jeśli byłby jakiś inny problem?

Dlatego zasugeruję następujące obejście: zmień skrypty rozruchowe, aby ustawić datę systemową na pewien czas w przyszłości (powiedz 2038-01-18 na komputerze 32-bitowym) tuż przed uruchomieniem fsck, i odczytaj ją ze sprzętu zegar później ( hwclock --hctosysz większą liczbą opcji, zależnie od potrzeb, w zależności od sprzętu i użycia GMT w zegarze sprzętowym).

— Gilles „SO- przestań być zły”
źródło

Czy to nie znaczy, że następnym razem będzie okno, w którym możemy ponownie trafić ten sam błąd? tzn. ostatni czas montowania to 2038-01-18, więc jeśli ustawiony jest również ten czas, istnieje warunek wyścigu, w którym (jeśli chodzi o system) próbujemy zamontować przed ostatnim montowaniem ponownie.

— me_and

@me_and: Tak, obawiam się, że moja kludge nie pomoże przeciwko złośliwym użytkownikom. Jeśli tak właśnie jest, łatanie fsck wydaje się najlepszą opcją.

— Gilles 'SO - przestań być zły'

0

Wygląda na to, że powinien być uruchamiany na maszynie wirtualnej, gdzie możesz mieć większą kontrolę (lub po prostu przywrócić migawkę).

— jamespo
źródło

Uruchomienie na maszynie wirtualnej tak naprawdę nie jest dla nas opcją, aw każdym razie samo przywrócenie do migawki oznacza, że usuwamy cały inny stan, który użytkownik mógł ustawić.

— me_and

0

Oto rozwiązanie, które działało dla mnie świetnie:

Utwórz /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
}

Więcej na temat tej poprawki tutaj:

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

— GoinOff
źródło