¿Cómo puedo evitar los mensajes "Ejecutar fsck manualmente" mientras se permite experimentar con los cambios de hora del sistema?

18

Estoy trabajando con un sistema en el que queremos permitir que los usuarios jueguen con la fecha y la hora si lo desean, y donde los reinicios pueden ocurrir arbitrariamente. Esto está bien, excepto por una cosa: si hay un gran salto de tiempo hacia atrás, aparece el siguiente error al reiniciar:

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.

... y luego el arranque se cuelga esperando la entrada de la consola del usuario, e incluso una vez que se obtiene acceso a la consola, se requiere una contraseña de root para continuar.

Esto es decididamente menos que ideal. ¿Hay alguna forma de omitir el cheque o forzar que el cheque se realice automáticamente al reiniciar?

Google solo ha proporcionado ayuda que requiere ejecutar fsck manualmente si / cuando se golpea, que no es lo que busco. Ejecutar fsck manualmente después de configurar el tiempo no funciona ya que el sistema de archivos todavía está montado en ese punto, y simplemente deshabilitar fsck por completo es menos que ideal.

Estoy usando RedHat 6.

Actualización : La solución con la que estoy trabajando actualmente es hackear fstab para deshabilitar la comprobación de fsck al reiniciar. Intenté editar el último tiempo de montaje en los discos usando debugfs, lo que funciona bien para las unidades ext3, pero parece fallar inconsistentemente en ext4.

— yo y
fuente

15

Iba a sugerir hackear e2fsckpara deshabilitar las comprobaciones específicas para un último tiempo de montaje o últimos tiempos de escritura en el futuro. Estos se definen en problem.c / problem.h , y se usan en super.c . Pero al mirar, descubrí que E2fsprogs 1.41.10 agrega una nueva opción a /etc/e2fsck.confllamada broken_system_clock . Esto parece ser exactamente lo que necesita, y dado que está utilizando Red Hat Enterprise Linux 6, debería tener 1.41.12, que incluye esta opción. Desde la página del manual:

   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 página del manual no puede deletrear "heurística". Ups Pero presumiblemente el código funciona de todos modos. :)

— mattdm
fuente

Eso se ve fantástico, salvo que la página del manual implica que solo afecta a ext2 y ext3, y estoy usando una combinación de ext3 y ext4. Aún así, lo intentaré ahora, como si funcionara, es exactamente lo que estoy buscando.

— yo_y

1

¡Funciona! Incluido en ext4. ¡Gracias!

— yo_y

1

Dudo que haya una manera de eliminar esta verificación específicamente, sin modificar el código fuente. Ignorar todos los errores de fsck suena peligroso, ¿y si hubiera algún otro problema?

Por lo tanto, sugeriré la siguiente solución: cambie los scripts de arranque para establecer la fecha del sistema en algún momento en el futuro (digamos 2038-01-18 en una máquina de 32 bits) justo antes de ejecutar fsck, y léalo desde el hardware reloj posterior ( hwclock --hctosyscon más opciones según sea necesario según su hardware y el uso de GMT en el reloj de hardware).

— Gilles 'SO- deja de ser malvado'
fuente

¿No significaría esto la próxima vez que habría una ventana en la que podríamos encontrar el mismo error nuevamente? es decir, el último tiempo de montaje es 2038-01-18, por lo que si el tiempo actual también se ajusta a eso, hay una condición de carrera en la que estamos (en lo que respecta al sistema) tratando de montar antes del último montaje nuevamente.

— yo_y el

@me_and: Sí, me temo que mi kludge no ayudará contra usuarios malintencionados. Si eso es a lo que te enfrentas, parchar fsck parece ser la mejor opción.

— Gilles 'SO- deja de ser malvado'

0

Parece que debería ejecutarse en una máquina virtual, donde puede tener más control (o simplemente volver a una instantánea).

— jamespo
fuente

Ejecutar en una máquina virtual realmente no es una opción para nosotros, y en cualquier caso, volver a una instantánea significa que eliminamos todos los demás estados que el usuario haya configurado.

— yo_y el

0

Aquí hay una solución que funcionó muy bien para mí:

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

Más sobre esta solución aquí:

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

— GoinOff
fuente