Onde os resultados do fsck são registrados no momento da inicialização, após / forcefsck?

37

Ao trabalhar remotamente, configurei um servidor para forçar um fsck no momento da inicialização com o sudo touch /forcefsckcomando e reiniciei.

Depois de reiniciado, verifiquei /var/log/fsckos resultados da verificação do disco.
Ambos os checkfs e checkroot disse: Nada foi ainda registrado

Então, onde está salvando os resultados?

boot logging fsck

— Bart Silverstrim
fonte

Tendo o mesmo problema no Ubuntu 12.04 LTS. Encontrei o log do fsck em /var/log/boot.log.

15

Possivelmente você foi afetado por este bug: "Não registra invocações de fsck em / var / log / fsck /"

— respingo
fonte

Provavelmente. Não deve ser surpreendido mais que ele provavelmente não vai ser abordado ...

— Bart Silverstrim

Isso também nos afeta de uma maneira muito negativa - estamos no EC2 e, quando os servidores são reiniciados, precisamos de detalhes de coisas como esta. Como isso pode ser considerado um item da "lista de desejos"? Essa é a funcionalidade principal e está quebrada.

— Tamale

@tamale Você está totalmente certo. Também fui atingido por isso. Minha /partição tinha uma peculiaridade desagradável e, ao entrar no modo de recuperação, forçou uma e2fsck. Isso é perfeito, mas como é realmente difícil lembrar quais arquivos substituir do backup, é preciso ser capaz de rastrear os nomes de arquivos supostamente corrompidos.

— Syntaxerror 12/08/2015

13

Para o Ubuntu 14.xx:

Encontrei alguns logs do fsck /var/log/upstart/mountall.log.

— Shay
fonte

1

Bem-vindo ao Ask Ubuntu. ;-) Havia um bug na versão 11.10 da época, então sua resposta em um novo sistema no momento não agrega valor a essa pergunta de três anos. Para o futuro: observe a data de uma pergunta e se já existe uma resposta. ;-)

— Fabby

4

@ Fabby, mas para futuros visitantes ainda pode ser útil, eu acho? A versão é fornecida (@ Shay, você quer dizer 14.04 ou 14.10?) E, portanto, eu diria que é uma resposta válida, embora possa não ajudar o OP (que encontrou uma solução há 3 anos ...)

— Byte Commander

Adicionei uma tag para ajudar os mecanismos de pesquisa a mostrar isso como uma pergunta antiga.

— NGRhodes

Absolutamente certo! :-) É por isso que acabei de deixar um comentário. Para constar: eu não votei de forma negativa! ;-)

— Fabby

1

@Byte Commander Esta questão supostamente "antiga" me ajudou MUITO! Eu nunca imaginaria que os fscktroncos ficariam escondidos /var/log/upstart/mountall.log. /var/log/upstart/mountall.*.log.gz. Bastante ilógico. No entanto, parece que os nomes de arquivos relatados como corrompidos não foram registrados, apenas seus inodes.

— Syntaxerror 12/08/2015

6

Para partições raiz Ubuntu 16.04 e 18.04

Você provavelmente está procurando /run/initramfs/fsck.log.

Um fsck do sistema de arquivos raiz necessariamente acontece antes que o sistema de arquivos raiz seja montado como gravável, portanto, a verificação do sistema de arquivos ocorre no início do processo de inicialização enquanto o sistema ainda está sendo executado a partir do initramfs. Um log fsck é gravado em um sistema de arquivos com backup em RAM (tmpfs) que está disponível para gravação no momento e continua disponível após a inicialização em /run/initramfs/fsck.log. Como o armazenamento é volátil, os logs do fsck são perdidos quando o sistema é reiniciado. Seria bom se esses logs fossem copiados para armazenamento não volátil após o sistema de arquivos raiz ser montado como gravável, mas isso não parece ser o caso.

Aqui está um exemplo:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0   238G  0 part /

$ cat /run/initramfs/fsck.log 
Log of fsck -C -a -V -t ext4 /dev/sda2 
Fri Nov 30 22:35:21 2018

fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 
/dev/sda2: clean, 653295/15597568 files, 6658147/62383360 blocks

Fri Nov 30 22:35:21 2018
----------------

— ven42
fonte

1

Para partições raiz, esta parece ser a única resposta correta para 16.04 + systemd.

— Jonah Braun

5

Para o Ubuntu 16.04

O comando journalctl -b --no-pager | grep systemd-fsck

relata o sistema de arquivos da partição não raiz checks.similar a isso:

Mar 22 15:06:26 64bitUbuntu systemd-fsck[750]: /dev/sdb1: clean, 146223/121454592 files, 356711795/485818368 blocks

Para verificações de partição raiz no problema de inicialização, o comando more /var/log/boot.log

Fornece resultados semelhantes a este:

/dev/sda2: clean, 349091/1954064 files, 2379983/7814912 blocks

— Elder Geek
fonte

2

Testando isso com o Ubuntu 12.04.5 LTS e encontrei o logon /var/log/boot.log

└❯ grep -A 1 fsck /var/log/*
/var/log/boot.log:fsck from util-linux 2.20.1
/var/log/boot.log-/dev/vda1: 209262/2621440 files (0.1% non-contiguous), 3239494/10485504 blocks

— barbuk
fonte

0

Para o Ubuntu 18.04

O comando journalctl -b --no-pager | grep systemd-fsckegrep systemd-fsck /var/log/syslog

ambos relatam verificações do sistema de arquivos da partição não raiz.

Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[615]: Scratch: clean, 19/6520832 files, 555602/26081280 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[609]: /dev/sda1: clean, 47014/89374720 files, 294970235/357492992 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[613]: /dev/sda5: clean, 6707/32727040 files, 7464312/130885120 blocks

As verificações das partições raiz montadas pelos resultados do UUID não parecem ser registradas, mesmo se forçadas.

— Elder Geek
fonte