Parallels のサイバーマンデー 25% OFF 12月5日まで安く買う方法

panic: ufs_dirbad: /: bad dir ino … エラーの解決法

FreeBSDのカーネルパニック解決法

FreeBSDでpanic: ufs_dirbad: /: bad dir ino 9999999 at offset 512 mangled entry のようなカーネルパニックが発生した場合の解決方法です。

目次

解決方法

STEP
エラーメッセージの確認

まず、エラーメッセージの確認をしておきます。

panic: ufs_dirbad: /: bad dir ino 1442307 at offset 512 mangled entry

上記の例ではカーネルパニックの原因となっているディレクトリのマウントポイント/inode1442307 となっています。この2つの値を覚えておいてください。あとで使います。

STEP
シングルユーザモードで起動

シングルユーザモードでFreeBSDを起動します。起動画面で S または 2 キーを押してください。

FreeBSDの起動画面
STEP
ファイルシステムの情報を確認

/etc/fstab を見て、カーネルパニックの原因となったマウントポイントのデバイス名を確認します。

# less /etc/fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/vtbd0p2    /               ufs     rw      1       1
/dev/vtbd0p1    /boot/efi       msdosfs rw      2       2
/dev/vtbd0p3    none            swap    sw      0       0

この例ではマウントポイント / のデバイス名は /dev/vtbd0p2 になります。

STEP
fsdbを実行する

先ほど調べたデバイス名を引数にして、ファイルシステムデバッガーfsdbを実行します。

# fsdb /dev/vtbd0p2
** /dev/vtbd0p2
Editing file system `/dev/vtbd0p2'
Last Mounted on /
current inode: directory
I=2 MODE=40755 SIZE=1024
	BTIME=May 12 17:16:13 2022 [0 nsec]
	MTIME=May 31 12:01:54 2022 [545059000 nsec]
	CTIME=May 31 12:01:54 2022 [545059000 nsec]
	ATIME=May 20 02:18:42 2022 [0 nsec]
OWNER=root GRP=wheel LINKCNT=19 FLAGS=0 BLKCNT=8 GEN=51ef81
fsdb (inum: 2)>
STEP
inodeに移動

カーネルパニックの原因となったinodeに移動します。

fsdb (inum: 2)> inode 1442307
current inode: directory
I=1442307 MODE=40755 SIZE=512
	BTIME=May 12 16:54:36 2022 [0 nsec]
	MTIME=May 31 02:00:00 2022 [4587000 nsec]
	CTIME=May 31 02:00:00 2022 [4587000 nsec]
	ATIME=May 20 02:18:29 2022 [0 nsec]
OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=8 GEN=965de8ec
fsdb (inum: 1442307)>

ここで lscd コマンドを実行できるので、このinodeのディレクトリ名を確認しておきましょう。

fsdb (inum: 1442307)> ls
slot 0 off 0 ino 1442307 reclen 12: directory, `.'
slot 1 off 12 ino 1362176 reclen 12: directory, `..'
slot 2 off 24 ino 1442755 reclen 24: regular, `bsdinstall_log'
slot 3 off 48 ino 1442756 reclen 24: regular, `utx.lastlogin'
slot 4 off 72 ino 1442757 reclen 16: regular, `utx.log'
slot 5 off 88 ino 1442772 reclen 28: regular, `sendmail.st'
slot 6 off 116 ino 1442759 reclen 20: regular, `auth.log'
slot 7 off 136 ino 1442760 reclen 16: regular, `cron'
slot 8 off 152 ino 1442761 reclen 20: regular, `debug.log'
slot 9 off 172 ino 1442762 reclen 16: regular, `maillog'
slot 10 off 188 ino 1442763 reclen 20: regular, `messages'
slot 11 off 208 ino 1442764 reclen 20: regular, `devd.log'
slot 12 off 228 ino 1442765 reclen 20: regular, `security'
slot 13 off 248 ino 1442766 reclen 20: regular, `daemon.log'
slot 14 off 268 ino 1442767 reclen 16: regular, `xferlog'
slot 15 off 284 ino 1442768 reclen 20: regular, `lpd-errs'
slot 16 off 304 ino 1442769 reclen 16: regular, `ppp.log'
slot 17 off 320 ino 1442770 reclen 192: regular, `sendmail.st.0'
fsdb (inum: 1442307)>

この例では問題のディレクトリは /var/log っぽいですね。

STEP
inodeをクリア

問題のinodeをクリアします。復旧するにはこれしかないので覚悟を決めてください。

fsdb (inum: 1442307)> clri 1442307

fsdbを終了します。

fsdb(inum:1442307)> quit

**** FILE SYSTEM STILL DIRTY *****
*** FILE SYSTEM MARKED DIRTY
*** BE SURE TO RUN FSCK TO CLEAN UP ANY DAMAGE
*** IF IT IS MOUNTED, RE-MOUNT WITH -u -o reload
STEP
fsckの実行

言われたとおりfsckを実行します。1回で修復できない場合もあるので何度か繰り返しましょう。

# fsck -y /dev/vtbd0p2
(中略)
***** FILE SYSTEM MARKED CLEAN *****

以上で復旧完了です。いえい。

壊れていたディレクトリは元通りに復旧しているかもしれないし、失われているかもしれません。お亡くなりになっていたらバックアップから復元しましょう。

さいごに

これは過去に実際に私が経験したことのあるエラーです。レンタルしていたVPSでサーバ会社によるメンテナンスがあり、メンテナンス終了後にVPSが起動しなくなってとても焦った覚えがあります。fsckだけでは修復できませんからね。

メンテナンス中の電源のON/OFFでディレクトリが破損したものと思われます。これはサーバ会社が悪いのか私が悪いのか。どちらにしろ、めったにないエラーなので出会えてよかったと思うことにしています。

でわでわ

FreeBSDのカーネルパニック解決法

この記事が気に入ったら
いいね または フォローしてね!

シェアしてね

コメント

コメントする

目次