Debianで暗号化したroot fsを読めなくなりunbootableになった

Linux kernel 5.2.3のreleaseに伴ったupgradeを実施してrebootした所、LUKSで暗号化したroot filesystemが読めず (passphraseを尋ねてくるpromptも出ず)にunbootableに陥った。

原因は、dependencyの関連でcryptsetup-initramfsというpackageがuninstallされ、その後にregenerateされた/boot/initrd.imgにcryptsetup関連のbinaryが含まれなくなったことだった。

症状と対策

* Linux kernelがloadされboot processは進行するが、暗号化されたroot filesystemが開けずにretryを繰り返して何れgive upする
* 前回別のmachineでGRUB2関連のトラブルを経験していたので、GRUB2 (今回はx86_64-efi)を入れ直したのだが↑と同じ症状でbootできず
* 以前のkernel (v5.1.15)からbootできることに気付き、kernel optionなどの変更によるものかと疑いはじめる。また、他のinitrd.imgと比較した所、bootできないinitrd.imgは1MBほどsizeが小さくなっていると気付き、ここに問題が潜んでいると推定
* 通常の方法では中に含まれているものが見えないので、lsinitramfsという専用のprogramで中身を検めた所、cryptsetup関連のprogramなどが含まれていないと判明
* 最終的にcryptsetup-initramfsというpackageがuninstallされていたことに気付いて再びinstallし、initrd.imgをregenerate (update-initramfs)して解決した

蛇足

根本的な理由に辿り着くまで非常に時間が掛かったのだが、それは以下の要因のため。

* 数日前に別のmachine (Linux box)でGRUB2関連のトラブルに遭遇していた。今回もそれに類似する、或いは見た目は違っていても根本に同じ問題があるのではないかと推定し (結果的に外れていた)、そちらの問題の解消のため作業に取り掛かった

* 前回のmachineと今回のmachineでは使っているGRUB2の種類が違っており、作業に慣れていなかった。前回はDOS形式のdiskにi386-pc方式でMBRにGRUBをinstallしていたが、今回はGPT形式のdiskにx86_64-efi方式でEFI領域にGRUBをinstallしていた

* LVMの扱いに習熟していなかった

参照したwebsites

* [mount: unknown file system type LVM2_member | SvennD](https://www.svennd.be/mount-unknown-filesystem-type-lvm2_member/)
* [Recovering from an unbootable Ubuntu encrypted LVM root partition](https://feeding.cloud.geek.nz/posts/recovering-from-unbootable-ubuntu-encrypted-lvm-root-partition/)
* [GRUB - ArchWiki](https://wiki.archlinux.jp/index.php/GRUB#GUID_Partition_Table_.28GPT.29_.E7.89.B9.E6.9C.89.E3.81.AE.E6.89.8B.E9.A0.86)

Seagateの12TB (≒10.91TiB) HDDを導入した

メインマシン兼NASとして使っているPCのデータストレージとして、これまではWestern DigitalのNAS向け製品であるWD RedシリーズのWD80EFZX (8TB ≒ 7.28TiB)を使っていた。これを新たにSeagateのNAS向け製品であるIronWolfシリーズのST12000VN0007 (12TB ≒ 10.91TiB)へ換装した。ここ数年はWestern DigitalのHDDばかり購入してきた (Redの6TB、8TB)ので、SeagateのHDDを購入するのは久し振りだ。

換装した一番の理由は、WD80EFZXの残り容量がほぼ無くなったこと。丁度決算期で普段より値引きが期待できる時期なのと、前回HDDを導入してから2年ほど経っているので頃合いなこともあった。

LUKS+Btrfsで運用している。RMAの兼ね合いもあるので、2年くらい持てばいいのだが。

S.M.A.R.T.の情報を見てみる

Linuxなので、smartctlを使ってみた:

SMART Attributes Data Structure revision number: 10

Vendor Specific SMART Attributes with Thresholds:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

  1 Raw_Read_Error_Rate     0x000f   079   068   044    Pre-fail  Always       -       74220560

  3 Spin_Up_Time            0x0003   097   097   000    Pre-fail  Always       -       0

  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       2

  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0

  7 Seek_Error_Rate         0x000f   068   060   045    Pre-fail  Always       -       5995223

  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       15

 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0

 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       2

187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0

188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0

190 Airflow_Temperature_Cel 0x0022   064   062   040    Old_age   Always       -       36 (Min/Max 25/38)

192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       2

193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       2

194 Temperature_Celsius     0x0022   036   040   000    Old_age   Always       -       36 (0 25 0 0 0)

195 Hardware_ECC_Recovered  0x001a   040   036   000    Old_age   Always       -       74220560

197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0

198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

200 Multi_Zone_Error_Rate   0x0023   100   100   001    Pre-fail  Always       -       0

240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       15 (143 172 0)

241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       13528061790

242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       455020

WDのHDDと違い、SeagateのHDDでは1 Raw_Read_Error_Rateや7 Seek_Error_Rate、195 Hardware_ECC_Recoveredといった値が物凄い勢いで増加しているので、最初diskの故障を疑った。

しかし、これらのraw valueをそのまま解釈するのは無意味であり、本当に気にするべきなのは5 Reallocated_Sector_Ctや197 Current_Pending_Sector、198 Offline_Uncorrectableの値であるとの情報があった。

* [Just got a Seagate Ironwolf... are these SMART readings normal? : DataHoarder](https://www.reddit.com/r/DataHoarder/comments/61pmsb/just_got_a_seagate_ironwolf_are_these_smart/)
* [Seagate製HDDが故障する直前のsmart値 – UbuntuによるEco Linuxサーバ構築記](http://eco.senritu.net/seagate%E8%A3%BDhdd%E3%81%8C%E6%95%85%E9%9A%9C%E3%81%99%E3%82%8B%E7%9B%B4%E5%89%8D%E3%81%AEsmart%E5%80%A4/)

RAIDでもNAS専用機でもなくsingle disk換装を選んだ理由

Single disk換装を行ったのは、費用や運用の面で最も適していると考えたからだ。

他にはNASを組む (或いはNASキットを買う)、RAIDを組むなどの方法もあるが:

* 初期コストが高い (diskが複数本必要、それを格納できるケースやマザーボード或いはNAS本体、etc)
* 運用の複雑さが増す
* 電気代が増す
* 総容量が大きくなるとバックアップを取るのが難しくなる

といった問題がある。Single disk運用は、そのdiskが故障すると終わりという問題があるものの、これまで使っていたdisks (8TBと6TB)に定期的にbackupを取ることで影響をある程度緩和する方針を取る。

raidzを使い、信頼性のあるきちんとしたfile serverを構築する場合には、以下のpageが参考になるだろう:

cf. [10万円以内で作る18TB raid-z2(ダブルパリティ)高信頼ファイルサーバ – UbuntuによるEco Linuxサーバ構築記](http://eco.senritu.net/10%E4%B8%87%E5%86%86%E4%BB%A5%E5%86%85%E3%81%A7%E4%BD%9C%E3%82%8B18tb-raid-z2%E3%83%80%E3%83%96%E3%83%AB%E3%83%91%E3%83%AA%E3%83%86%E3%82%A3%E9%AB%98%E4%BF%A1%E9%A0%BC%E3%83%95%E3%82%A1%E3%82%A4/)