Raspbian強制終了でクラッシュ！ fsckコマンドで修復を試みるもダメだった
ログを残しておく。
対象環境
- Raspberry Pi 3 Model B+
- Raspbian stretch 2018-06-27
経緯
- 新しいディスプレイを買った
- 解像度を試すべく何度も再起動した
- 何度目かで終了せずフリーズした
- やむなく電源をぶっこ抜いた
- 再起動しなくなってしまった！
状況
- ブートしない
- 虹色の画面も出ないし、ラズベリーのアイコンも出ない
- ディスプレイには
NO SUPPORTと表示されたあと真っ暗になる - Raspbianが入った別のHDDでは正常にブートする（本体もディスプレイも正常と思われる）
- 今回の手順で
fsckコマンドを使っても修復できなかった
参考
方法
手順
0. 修復用システムHDDを用意する
fsckは修正対象のパーティションをマウント解除して行う必要がある。そのためLinuxシステムがインストールされたHDDが別途必要。もしくはブート用CDやUSBメモリでも可。
- 修復用システムHDDを用意する
- 1に修復したいシステムHDDを接続する
1. 修正パーティション確認
$ mount ... /dev/sdb1 on /media/pi/boot type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) /dev/sdb2 on /media/pi/rootfs type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
2. 対象パーティションをアンマウントする
$ umount /media/pi/boot $ umount /media/pi/rootfs
3. fsck実行
$ fsck -y /dev/sdb1 $ fsck -y /dev/sdb2
上記でも修正できないなら以下も実行する。
$ fsck -fy /dev/sdb1 $ fsck -fy /dev/sdb2
sdb1の結果
$ sudo fsck -y /dev/sdb1 fsck from util-linux 2.25.2 fsck.fat 3.0.27 (2014-11-12) 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Performing changes. /dev/sdb1: 173 files, 44991/87078 clusters
util-linuxからのfsck 2.25.2 fsck.fat 3.0.27（2014-11-12） 0x41：ダーティビットがセットされます。 Fsが正しくアンマウントされておらず、一部のデータが破損している可能性があります。 汚れたビットを自動的に削除します。 変更を実行する。 / dev / sdb1：173ファイル、44991/87078クラスタ
念のため-fも付与して再度実行する。
$ sudo fsck -fy /dev/sdb1 fsck from util-linux 2.25.2 fsck.fat 3.0.27 (2014-11-12) /dev/sdb1: 173 files, 44991/87078 clusters
sdb2の結果
面倒なので最初から-fyフラグで実行した。たぶん15分くらいかかった。
$ sudo fsck -fy /dev/sdb2 fsck from util-linux 2.25.2 e2fsck 1.43.3 (04-Sep-2016) Pass 1: Checking inodes, blocks, and sizes Inodes that were part of a corrupted orphan linked list found. Fix? yes Inode 910083 was part of the orphaned inode list. FIXED. Inode 1039218 was part of the orphaned inode list. FIXED. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information rootfs: ***** FILE SYSTEM WAS MODIFIED ***** rootfs: 226273/60331392 files (0.2% non-contiguous), 5771010/244178358 blocks
Google翻訳%0APass%201%3A%20Checking%20inodes%2C%20blocks%2C%20and%20sizes%0AInodes%20that%20were%20part%20of%20a%20corrupted%20orphan%20linked%20list%20found.%20%20Fix%3F%20yes%0A%0AInode%20910083%20was%20part%20of%20the%20orphaned%20inode%20list.%20%20FIXED.%0AInode%201039218%20was%20part%20of%20the%20orphaned%20inode%20list.%20%20FIXED.%0APass%202%3A%20Checking%20directory%20structure%0APass%203%3A%20Checking%20directory%20connectivity%0APass%204%3A%20Checking%20reference%20counts%0APass%205%3A%20Checking%20group%20summary%20information%0A%0Arootfs%3A%20%20FILE%20SYSTEM%20WAS%20MODIFIED%20%0Arootfs%3A%20226273%2F60331392%20files%20(0.2%25%20non-contiguous)%2C%205771010%2F244178358%20blocks)
util-linuxからのfsck 2.25.2 e2fsck 1.43.3（2014年9月4日） パス1：inode、ブロック、およびサイズのチェック 孤立した孤立リンクリストの一部であるInodeが見つかりました。 修正？ はい Inode 910083は、孤立したinodeリストの一部でした。 一定。 iノード1039218は、孤立したiノードリストの一部でした。 一定。 パス2：ディレクトリ構造のチェック パス3：ディレクトリ接続の確認 パス4：参照カウントの確認 パス5：グループ要約情報の確認 rootfs：*****ファイルシステムが変更されました***** rootfs：226273/60331392ファイル（0.2％非連続）、5771010/244178358ブロック
4. 確認
ブートせず。状況は同じ。残念でした。もうOS再インストールしかないか……。
対策
A．Raspbianまるごとバックアップ。でも頻繁なバックアップは面倒…… B．実験用Raspbianインストール済HDDを用意する。でも、フリーズして電源断したら壊れたのだから何度やっても同じ……
電源断したら壊れるのは想定内。ならその前の段階で防げないか？
C．フリーズから復旧する方法を調べる
所感
なんかLinuxってこんなんばっかだな。システムアップデートしたらシステム破壊してOS再インストールするハメになったし。
今回は対策Bをとっていたので被害は最小限だったが、直前までやってたDockerやGiteaが消えた。そしてRaspbianのインストールと設定をやり直し。以下の手順がいる。少なくとも数時間のロス。
バックアップとかRAIDとか、いずれちゃんと考えるべきか。
