12:50 pm
LVM上で/bootパーティションを切っていて、かつ同一VG上に任意のLVのsnapshotファイルを保持している状況下で、カーネルアップデートを行なうとGrub2のバグのためにマッピングエラーが起きて、カーネルアップデートに失敗してしまいます。
この失敗した状況下において、システムのリブートを行なうとGrub2が立ち上がらなくなり、Gurub2のレスキューモード(grub-rescue>プロンプトが表示され、カーネルメニューが表示されなくなってしまいます)に入ってしまい、サーバー自体が立ち上がらなくなってしまいます。
この罠にはまって、解決策にたどり着くまでにサーバーが一週間もダウンしてしまいました。
対応策は簡単で、AleternateCDやSystemResueCDからサーバーのHDDにアクセスして、問題となっているsnapshot ファイルを削除してしまえば良いだけです。対応Patchもあるようですが、snapshot ファイルを削除してしまうのが簡単安全確実です。
自分の場合、もともとsnapshotは、dumpバックアップを取るために一時的に作成するだけなので、バックアップが出来てしまえば、残しておく必要はないので。
スナップショットファイルといっても、lvscan をやってみれば分かるように、lvのひとつとしてデータを保持しているようなので、Grub2(実質的には/usr/sbin/grub-probe)が /boot(LV) と混同してマッピングエラー(no mapping exists for ‘VG0-lv01′)を起こしてしまうようです。
※VG0-LV01は、/bootとして作ったlv名になります。
エラーの原因が分かってみると以上のように簡単に対応策が取れますが、なぜno mapping exists for ‘VG0-lv01′ error が出るのか掴めなかったので、一週間、色々な試行錯誤で大変苦労しました。
まさか、snapshot に絡むバグとはまったく想像しておりませんでしたので、解決に時間を要してしまいました。
教訓:異常発生前に行なったすべての作業(今回の場合は、snapshoto作成)を予断なく洗い出し、当該作業を洩れなくキーワードにしてGoogleで対応策をサーチすべき。
Debian Bug report logs – #574863
grub-pc: grub-probe unable to find mapping for /boot on LVM with a snapshot LV
Problem Description:
Creation of a snapshot logical volume makes grup-pc complete skip the volume
group and makes the system not bootable. (/boot is in an LVM). The problem is
in the code in lvm.c:grub_lvm_scan_device()
Whenever there is a snapshot logical volume, there is a special LV of
“type = snapshot” that is created to handle the snapshot operation.
This LV is hidden and is part of the LVM metadata but not listed in lvdisplay.
This special LV will not have the “stripe_count = xxx” property. The actual
stripe_count will be same as the source LV ‘origin = ‘ property.
However in the code any LV not having a stripe_count property is treated as a
fatal error and control jumps to lvs_segment_fail: and further fail4: and
ultimately skips the entire VG. None of the LVs are populated in the vg_list
leading to grub-probe failure and further issues that completely breaks grub-pc
installation and updation.
Related Posts