Meu Ubuntu está executando o fsck em cada inicialização

Em cada inicialização é o mesmo:

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

É algum tipo de opção que o Ubuntu usa para garantir a consistência do sistema de arquivos ou há algo errado com o meu disco rígido? fsckleva até 30 anos durante a inicialização e, portanto, triplica o tempo necessário.

Saída total (parcialmente em alemão):

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 arquivos, 44176803/154733312 blocos

A linha que produz essa mensagem é esta :

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

Ele ignora a "verificação completa", mas garante que alguns testes rápidos para o diário estejam limpos e que não haja inodes órfãos:

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

Isso é normal e esperado. Se fosse uma verificação completa, levaria muito mais tempo, mas geralmente levaria um segundo ou menos. A systemd-fsck(8)página de manual do Systemd possui as condições em que uma verificação completa é acionada:

systemd-fsck-root.service é responsável pelas verificações do sistema de arquivos no sistema de arquivos raiz, mas apenas se o sistema de arquivos raiz não tiver sido verificado no initramfs. systemd-fsck @ .service é usado para todos os outros sistemas de arquivos e para o sistema de arquivos raiz no initramfs.

Esses serviços são iniciados na inicialização se o passno em / etc / fstab para o sistema de arquivos estiver definido como um valor maior que zero. A verificação do sistema de arquivos para raiz é realizada antes dos outros sistemas de arquivos. Outros sistemas de arquivos podem ser verificados em paralelo, exceto quando estiverem no mesmo disco rotativo.

systemd-fsck não conhece nenhum detalhe sobre sistemas de arquivos específicos e simplesmente executa verificadores de sistema de arquivos específicos para cada tipo de sistema de arquivos (/sbin/fsck.*). Este ajudante decidirá se o sistema de arquivos deve ser verificado com base no tempo desde a última verificação, número de montagens, desmontagem não limpa etc.

Você pode simplesmente verificar se os testes levaram quase nada para executar (se você usar o 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

Você tem certeza de que o fsck está demorando 30s e não apenas que a próxima mensagem do console relacionada ao udevd leva 30 segundos? Em outras palavras, talvez o udevd esteja demorando 30 segundos para trabalhar com o libticables antes de mostrar uma mensagem do console?

Tente remover (ou mover outro local temporariamente)

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

e veja se isso ajuda.

Este fsck em cada inicialização aconteceu comigo devido a um relógio ruim. Parece que o systemd-fsck @ é executado antes do systemd-timesyncd e, sem um RTC com bateria, a hora do sistema está incorreta no momento em que o fsck é executado.

Confirmei que é isso que aciona a verificação completa (em vez de o fsck sair rapidamente), desativando systemd-timesynd, ajustando o relógio para o valor de pré-sincronização encontrado no journalctl e executando o fsck. O e2fsck passa a fazer uma verificação completa, uma vez que detecta que o último tempo de gravação do superbloco está no 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
...

Observe que esse gatilho para a verificação completa não está relacionado aos outros gatilhos da contagem máxima de montagem e intervalo de tempo desde a última verificação, vista em dumpe2fs -h, mencionada em outras respostas aqui.

Observe que, sem ajustar o relógio (ou seja, deixando o timesyncd sincronizá-lo), o fsck não fará uma verificação completa, mas sairá rapidamente com uma mensagem 'limpeza do sistema de arquivos'.

Como solução alternativa, desabilitei o fsck no / etc / fstab configurando o campo 'pass' para 0. Eventualmente, comprarei um RTC com bateria para este dispositivo.

Minhas pesquisas me permitem concluir que a contagem máxima de montagens padrão do Ubuntu está definida como -1. Isso significa que o fsck nunca será executado em nenhuma inicialização, independentemente do número de montagens. Você pode verificar o seu por comando -

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

Você pode aumentá-lo conforme sua necessidade usando tune2fs. Um exemplo típico é o seguinte -

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

Personalize-o por sua vontade.