セキュリティーの都合上詳しいことはかけませんが，ハードウエアの交換について，やってみなけりゃわからない部分があるので，実際に試してみることにします．
時間のあるときにテストするので， “しばらく” の期間は未定です．
テスト期間中は数分〜数時間でリブートさせたり，数時間停止（外部ネットからは無応答）したりということになります．
安定になったらまた掲示します．
Category: Computer
Thunderbolt 2のDoc復活
アメリカにあるCalDigit社のThunderbolt 2 (TB2)のDocを昔使っていて，現在のメインWorkstation (WS)であるMac mini late 2018を購入した2019年はじめにMac miniにThunderbolt 2のポートがないので，引退させ押入れに入れました．
それからしばらくして，TB2のHDD/SSDケースをどうしたものかと考えていたら，アマチュア無線関係のかたから，Apple純正のTB3 -> TB2アダプターを勧められ，少し高いけど，TB2のHDD/SSDケースが2つあったこともあり，購入してバックアップ用に活用しました．
それから5年経ち別のアマチュア無線関係のかたが新しいMac miniやMacbook Airを購入され，ドックを検討しているとSNSに書かれていたので，自分のDocの写真を撮ってこんな古いドックがありますとSNSでリプライしました．
その時ふと，TB3->2アダプターでこの死蔵しているドックを使って見ようと思いました．
これまでなぜか考えつかなかったんですが，試してみたらなかなかいい具合です．
TB2の差込口が2つあるので，この状態でTB2のHDD/SSDケースにケーブル一本でつなげますから不利益はないです．
副次的なメリットとして，このDocのHDMIポートからサブモニターであるEIZO Flexscan L461につなぐと全く問題なく使えます．実は，Mac mini本体のHDMIポートに直接繋ぐと起動時には画面が乱れて，ログインしてデスクトップが表示された時点でケーブルの抜き差しをすると正常になります．そんなことを毎日，5年間も続けてきたのですが，あっさり解消しました．
Etherポートも試してみました．本体と遜色ない速度が出ます．ただ，DocのEtherポートを使うとネットへのトラフィックがTB3->TB2のデータ帯域を使い，メリットは特にないので常時使用することはやめときました．
TB2のケーブルが一本余計に要りますが，それも “死蔵” してましたので問題なし．
HDMI↔DVI変換ケーブルを使用．
サーバー不安定 (3) ひとまず安定か
昨日から何度かリブートはかけましたが，24時間以上システムが無応答になったり，おかしな挙動をすることもなく安定して動いているようで，ひとまず安心です．
故障した可能性が大きいRaspberry Pi 4 Model B (RPi4) RAM 8GBの代わりをどうするか．先々を考えると少し奮発してRPi5 8GBを買うのが良さそうですが，まだRPi5で動くSlackware Aarch64の正式リリースはなく “Current” で使い続けるのは無理なので迷うところです．
Slackware ARM (32bit)のRPi5 hackは何故か存在しないのです．
このままRPi4 4GBでしばらく行ってみます．
サーバー不安定 (2) 本体かも
どうも，サーバーの不安定の原因は，USBまわりというところだけは正解のようですが，USB接続のSSDでもUSB HUBでもなさそうです．
本体を予備のRaspberry Pi 4 Model B (RPi4)にしました．違いは本来のサーバーはRAM 8GBのところ，予備機は4GBというところです．
SSDのまるまるコピーなどといった負荷をかけながら動かしていて，起動から5時間経過しましたが，今のところ正常のようです．
また8GBの方もSDカードを入れてVLCで監視カメラのモニターをさせています．USBは使わない状態です．こちらも同じく5時間安定して動いています．
ということで，RPi4のハードのUSBまわりの故障のように思います．
ちなみに，GUIなしのサーバー用途でRAMは4GBもあれば十分かと思いましたが，そうでもなくて，rsyncによるディスクのまるまるコピーのようなバッファを多く使うタスクを実行していると，kswapd0が大汗をかく場面が多く，その場合zramといえどもhttpdのレスポンスはかなり悪くなります．
RPi4 8GBとなるとRPi5に価格が近くなるので迷います．
サーバー不安定
下記のようにUSB HUBの故障かと思いましたが，予備用のHUBを使っても起動後しばらくしてシステムがハングアップしてしまいます．トラブルの原因の特定にはもう少し時間がかかりそうです．
USB HUBの故障と推定（たぶん誤り）
某サーバーですが，本日電力系統への落雷が原因と思われる停電があり，数分後に復電しましたが，ブートしなくなりました．
BIOSのメッセージからブート用のメディアが見つからないようです．メインのSSDは，/bootとROOTとの2パーティションなので，たぶん/bootがファイル的に壊れたものと思い，他のLinuxマシン（以下 “作業用マシン” ）でfsckをかけました．致命的ではない軽微な修復がなされましたが，サーバーに繋いでも症状は変わりません．
もう一度作業用マシンに繋いで/bootとROOTもfsckをかけました．ext4のROOTは頑強で何の問題もありませんでした．念の為/bootはフォーマットしたうえで今朝のバックアップをコピーしました．
それでも症状は変わりません．これは本体かなと思い，サーバー機とほぼ同じスペックの予備機と入れ替えましたが，やはりブート用のメディアが見つかりません．
これはひょっとしてと思い，USB3.0のHUBをとばしてSSDをサーバー本体に繋いだらブートしました．
これは間違いなくUSB3.0HUBの故障です．予備用のUSB3.0HUBを使って従前と同じマスストレージの接続形態に戻したら，サーバーは無事にブートしました．
当面はこの予備用のHUBを使いますが，安くて良さそうなUSB3.0HUBを探して注文することにします．
本当はBIOSではないのですが，一般的なPCならBIOSなので，説明の省略も兼ねてそう記します．