FreeBSDでpanic: ufs_dirbad: /: bad dir ino 9999999 at offset 512 mangled entry のようなカーネルパニックが発生した場合の解決方法です。
解決方法
まず、エラーメッセージの確認をしておきます。
panic: ufs_dirbad: /: bad dir ino 1442307 at offset 512 mangled entry上記の例ではカーネルパニックの原因となっているディレクトリのマウントポイントは / 、inodeは 1442307 となっています。この2つの値を覚えておいてください。あとで使います。
シングルユーザモードでFreeBSDを起動します。起動画面で S または 2 キーを押してください。
/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先ほど調べたデバイス名を引数にして、ファイルシステムデバッガー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)>カーネルパニックの原因となった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)>ここで ls や cd コマンドを実行できるので、この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)>問題のinodeをクリアします。復旧するにはこれしかないので覚悟を決めてください。
fsdb (inum: 1442307)> clri 1442307fsdbを終了します。
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言われたとおりfsckを実行します。1回で修復できない場合もあるので何度か繰り返しましょう。
# fsck -y /dev/vtbd0p2
（中略）
***** FILE SYSTEM MARKED CLEAN *****以上で復旧完了です。いえい。
壊れていたディレクトリは元通りに復旧しているかもしれないし、失われているかもしれません。お亡くなりになっていたらバックアップから復元しましょう。
さいごに
これは過去に実際に私が経験したことのあるエラーです。レンタルしていたVPSでサーバ会社によるメンテナンスがあり、メンテナンス終了後にVPSが起動しなくなってとても焦った覚えがあります。fsckだけでは修復できませんからね。
メンテナンス中の電源のON/OFFでディレクトリが破損したものと思われます。これはサーバ会社が悪いのか私が悪いのか。どちらにしろ、めったにないエラーなので出会えてよかったと思うことにしています。
でわでわ
コメント