web-dev-qa-db-ja.com

/ forcefsckの後、ブート時にfsckの結果はどこに記録されますか?

リモートで作業するとき、Sudo touch /forcefsckコマンドでブート時にfsckを強制するようにサーバーを設定し、再起動しました。

再起動後、/var/log/fsckでディスクチェックの結果を確認しました。
checkfscheckrootの両方:まだ何も記録されていません

結果をどこに保存しますか?

36

このバグの影響を受けている可能性があります: "/ var/log/fsck /にfsck呼び出しを記録しません"

15
splash

Ubuntu 14.xxの場合:

/var/log/upstart/mountall.logにfsckログがいくつか見つかりました。

13
Shay

buntu 16.04の場合

コマンドjournalctl -b --no-pager | grep systemd-fsck

これと同様に、非ルートパーティションファイルシステムのチェックを報告します。

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

ブート時のルートパーティションチェックについては、コマンドmore /var/log/boot.log

これに類似した結果を提供します:

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

buntu 16.04および18.04の場合rootパーティション

おそらく/run/initramfs/fsck.logを探しています。

ルートファイルシステムが書き込み可能としてマウントされる前にルートファイルシステムのfsckが必ず発生するため、システムがinitramfsから実行されている間に、ブートプロセスの早い段階でファイルシステムチェックが行われます。 fsckログは、RAMでバックアップされたファイルシステム(tmpfs)に書き込まれます。このファイルシステムは、現時点で書き込み可能であり、/run/initramfs/fsck.logでの起動後も引き続き利用できます。これは揮発性ストレージであるため、システムを再起動するとfsckログは失われます。ルートファイルシステムが書き込み可能としてマウントされた後、これらのログが不揮発性ストレージにコピーされた場合は便利ですが、そうではないようです。

以下に例を示します。

$ 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
----------------
4
ven42

Ubuntu 12.04.5 LTSでこれをテストすると、/ 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
2
barbuk

buntu 18.04の場合

コマンドjournalctl -b --no-pager | grep systemd-fsckおよびgrep systemd-fsck /var/log/syslog

どちらも非ルートパーティションファイルシステムのチェックを報告します。これと同様:

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

UUIDの結果によってマウントされたルートパーティションのチェックは、強制されてもログに記録されないようです。

0
Elder Geek