Mi Ubuntu ejecuta fsck en cada arranque


19

En cada arranque es lo mismo:

/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks

¿Es algún tipo de opción que Ubuntu utiliza para garantizar la coherencia del sistema de archivos o hay algún problema con mi HDD? fscktoma hasta 30 segundos durante el arranque y, por lo tanto, triplica el tiempo necesario de lo contrario.

Salida completa (en parte en alemán):

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
fsck von util-linux 2.20.1
/dev/sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke
udevd[623]: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/45-libticables.rules:6

udevd[623]: invalid rule '/lib/udev/rules.d/45-libticables.rules:6'

 * Starting mDNS/DNS-SD daemon                                                 [ OK ]
 * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated                                                                   [ OK ]
 * Starting configure network device security                                  [ OK ]
 * Starting bluetooth daemon                                                   [ OK ]
 ####* Starting all other stuff

¿Qué versión de Ubuntu estás ejecutando? ¿Su sistema se apaga limpiamente?
ubfan1

Raring x64 = 13.04 64bit. El apagado se ejecuta limpiamente hasta donde puedo decir (¿Dónde está el archivo de registro de apagado?)
s3lph

1
fsck dice que no se ejecutó, que el volumen estaba limpio.
psusi

Pero el componente de comprobación tiene que ejecutarse para decir que está limpio, ¿no?
s3lph

Respuestas:


25

/ dev / sda1: clean, 908443/38690816 archivos, 44176803/154733312 bloques

La línea que produce ese mensaje es esta :

/* Print the summary message when we're skipping a full check */
log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),

Se salta el "chequeo completo" pero solo se aseguró de que alguna prueba rápida del diario esté limpia y no haya inodos huérfanos:

cat /var/log/boot.log 
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
/dev/sda1: clean, 260598/771552 files, 1684682/3080192 blocks
/dev/sdb10: recovering journal
/dev/sdb10: Clearing orphaned inode 142568 (uid=1000, gid=1000, mode=0100664, size=32768)
/dev/sdb10: Clearing orphaned inode 138527 (uid=1000, gid=1000, mode=0100600, size=9580)
/dev/sdb10: clean, 54957/991232 files, 3498365/3958006 blocks

Esto es normal y esperado. Si se tratara de una verificación minuciosa, llevaría mucho más tiempo, pero generalmente lleva un segundo o menos. La systemd-fsck(8)página del manual de Systemd tiene las condiciones en las que se activa una verificación completa:

systemd-fsck-root.service es responsable de las verificaciones del sistema de archivos en el sistema de archivos raíz, pero solo si el sistema de archivos raíz no se verificó en initramfs. systemd-fsck @ .service se utiliza para todos los demás sistemas de archivos y para el sistema de archivos raíz en initramfs.

Estos servicios se inician en el arranque si passno en / etc / fstab para el sistema de archivos se establece en un valor mayor que cero. La verificación del sistema de archivos para root se realiza antes que los otros sistemas de archivos. Se pueden verificar otros sistemas de archivos en paralelo, excepto cuando están en el mismo disco giratorio.

systemd-fsck no conoce ningún detalle sobre sistemas de archivos específicos, y simplemente ejecuta verificadores del sistema de archivos específicos para cada tipo de sistema de archivos (/sbin/fsck.*). Este asistente decidirá si el sistema de archivos se debe verificar en función del tiempo transcurrido desde la última verificación, el número de montajes, el desmontaje no limpio, etc.

Simplemente puede verificar que las pruebas casi no se ejecutaron (si usa systemd):

sudo systemd-analyze blame | grep fsck
          1.608s systemd-fsck@dev-disk-by\x2duuid-408535fe\x2d28e6\x2d4d82\x2dbb59\x2d9810ead089a3.service
            87ms systemd-fsck@dev-mapper-vlhome\x2dlvhome.service

Una respuesta a la q en su enlace dice que puede controlar el comportamiento modificando /etc/fstab. ¿Solo es posible configurar 0o 1puedo decirle a mi sistema cuándo realizar esta prueba "rápida"?
s3lph

