freebsd-updateなどでシステム更新の際、手順ミスでライブラリに不整合が生じることがある。Shared object “libxyzw.so.8” not found的なアレ。

これがログインシェルで起きると悲劇で、シェルの起動に失敗しシステムにログインできなくなってしまう。マシンに物理アクセス可能ならシングルユーザーモードなりで復旧可能だが、アクセス手段がsshとかしかなかったりすると詰むんですわ。お察しの通り、記事にしてるくらいだから実際に詰んだんですけどね。

実家サーバをfreebsd-updateが中途半端な状態で再起動したら、以下のような状態でsshログイン不可になってしまった。

$ ssh Decomo@192.168.0.1
Password for Decomo@:
Last login: Sun Nov  6 13:06:52 2022 from 192.168.0.2
FreeBSD 13.1-RELEASE-p1 GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "fish"
Connection to 192.168.0.1 closed.

ログインシェルの変更さえできればリモートアクセスできそうなものの、ssh経由で実現する方法はついぞ見つけられなかった。実のところ作業自体は11月の実家帰省中に行っており、目の前にマシンも液晶モニタもあるのに、D-Sub→DVI-Iのケーブルがなく、手も足も出なかったという。この度、ケーブル持参でようやく復旧できたというわけ。

そもそも、リモートアクセス手段しかない状態でシステム更新すんなよって話だが…静的リンクなbashであるbash-staticがPortsに存在する理由を“わからせ”られた。

というわけで、動的リンクなシェルをログインシェルにしてはいけない。どうしても設定する場合は、/bin/shをログインシェルとするリモートアクセス可能な緊急回復用ユーザー¹⁾を作っておくと良いだろう。

年の瀬も迫る2022年12月26日の昼下がり、珍しく携帯電話が鳴った。ガラケーから電話帳を移しておらず相手は不明。だが、実家の光回線工事のやり取りやらをしていた時期ということもあり、出ざるを得ない。

「はい、もしもし──」
「どーもー、○○です。お世話になっております。」
「あ、どうも、お世話になっております。」

誰かと思えば、自分がインフラ周りの面倒を見てる会社の知人シャチョー。基本はSlackでのやり取りであるからして、平日の昼間に直電とは嫌な予感しかしない。

「なんかファイルサーバーに接続できなくなったみたいで」
「おぅ、マジすか」
「金曜日までは大丈夫だったみたいなんですけど…」
「すぐに確認したいところですが、運悪く今日は出社中でして…」

弊社は原則リモート勤務なので、こういう時でも本来ならお家で確認ができるのであるが、年末対応やらなんやらで出社中だった。さすがに会社のネットワークからsshするのは憚られた。

「分かりました、では夜お願いします」
「承知しました。××さんに詳細確認してみます」

と、そんなやり取りをして終話。

状況的に社内ネットワークないし当該サーバのネットワークの不調かなーと考えつつ、iPadでSlackを開き状況を聞いてみるとBIOS画面でリブートを繰り返しているとのこと。ブートドライブはIntel DC S3700 SSD×2でH/W RAIDのミラー構成だったので、それが起動しないってことは割と重症、というかガチ障害である。このミラードライブは記憶域階層のSSD層としても使っているため、データの保全がヤバい予感しかなかったが、金曜日夜のデータバックアップで直近の作業にひとまず支障なしとのことだったので、最悪の事態は免れた。

終業後、SSD死亡を想定しヨドバシで取り急ぎSSDを調達し一路知人会社へ向かった。こういう時、オフィスが秋葉原だと便利ですね。

20時過ぎに到着。とりあえず問題のサーバのBMCログを確認すると、12/19にSSDペアの片方が脱落、12/25にもう一方が脱落し、システムがクラッシュしたようだ。脱落の原因は不明。同じエンクロージャ内のHDDは何の問題もないし、こんな立て続けにSSDだけが脱落するとは偶然にしては出来過ぎな気がする。何かしらバグを踏んだか？

