CentOS7が起動しなくなったけど復旧した
先日、自前のサービスを運用しているさくらのVPSでCentOS7が起動しなくなっていたが、無事に復旧できたので備忘録として残しておきたいと思う。
※もともと記事にする予定はなかったので、省略したり曖昧だったりな箇所もあります
経緯
ある日いつのもように運用中のサービスを利用しようとしたところ、HTTPサーバーが応答しなくなったことに気づく。慌ててSSHで接続を試みたもののSSHサーバーも応答しない状況だった。
さくらのコンソールからVNCコンソールでVPSに接続したところ、CUIが真っ黒のままでいくら入力しても何も出力してくれない。何もしてないのに壊れた!
強制再起動を掛けたところ、Booting from Hard Disk...までは出力されるが、その後はやはりいくら入力してもCUIは真っ黒のままになる。
へんじがない…。ただの しかばねのようだ…。
ここでいろんな可能性が過ぎったが、メールを漁ってみるとさくらインターネットさんからこんなお知らせが来ていた。
内容を確認してみると、見事に該当サーバーを利用していてタイミングも被ってたので、藁にも縋る思いでさくらさんに問い合わせをすることに。
ぼく「こないだの障害でデータ吹き飛んじゃったかもです!状況確認おねがいできますか!」
さくらさん「お知らせの通りサーバーは既に復旧していますし、VPSは自分で管理するものなので自分で確認してください。」
ぼく「わかりました!(そっか、そういうものなのね...('o';))」
という感じのやりとりを経て、まだこちらで何かできる余地があるという貴重な情報を得たので、さくらの担当者さんが案内してくれた情報も参考に、復旧を試みることに。
復旧までの流れ
シングルユーザーモード
GRUBの出力すらないためレスキューモードへ
レスキューモード
- 公式から拾ったISOからブート→VNCコンソールを開く
- Troubleshooting→Rescure CentOS system
- Continue
- chroot /mnt/sysimageでコケる
- ls /mnt/sysimageしてみると空だし、前のほうでYou don't have any Linux partitionsと書いてあることに気づく
- めのまえが まっくらに なった!
この時点ではブートローダのGRUBがおかしくなった可能性もあると思ったので
# mount /dev/vda1 /mnt/devvda1
して、grub.cfgのserialなんちゃらの行を消してみる→grub2-mkconfigで作り直してみる→前回のカーネルアップデート時のcfgに戻してみる…など試してみたものの、GRUBの出力を得られることはあったがOSの起動には至らず。
結局OSが入っているパーティションのどこかで問題が起きている可能性があると思ったので、パーティションの修復を試みることに。
パーティション修復
1.パーティションを確認する
# fdisk -l
(略)
Device Boot Start End Blocks Id System
/dev/vda1 * 2048 1026047 512000 83 Linux
/dev/vda2 1026048 419430399 209202176 8e Linux LVM
(略)
2.LVMパーティションを利用可能にする(Rescure modeでは無効になっている)
LV Statusを確認
# lvdisplay | grep "Stat"
LV Status NOT available
LV Status NOT available
LV Status NOT available
Volume groupを有効化
# vgchange -a y
LV Statusを再度確認
# lvdisplay | grep "Stat"
LV Status available
LV Status available
LV Status available
# lvscan
ACTIVE '/dev/centos_*/swap' [<2.02 GiB] inherit
ACTIVE '/dev/centos_*/home' [147.49 GiB] inherit
ACTIVE '/dev/centos_*/root' [50.00 GiB] inherit
3.OSが入っているパーティションの修復を試みる
ダメもとでマウントしてみる
# mount /dev/centos_*/root /mnt/root
(具体的には忘れたけど失敗した旨のメッセージが返ってきた)
チェックを走らせてみる(xfs_checkなんてなかった)
# xfs_ncheck /dev/centos_*/root
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_ncheck. If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
must run blockget -n first
修復してみる
上記のエラー文言にも書いてあるように、-Lオプションは破損を引き起こす可能性があるようなので、一般的にはdd等でバックアップを取ってからやるほうが良いと思う(やるとは言っていない)
# xfs_repair -L /dev/centos_*/root
Phase 1 - find and verify superblock...
(中略)
done
いい意味で終わった・・?ようなので、これでレスキューモードを終えてVPSを起動をしてみたところ・・・
無事にCentOS7が起動した😭🙏🙇♂️🍻🎉