やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

Raspbian強制終了でクラッシュ! fsckコマンドで修復を試みるもダメだった

 ログを残しておく。  

対象環境

経緯

  1. 新しいディスプレイを買った
  2. 解像度を試すべく何度も再起動した
  3. 何度目かで終了せずフリーズした
  4. やむなく電源をぶっこ抜いた
  5. 再起動しなくなってしまった!

状況

  • ブートしない
    • 虹色の画面も出ないし、ラズベリーのアイコンも出ない
  • ディスプレイにはNO SUPPORTと表示されたあと真っ暗になる
  • Raspbianが入った別のHDDでは正常にブートする(本体もディスプレイも正常と思われる)
  • 今回の手順でfsckコマンドを使っても修復できなかった

参考

方法

  1. 修復用システムHDDを用意する
  2. 修正パーティション確認
  3. 対象パーティションをアンマウントする
  4. fsck実行
  5. 確認

手順

0. 修復用システムHDDを用意する

 fsckは修正対象のパーティションをマウント解除して行う必要がある。そのためLinuxシステムがインストールされたHDDが別途必要。もしくはブート用CDやUSBメモリでも可。

  1. 修復用システムHDDを用意する
  2. 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. 確認

  1. バイスを取り外す(タスクバー右端のイジェクトアイコン。デバイスがないならアンマウント後にUSBぶっこ抜く)
  2. 再びブートさせたいラズパイに修正したデバイスを接続する
  3. 電源を入れる

 ブートせず。状況は同じ。残念でした。もうOS再インストールしかないか……。

対策

A.Raspbianまるごとバックアップ。でも頻繁なバックアップは面倒…… B.実験用Raspbianインストール済HDDを用意する。でも、フリーズして電源断したら壊れたのだから何度やっても同じ……

 電源断したら壊れるのは想定内。ならその前の段階で防げないか?

C.フリーズから復旧する方法を調べる

所感

 なんかLinuxってこんなんばっかだな。システムアップデートしたらシステム破壊してOS再インストールするハメになったし。

 今回は対策Bをとっていたので被害は最小限だったが、直前までやってたDockerやGiteaが消えた。そしてRaspbianのインストールと設定をやり直し。以下の手順がいる。少なくとも数時間のロス。

 バックアップとかRAIDとか、いずれちゃんと考えるべきか。