SSDを別マシンで確認してみても問題なく認識するし、S.M.A.R.T.的にも問題は見当たらなかった。というわけで、SSDはそのまま戻し、障害発生で無効となっていた仮想ドライブを有効化したら、幾度かの自動chkdskを経て、何とか元のWindows Serverは起動した。

ところが肝心のデータドライブが見えていない。これはまぁディスクの管理でDドライブをオンラインにして直ぐに解消したが、今度は認識したDドライブの容量が変で、開くこともできないという状態。

こちらも何度かのchkdskで開けるようにはなったものの、殆どのファイルは失われる結果に終わった。ミラーの仮想ドライブの脱落だから、仮想ドライブさえ元に戻せれば殆どのファイルは復元できるかなー？と楽観的に考えていたが、そう甘くはなかった……

クラッシュ前の営業日分の日次バックアップが完全に取れていたのは本当に不幸中の幸い、転ばぬ先の杖、備えあれば患いなしだった。もし取れてなかったと思うと、肝が冷えるなんてレベルじゃない。バックアップマジ重要。

記憶域は障害発生時の情報が無くてさっぱり分からん。

バックアップから20TBの書き戻しは確定し、元のWindows Serverの環境を維持する理由もなくなった。

良い機会なので、Proxmox VEでRAID-Zなストレージバックエンドを用意し、仮想マシンとしてWindows Serverのファイルサーバを構築しなおすことにした。H/W RAIDとも当然おさらば、単なるHBAとして働いてもらおう。やはりZFSしか勝たん！

ついでにCPUをXeon E5-2650v4に換え、メモリを144GBに増設し、仮想化基盤として整備した。

東芝とSeagateの14TB SATA HDD、MN08ACA14TとExos X16 ST14000NM001G-2KJ103のベンチマーク。実家に設置しているサーバの6TB×4のRAID-Z2ストレージを置き換えようと購入し、1年近く死蔵しているという。なお、先日ようやく実家に持っていきはしたものの、未だ交換には至らず…

例によってUSB 3.0変換での計測なので参考程度に。

	MN08ACA14T	ST14000NM001G
CrystalDiskInfo
CrystalDiskMark
	------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 271.152 MB/s [ 258.6 IOPS] < 27833.35 us> SEQ 1MiB (Q= 1, T= 1): 270.276 MB/s [ 257.8 IOPS] < 3873.33 us> RND 4KiB (Q= 32, T= 1): 1.785 MB/s [ 435.8 IOPS] < 72642.48 us> RND 4KiB (Q= 1, T= 1): 0.658 MB/s [ 160.6 IOPS] < 6194.17 us> [Write] SEQ 1MiB (Q= 8, T= 1): 255.845 MB/s [ 244.0 IOPS] < 32572.05 us> SEQ 1MiB (Q= 1, T= 1): 83.587 MB/s [ 79.7 IOPS] < 12506.20 us> RND 4KiB (Q= 32, T= 1): 1.137 MB/s [ 277.6 IOPS] <112710.49 us> RND 4KiB (Q= 1, T= 1): 0.619 MB/s [ 151.1 IOPS] < 6603.23 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 12:07:56 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: TOSHIBA MN08ACA14T (14TB/USB 3.0)	------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 281.158 MB/s [ 268.1 IOPS] < 29734.37 us> SEQ 1MiB (Q= 1, T= 1): 279.057 MB/s [ 266.1 IOPS] < 3753.59 us> RND 4KiB (Q= 32, T= 1): 2.137 MB/s [ 521.7 IOPS] < 60793.95 us> RND 4KiB (Q= 1, T= 1): 0.721 MB/s [ 176.0 IOPS] < 5668.58 us> [Write] SEQ 1MiB (Q= 8, T= 1): 270.648 MB/s [ 258.1 IOPS] < 30823.96 us> SEQ 1MiB (Q= 1, T= 1): 274.467 MB/s [ 261.8 IOPS] < 3816.19 us> RND 4KiB (Q= 32, T= 1): 13.794 MB/s [ 3367.7 IOPS] < 9487.38 us> RND 4KiB (Q= 1, T= 1): 8.230 MB/s [ 2009.3 IOPS] < 496.55 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 20:48:46 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: SEAGATE ST14000NM001G (14TB/USB 3.0)