@the_Seppi no, no puedes desactivar el fsck en el fstab pero el orden, esta otra respuesta mía lo explica, solo léelo al final.
Braiam

Leí que cambiar el último dígito a 0 deshabilita fsck en el montaje
s3lph

@the_Seppi, sí, tiene razón 1y 2determina el orden que se va a verificar, pero 0ninguno dice que no es necesario. Pero luego tengo ambos valores en 0 y todavía recibo el cheque.
Braiam

2
Hay un error reportado en el launchpad: error de arranque # 1504688 . Contiene una posible solución en el comentario # 17 .
azurkin

1

¿Estás seguro de que es fsck lo que está tardando 30 segundos y no solo que el siguiente mensaje de consola relacionado con udevd tarda 30 segundos? En otras palabras, ¿tal vez el udevd tarda 30 segundos en agotar el tiempo de trabajo en lo de libticables antes de mostrar un mensaje de consola?

Intenta eliminarlo (o mudarte a otro lugar temporalmente)

/lib/udev/rules.d/45-libticables.rules

y ver si eso ayuda.


No, definitivamente es fsck. El Running /scripts/init-bottom ...donese imprime a aproximadamente 3 segundos, el fsck-clean a unos 30 segundos.
s3lph

¿Qué tipo de sistema de archivos estás usando?
Joseph Santaniello

Estoy usando EXT4
s3lph

¿Es la pausa antes de imprimir "fsck von ..." o antes de "/ dev / sda ..."?
Joseph Santaniello

¿Dónde estás montando / dev / sda1? Puede intentar agregar: noauto,x-systemd.automounta las opciones de fstab si es / home o algo así. Por lo tanto, el sistema omitirá el montaje hasta que se acceda según: wiki.archlinux.org/index.php/Systemd#Automount
Joseph Santaniello

0

Este fsck en cada arranque me sucedió debido a un mal reloj. Parece que systemd-fsck @ se ejecuta antes de systemd-timesyncd, y sin un RTC respaldado por batería, la hora del sistema es incorrecta en el momento en que se ejecuta fsck.

Confirmé que esto es lo que desencadena la verificación completa (en lugar de hacer que fsck salga rápidamente), deshabilitando systemd-timesynd, configurando el reloj en el valor de pre-sincronización que se encuentra en journalctl y ejecutando fsck. El e2fsck luego realiza una verificación completa, una vez que detecta que el último tiempo de escritura del superbloque es en el futuro:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Superblock last write time (Mon Jun 19 00:48:11 2017,
    now = Tue Jan 31 20:09:28 2017) is in the future.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
...

Tenga en cuenta que este disparador para la verificación completa no está relacionado con los otros disparadores del conteo máximo de montaje y el intervalo de tiempo desde la última verificación, visto en dumpe2fs -h, mencionado en otras respuestas aquí.

Tenga en cuenta que, sin configurar el reloj (es decir, dejar que Timesyncd lo sincronice), fsck no realizará una verificación completa, sino que saldrá rápidamente con un mensaje de "sistema de archivos limpio".

Como solución alternativa, deshabilité fsck en / etc / fstab estableciendo el campo 'pass' en 0. Eventualmente, compraré un RTC respaldado por batería para este dispositivo.


-1

Mis búsquedas me llevan a la conclusión de que el conteo de montaje máximo predeterminado de Ubuntu está establecido en -1. Esto significa que fsck nunca se ejecutará en ningún arranque, independientemente del número de montajes. Puede verificar el suyo por comando -

sudo dumpe2fs -h /dev/sda8 | grep -i 'mount count'

Puede aumentarlo según sus necesidades utilizando tune2fs. Un ejemplo típico es el siguiente:

sudo tune2fs -c 30 -i 1w /dev/sda8

Personalízalo según tu acuerdo.


1
No, eso significa que el kernel y e2fsck no tendrán en cuenta el valor: linux.die.net/man/8/tune2fs "Si max-mount- count es 0 o -1, la cantidad de veces que se monta el sistema de archivos no se tendrá en cuenta por e2fsck (8) y el núcleo ".
HappyCactus

Mi mal, cambiará de publicación.
Vivek Ji
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.