Ubuntu esegue fsck ad ogni avvio

Ad ogni avvio è lo stesso:

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

È una sorta di opzione che Ubuntu utilizza per garantire la coerenza del filesystem o c'è qualcosa che non va nel mio HDD? fsckrichiede fino a 30 secondi durante l'avvio e quindi circa triplica il tempo necessario altrimenti.

Uscita completa (in parte in tedesco):

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

/ dev / sda1: clean, 908443/38690816 File, 44176803/154733312 Blocks

La linea che produce quel messaggio è questa :

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

Salta il "controllo completo" ma si è assicurato che alcuni test rapidi sul diario siano puliti e non ci siano inode orfani:

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

Questo è normale e previsto. Se fosse un vero e proprio controllo approfondito ci vorrebbe molto più tempo ma di solito ci vuole un secondo o meno. La systemd-fsck(8)pagina di manuale di Systemd presenta le condizioni in cui viene attivato un controllo completo:

systemd-fsck-root.service è responsabile dei controlli del file system sul file system radice, ma solo se il file system radice non è stato verificato in initramfs. systemd-fsck @ .service è usato per tutti gli altri file system e per il file system radice in initramfs.

Questi servizi vengono avviati all'avvio se passno in / etc / fstab per il file system è impostato su un valore maggiore di zero. Il controllo del file system per root viene eseguito prima degli altri file system. Altri file system possono essere controllati in parallelo, tranne quando si trovano sullo stesso disco rotante.

systemd-fsck non conosce alcun dettaglio su filesystem specifici ed esegue semplicemente i controlli del file system specifici per ciascun tipo di filesystem (/sbin/fsck.*). Questo aiutante deciderà se il filesystem debba effettivamente essere verificato in base al tempo trascorso dall'ultimo controllo, al numero di montaggi, allo smontaggio impuro, ecc.

Puoi semplicemente verificare che i test abbiano richiesto quasi nulla per l'esecuzione (se usi 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

Sei sicuro che fsck stia impiegando 30 secondi e non solo che il prossimo messaggio della console relativo a udevd impiega 30 secondi? In altre parole, forse udevd impiega 30 secondi per il timeout lavorando sulla cosa libticables prima di mostrare un messaggio console?

Prova a rimuovere (o spostare temporaneamente altrove)

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

e vedere se questo aiuta.

Questo fsck ad ogni avvio mi è successo a causa di un cattivo orologio. Sembra che systemd-fsck @ venga eseguito prima di systemd-timesyncd e senza un RTC alimentato a batteria, l'ora del sistema è errata al momento dell'esecuzione di fsck.

Ho confermato che questo è davvero ciò che innesca il controllo completo (invece di far uscire rapidamente fsck), disabilitando systemd-timesynd, impostando clock sul valore di pre-sincronizzazione trovato in journalctl ed eseguendo fsck. Quindi e2fsck procede a un controllo completo, una volta rilevato che l'ultimo tempo di scrittura del superblocco è in 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
...

Si noti che questo trigger per il controllo completo non è correlato agli altri trigger del conteggio massimo di montaggio e dell'intervallo di tempo dall'ultimo controllo, visto in dumpe2fs -h, menzionato in altre risposte qui.

Notare che, senza impostare l'orologio (ovvero, permettendo a timesyncd di sincronizzarlo), fsck non effettuerà un controllo completo, ma uscirà rapidamente con un messaggio di "pulizia del filesystem".

Come soluzione alternativa, ho disabilitato fsck in / etc / fstab impostando il campo 'pass' su 0. Alla fine, comprerò un RTC con batteria per questo dispositivo.

Le mie ricerche mi hanno portato alla conclusione che il numero massimo di mount predefinito di Ubuntu è impostato su -1. Ciò significa che fsck non verrà mai eseguito su alcun avvio, indipendentemente dal numero di montaggi. Puoi controllare il tuo per comando -

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

È possibile aumentarlo in base alle proprie esigenze utilizzando tune2fs. Un esempio tipico è il seguente:

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

Personalizzalo secondo il tuo accordo.