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

37

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

再起動後/var/log/fsck、ディスクチェックの結果をチェックインしました。
どちらもcheckfsとCHECKROOTは言った：何もまだログインしていません

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

boot logging fsck

— バート・シルバーストリム
ソース

Ubuntu 12.04 LTSでも同じ問題が発生します。/var/log/boot.logにfsckログが見つかりました。

15

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

— はねかける
ソース

最も可能性が高い。もう驚かすべきではない、それはおそらくないだろうということは、対処すべき...

— バートSilverstrim

これは非常に否定的な方法でも影響します。EC2を使用しているため、サーバーを再起動すると、このような詳細が必要になります。これを「ウィッシュリスト」アイテムと見なすにはどうすればよいですか？これはコア機能であり、壊れています。

— タマーレ

@tamaleあなたは完全に正しいです。私もこれに見舞われました。私の/パーティションには厄介な癖があり、回復モードに入ると強制的にe2fsckオンにしました。これは完璧ですが、どのファイルをバックアップから置き換えるかを覚えるのは本当に難しいので、破損したと報告されているファイル名を追跡できなければなりません。

— 構文エラー

13

Ubuntu 14.xxの場合：

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

— シェイ
ソース

1

Ask Ubuntuへようこそ。;-)当時11.10にバグがあったため、新しいシステムに関するあなたの答えは、この3年前の質問に価値を追加しません。将来のために：質問の日付と、すでに答えがあるかどうかを見てください。;-)

— Fabby

4

@ファビーですが、将来の訪問者にとってはまだ便利かもしれませんね。バージョンが表示されます（@Shayは14.04または14.10を意味しますか？）。したがって、有効な答えであると言えますが、OP（3年前に解決策を見つけた人...）

— バイトコマンダー

検索エンジンがこれを古い質問として表示できるようにタグを追加しました。

— NGRhodes

絶対的に正しい！:-)それが、私がコメントを残した理由です。記録のために：私は投票しなかった！;-)

— Fabby

1

@Byte Commanderこの「古い」と思われる質問は、本当に私を大いに助けてくれました！私は、fsckログがそれぞれに隠されることを決して想像しなかったでしょう/var/log/upstart/mountall.log。/var/log/upstart/mountall.*.log.gz。かなり非論理的。ただし、破損していると報告されたファイル名はログに記録されず、inodeのみが記録されたようです。

— 構文エラー

6

Ubuntu 16.04および18.04 ルートパーティションの場合

おそらく探してい/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
----------------

— ven42
ソース

1

ルートパーティションの場合、これは16.04 + systemdの唯一の正しい答えのようです。

— ジョナブラウン

5

Ubuntu 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

— オタク長老
ソース

2

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

— バーブク
ソース

0

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

— オタク長老
ソース