Fuerza fsck.ext4 al reiniciar, pero realmente "contundente"

21

Uno de mis servidores Ubuntu 10.04 me está dando problemas. Cuando ejecuto fsck.ext4 -n /dev/sda5me dice que hay errores en el recuento de inodo libre, el recuento de bloque libre y más.

Yo he tratado:

touch /forcefsck

También probé:

shutdown -rF now

y aún así, después de reiniciar, veo errores.

¡También acabo de revisar mi netbook eeePC, Ubuntu 10.10, y tengo el mismo problema!

¿Cómo puedo forzar un "fsck" del sistema de archivos "/" realmente "forzado" "contundente" en el reinicio?

Aclaración: ejecuto fsck.ext4 -nporque es un sistema de archivos montado, para verificar si hay errores. Esto me dice que los hay. Pensé que el fsck automático cada 30 montajes durante el proceso de arranque es precisamente para ocuparse de los errores en el sistema de archivos raíz. Pero no lo hace en mi caso. Podría reiniciar con un LiveCD y corregir los errores, y luego reiniciar nuevamente, pero eso es un tiempo de inactividad serio para un servidor en vivo. Un reinicio, fsck automático, luego continuar el arranque es mucho más sostenible en un servidor en vivo, y creo que debería ser el comportamiento correcto.

Información adicional: Aquí está la salida. Parece algo que el autofsck solucionaría, ¿no?

root@server:~# fsck.ext4 -n /dev/sda5
e2fsck 1.41.11 (14-Mar-2010)
Warning!  /dev/sda5 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sda5 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1849368, counted=1948909).
Fix? no

Free inodes count wrong (545504, counted=552134).
Fix? no


/dev/sda5: ********** WARNING: Filesystem still has errors **********

/dev/sda5: 116752/662256 files (0.2% non-contiguous), 795324/2644692 blocks
10.04 filesystem ext4 fsck UrkoM
fuente
¿Cuál es la versión del servidor Ubuntu que está utilizando?
crncosta
10.04. Editaré mi pregunta.
UrkoM
No creo que puedas hacer eso, de hecho, es mejor que hagas la verificación manualmente.
RolandiXor
1
Lo siento pero aún necesito más información. ¿Estás haciendo fsck en sistemas de archivos montados? ¿puede arrancar desde un LiveCD y verificar nuevamente (con su / dev / sda5 desmontado)?
crncosta
¿No es posible que no esté el sistema de archivos sino el disco duro roto? En cuyo caso, se esperaría que ext4 no corrija los errores tan bien como lo haría con algunos sectores defectuosos.
Stefano Palazzo

Respuestas:

10

Desde la página de manual de e2fsck:

"Tenga en cuenta que, en general, no es seguro ejecutar e2fsck en sistemas de archivos montados. La única excepción es si se especifica la opción -n y no se especifican las opciones -c, -l o -L. Sin embargo, incluso si es seguro para hacerlo, los resultados impresos por e2fsck no son válidos si el sistema de archivos está montado. Si e2fsck pregunta si debe o no verificar un sistema de archivos que está montado, la única respuesta correcta es "no". Solo los expertos que realmente saben qué lo que están haciendo debería considerar responder esta pregunta de cualquier otra manera ".

Por lo tanto, si comprueba un FS montado con fsck incluso utilizando la opción -n, el resultado puede no ser válido en absoluto. No verifique los sistemas de archivos montados. Use un Live-CD / Live-USB.

Si no verifica el sistema de archivos mientras está montado, no entiendo por qué necesita usarlo touch /forcefsck, simplemente puede desmontarlo y arreglarlo. Pero si es el caso y después de una corrección, su FS todavía tiene errores, entonces puede considerar usar:

e2fsck -cy /dev/sda5

Eso solucionará un problema relacionado con el disco duro llamado bloques defectuosos que pueda tener (esto llevará mucho tiempo).

Si desea verificar un sistema de archivos montado, no sé cómo proceder, pero creo que debería crear otra pregunta.

Nyamiou The Galeanthrope
fuente
Tienes razón, el sistema de archivos está montado. Y, por supuesto, necesito hacer fsck cuando esté desmontado. Pero ejecuto fsck -n para verificar mientras estoy montado, sin hacer cambios, y me dice que hay errores. ¿Y no debería el fsck en el reinicio arreglarlos?
UrkoM
Acabo de notar lo que dices en la primera oración: ¿por qué fsck -n no sería válido en un sistema de archivos montado? ¿Cómo puedo verificar si un sistema de archivos montado tiene errores de manera confiable?
UrkoM
Puede consultar la página de manual de e2fsck que dice: "Tenga en cuenta que, en general, no es seguro ejecutar e2fsck en sistemas de archivos montados. La única excepción es si se especifica la opción -n, y las opciones -c, -l o -L son no especificado. Sin embargo, incluso si es seguro hacerlo, los resultados impresos por e2fsck no son válidos si el sistema de archivos está montado. Si e2fsck pregunta si debe verificar o no un sistema de archivos que está montado, la única respuesta correcta es '' no ''. Solo los expertos que realmente saben lo que están haciendo deberían considerar responder esta pregunta de otra manera ".
Nyamiou The Galeanthrope
No sé cómo verificar un sistema de archivos montado, tal vez debería crear otra pregunta.
Nyamiou The Galeanthrope
¿Puedes agregar esos dos últimos comentarios a tu respuesta? Entonces lo aceptaré. No lo sabía, así que es por eso ... Creo que es porque fsck -n no procesa el diario, por lo que el estado del sistema de archivos es inconsistente sin mirar los últimos cambios guardados allí.
UrkoM
24