ゼロフィル(512kBブロック)	14000504438784 bytes (14 TB, 13 TiB) copied, 70020 s, 200 MB/s	14000490807296 bytes (14 TB, 13 TiB) copied, 71015 s, 197 MB/s

MN08ACA14Tが電源投入2回、使用時間28時間にもかかわらず、代替セクタが計上されてるのが非常に嫌な感じなんですけど…。ネット上でも代替セクタでまくりとか、振動に弱いとかの報告が目につくので、然もありなんではある。が、NAS向けを謳ってるHDDで大丈夫なのこれ。

似たようなスペックの両HDDだけれども、全体的にST14000NM001Gの方が速いと言ってよさそう。この辺は流石のExosブランドってとこっすかね。Seagate絶対許さんマンのワタクシではありますが、Exosブランドに関してはだいぶ信頼している。いやまぁ、コンシューマ向けのラインを24/365で使って壊れて文句言ってる自分が悪いっちゃ悪いんですけども。

CDMのドライブ容量が50GBなのはクイックじゃないフォーマットで、ドライブ作ったためであり他意はない。

中華製のPCケースZZAW C2を買った。フルアルミ製でMicroATX適合の超小型ケースである。

ドライブベイやUSBポート等を完全に廃し電源ボタンのみ搭載という超割り切り仕様とする一方、多少の制約はあるものの、その辺のMini-ITX用ケース程度の大きさで、ATX電源、フルサイズのビデオカード、PCIeスロット4本対応という、刺さる人には刺さりまくりな仕様となっている。

公式サイトはアリエクの販売ページだと思う。少なくとも、ここが一番詳しくてわかりやすい。とか言いつつ、送料を考慮すると一番安かったAmazonでお買い上げ。

中国からの発送で業者はYunExpress、国内配達は佐川だった。7/4に注文し7/12に到着、所要日数9日ってことで、比較的早い方かな。詳細な追跡情報は下表な感じ。関空経由は初めてかも。

製品箱に伝票が直張り状態だったけど、箱の角が少し潰れてるくらいで破損・汚れはなく届いた。

もちろん、中身は無事。

OpenZFS 2.1.4時点で、冗長性レベルを問わずRAID-Zプールに追加したスペシャルvdevを削除することは出来ないようだ。恐らく、トップレベルvdev削除の制限に起因する仕様と思われる。

次のようなRAID-Z1とスペシャルvdevから成るプールがあるとする。

# zpool status ztank
  pool: ztank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        zdata       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
        special
          mirror-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0

errors: No known data errors

ここで、スペシャルvdevを削除しようとzpool removeすると、次のようにエラーとなる。

# zpool remove ztank mirror-1
cannot remove mirror-1: invalid config; all top-level vdevs must have the same sector size and not be raidz.

トップレベルvdevのmirror-1を一気に削除するのがマズいのかと思い、次のように構成メンバを個別に削除してってもダメ。

# zpool detach ztank da5
# zpool remove ztank da4
cannot remove .....

なお、RAIDZ以外の構成なら特に制限なく削除可能で、同じトップレベルvdevであるslogやL2ARCの場合は、RAIDZでも（以前から）削除可能である。

家鯖でスペシャルvdevを本格運用すべく色々準備してたけど、削除できないのはちょっと厳しいなぁ…VMであらかじめ実験しといて良かったぜ……slog/L2ARCは削除できるんだから、将来的にできるようになるのかなぁ………スペシャルvdevの場合、明示的に本体プールの方にデータを書き戻す必要があって難しいのかなぁ…………

当面はpL2ARCを使うとするかー。