Come posso evitare i messaggi "Esegui fsck manualmente" consentendo allo stesso tempo di sperimentare le modifiche all'ora del sistema?

18

Sto lavorando con un sistema in cui vogliamo consentire agli utenti di giocare con la data e l'ora, se lo desiderano, e dove i riavvii possono avvenire in modo arbitrario. Questo va bene, tranne una cosa: se c'è un grande salto all'indietro, al riavvio appare il seguente errore:

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.

... e quindi l'avvio si blocca in attesa dell'input della console dell'utente e, anche una volta ottenuto l'accesso alla console, richiede una password di root per continuare.

Questo è decisamente meno che ideale. Esiste un modo per saltare il controllo o forzare l'esecuzione automatica del controllo al riavvio?

Google ha fornito solo assistenza che richiede l'esecuzione manuale di fsck se / quando viene colpito, il che non è ciò che sto cercando. L'esecuzione manuale di fsck dopo aver impostato l'ora non funziona in quanto il filesystem è ancora montato a quel punto e disabilitare solo fsck è tutt'altro che ideale.

Sto usando RedHat 6.

Aggiornamento : la soluzione che sto attualmente cercando è di hackerare fstab per disabilitare il controllo di fsck al riavvio. Avevo provato a modificare l'ultima volta di montaggio sui dischi usando debugfs, che funziona bene con le unità ext3, ma sembra non riuscire in modo incoerente su ext4.

— io e
fonte

15

Stavo per suggerire l'hacking e2fsckper disabilitare i controlli specifici per un ultimo periodo di mount o gli ultimi tempi di scrittura in futuro. Questi sono definiti in problem.c / problem.h e utilizzati in super.c . Ma guardando, ho scoperto che E2fsprogs 1.41.10 aggiunge una nuova opzione al /etc/e2fsck.confcosiddetto broken_system_clock . Questo sembra essere esattamente ciò di cui hai bisogno e dal momento che stai usando Red Hat Enterprise Linux 6, dovresti avere 1.41.12, che include questa opzione. Dalla pagina man:

   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.

Sì, la pagina man non può contenere "euristica". Ops. Ma presumibilmente il codice funziona comunque. :)

— mattdm
fonte

Sembra fantastico, a parte il fatto che la pagina man implica che interessa solo ext2 ed ext3, e sto usando una combinazione di ext3 ed ext4. Tuttavia, ora vado a provarlo, come se funzionasse, è esattamente quello che sto cercando.

— me_e il

1

Funziona! Incluso su ext4. Grazie!

— me_e il

1

Dubito che ci sia un modo per rimuovere questo controllo nello specifico, a parte la modifica del codice sorgente. Ignorare tutti gli errori di fsck sembra pericoloso, e se ci fosse qualche altro problema?

Pertanto suggerirò la seguente soluzione alternativa: modificare gli script di avvio per impostare la data del sistema in futuro (diciamo 2038-01-18 su una macchina a 32 bit) poco prima di eseguire fsck e rileggerlo dall'hardware orologio successivo ( hwclock --hctosys, con più opzioni in base all'hardware e all'utilizzo di GMT nell'orologio hardware).

— Gilles 'SO- smetti di essere malvagio'
fonte

Ciò non significherebbe la prossima volta che ci sarebbe una finestra in cui potremmo colpire di nuovo lo stesso bug? vale a dire che l'ultimo tempo di montaggio è 2038-01-18, quindi se anche l'ora corrente è impostata su quella, c'è una condizione di competizione in cui (per quanto riguarda il sistema interessato) stiamo provando a montare di nuovo prima dell'ultimo montaggio.

— me_e il

@me_and: Sì, temo che il mio Kludge non aiuti contro gli utenti malintenzionati. Se questo è ciò che stai affrontando, patchare fsck sembra essere l'opzione migliore.

— Gilles 'SO- smetti di essere malvagio' il

0

Sembra che dovrebbe essere eseguito in una macchina virtuale, dove puoi avere un maggiore controllo (o semplicemente tornare a un'istantanea).

— jamespo
fonte

L'esecuzione in una macchina virtuale non è in realtà un'opzione per noi, e in ogni caso il solo ripristino di un'istantanea significa che rimuoviamo tutti gli altri stati che l'utente potrebbe aver impostato.

— me_e il

0

Ecco una soluzione che ha funzionato alla grande per me:

Crea /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
}

Maggiori informazioni su questa correzione qui:

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

— GoinOff
fonte