Sé que este es un hilo muy antiguo, pero recientemente tuve que resolver este problema, así que quería publicar cómo obligar al sistema operativo a solucionar los problemas encontrados con fsck durante el arranque (para 12.04).

Necesitas ejecutar el comando sudo touch /forcefsck. Esto hará que realice un fsck en el próximo arranque. Puede ver los resultados del fsck en /var/log/boot.log.

Sin embargo, no está garantizado que fsck arregle todo lo que encuentre. Para hacer esto, necesitaría editar el archivo / etc / default / rcS. Hay una línea al final de ese archivo:

FSCKFIX=no

Esto debe cambiarse a lo siguiente:

FSCKFIX=yes

Esto tendrá el mismo efecto que ejecutar fsck con la opción -y que forzará todas las correcciones que se pueden implementar y no solicitará la interacción del usuario.

Esto le permitirá ejecutar el fsck como lo pedía el OP sin tener que recurrir al arranque desde un disco en vivo que no siempre es posible, especialmente si está en un sistema remoto.

Brian
fuente
1
La edición de esta entrada en mi instancia de Ubuntu EC2 junto con los comandos sudo touch /forcefscky sudo shutdown -rresolvió con éxito los problemas del sistema de archivos y la advertencia de verificación al iniciar sesión. Fácil y no disruptivo - aplausos.
c.gutierrez
La misma pregunta se hizo en Server Fault, y esta respuesta también fue la que funcionó para mí, en un sistema Ubuntu 14.04. Simplemente hacer el sudo touch /forcefscky luego reiniciar no lo hizo; la edición rcSfue necesaria.
Teemu Leisti
12 
sudo touch /forcefsck
sudo reboot

Tienes un error tipográfico, estás tocando / forcefcsk. La "c" y la "s" se intercambian. fsck es la abreviatura de FileSystemChecK.

Dan Benamy
fuente
¡Esto no funcionaría para mí porque el sistema de archivos raíz está montado de solo lectura debido a errores que debo solucionar fsck! El problema del huevo y la gallina que solo se puede resolver a través de liveCD o arrastrando el disco a otra máquina.
HDave
3

No puede forzar un fsck en / que reparará porque la partición está en uso. Intente ejecutar la verificación desde una partición diferente o un CD en vivo.

charlie-tca
fuente
2
Muy cierto, pero el fsck automático en el arranque debe ocurrir antes de que la partición esté en uso, precisamente para poder corregir errores en "/". De lo contrario, ¿cuál es el punto?
UrkoM el
3
Creo que la verificación se realiza antes del uso, sin embargo, es más una verificación de asesoramiento. Depende de usted decidir cómo corregir los errores. Una verificación fácil es cuando se mira / etc / fstab. El "/" obtiene una comprobación diferente que las otras particiones.
charlie-tca
¿Sucede antes de que se gire la raíz? es decir. Disco RAM inicial.
mckenzm
1

Puede realizar las revisiones automáticamente de la siguiente manera:

Tune2fs -c 5 -i 10 / dev / sda1

-ces el número máximo de montajes antes de ejecutarse fscky -ies el número máximo de días antes de ejecutarse fsck.

En este caso se realizará cada 5 montajes o cada 10 días, lo que ocurra primero.

Tengo dos computadoras, una con Linux SuSE 13.2 y la otra con Linux Mint 18.0 y en ambas funciona perfectamente.

hk3jld
fuente
¿Cuáles son los formularios y comentarios en el formulario automático de la siguiente manera: Tune2fs -c 5 -i 10 / dev / sda1 Donde: -c es el número máximo de montajes antes de ejecutar fsck Donde: -i es el número máximo de días antes de ejecutar fsck En este caso se realizará cada 5 montajes o cada 10 días, lo que ocurra primero. Tengo dos computadoras, una con Linux SuSE 13.2 y la otra con Linux MInt 18.0 y ambas funcionan perfectamente.
hk3jld
¿Cuáles son los formularios y comentarios en el formulario automático de la siguiente manera: Tune2fs -c 5 -i 10 / dev / sda1 Donde: -c es el número máximo de montajes antes de ejecutar fsck Donde: -i es el número máximo de días antes de ejecutar fsck En este caso se realizará cada 5 montajes o cada 10 días, lo que ocurra primero. Tengo dos computadoras, una con Linux SuSE 13.2 y la otra con Linux MInt 18.0 y ambas funcionan perfectamente. No sé inglés pero utilizo un traductor, espero que la capacitación esté bien
hk3jld
1
¿Funciona también en Ubuntu?
George Udosen