microSDブート、システムディスクUSBメモリ32GB、ストレージHDD 2TBのサーバとしているRaspberry Pi 2 Model B/Raspbian 11 bullseyeのシステムディスクをUSBメモリからSSDに換装してみた話。
microSDやUSBメモリと相性がシビアなラズパイ2B、いっそSSDにしよということで選定してたらコスパやらなんやらで240GBのESSENCORE KLEVV SSD 240GB K240GSSDS3-N40に決定もそんなに容量いらないよね、サブのラズパイ3B+パソコンもA-DATA SSD 120GB ASU650SS-120GT-Rだけど、先代dynabook satellite T30 160Cから載せ替え、今はメインPC dynabook B45/Bに引き継いだTranscend SSD 128GB TS128GSSD370Sと差し替え、これをラズパイ2Bで使うことに。
まず、dynabook B45/BのTranscend 128GB SSDをESSENCORE KLEVV 240GB SSDに換装。
このTS128GSSD370Sは、自身初のSSD、早いもので5〜6年くらい経つんですかね、当時7000円弱だったと思われますが、ムーアの法則やらSSD仕様の違いはあるにせよ、ESSENCOREは240GBで4000円弱、他でも4000円前後から買えることを思うと安くなったものです。
というわけで換装...と言ってもノートPC上にUSBメモリとSSDをそれぞれUSBポートに挿し、GPartedでSSDのパーティションを全削除、USBメモリを/dev/sdc、SSDを/dev/sddとするとsudo dd if=/dev/sdc of=/dev/sdd conv=noerror,sync status=progressでクローン化というかクローニング、GPartedで結果を確認、適宜パーティションサイズを拡張、良ければ、ノートPCのUSBポートから外し、ラズパイ2BのUSBポートに挿し、ラズパイを起動するだけ。
ぎょっ、PC内蔵(SCSI?)からUSB3.0 SSDケースで128GBが約25分だったのに、このUSB2.0メモリからUSB3.0 SSDケースは、32GBで約44分...、ざっと8倍違う...これがSCSIとUSB2.0の差か...。
さておき、おお、他もSSDにしてるから超高速になることはわかっており、それゆえのSSD選択ですが、ここのところ、相性良くないUSBメモリで激遅だったから尚とは言え、購入から6年経過したSSDながら超速っ!!!
ラズパイサーバの電源投入直後、いくらなんでもねと、わずかに時間はおきつつ、sshコマンド実行、相応の時間はかかれど接続エラーになるより早く起動が間に合い接続完了、快適過ぎる...、そうこなくっちゃ。
ローカルマシンからrsyncでバックアップと思ったら、こんなエラーが...。
ネット検索するとリモート先にrsyncがインストールされていないことが原因って情報があるも、そんなはずはない常に同じサーバに対してやっているrsyncバックアップなのだから...。
念の為、dpkg -lで確認しても当然、リモート先というかサーバにもrsyncはインストールされている、apt install --reinstall rsyncしても状況は変わらず...。
と思っていたら、/var/lib/dpkg/infoうっかり丸ごと削除からの復旧・解決策の時と同じ状況に...。
同じ対策をしてみたら、何度やってみても途中でフリーズしたり、処理途中で異常終了したり...。
ラズパイ2Bでやっていたのですが、そのうち、microSDカードもおかしなことに、7年ほど経っているので仕方ないか、と同じくらい経過も使っていなかったmicroSDカードで試してもダメ...。
ラズパイ2Bが壊れたわけじゃないよね?と思い、ラズパイ3B+でやってみるも前述の状況と同じ(もちろん、SSD側のfat32上のcmdline.txtでPARTUUIDをSSD上のext4パーティションのものに替えてUSBブート)。
よく考えてみれば、システムディスクとして使っているTranscend SSD 128GBは、既に7年くらいは経っているので無理もないか...。
というわけで約7年経過のTranscend 128GB SSDから巡り巡った約3年経過のA-DATA ASU650SS-120GT-Rへ換装。
128GBから120GBなんでfat32、ext4、それぞれパーティションごとにdd。
ちょっと遅いので怪しいかも...やっぱり、当初と同じカーネルパニック。
というか、そのままやったら、/dev/sdaをAttachedしたところで[random crng init done.]、こりゃUUID違うんじゃんということで/etc/fstabとblkid上のPARTUUIDが異なったので修正したらパニックに...なぜ...ってこれが壊れてるってことか、こりゃ、一からサーバ設定か...。
GPartedのパーティーション[チェック]やfsckも正常終了するんですけどね...なんで?
というわけでRaspberry Pi ImagerでRaspberry Pi OS Lite 64bitに書き込んでみたら、あっという間に完了、明日にでもゆっくり設定しよう。
ちなみに途中、AliExpressで買った黒い弁当箱タイプのSSDケース基盤、コネクタがもげて壊してしまいました。
A-DATAのSSDに基盤はちゃんと刺さってたのにケースに入れると何度やっても、もげた部分が浮く感じになり、とうとう壊れたみたいな。
約7年経過のラズパイ2BもmicroSDスロットもmicroSDもA-DATAのSSDも壊れておらず、ddした中身が壊れてたっぽいので、SSDに2Bなので32bit Raspberry Pi OS Liteを書き込み、一から設定することに。
と言っても今となっては、aptで入れるパッケージは、ufw、lvm2、avahi-u、tightvncserver、samba、smbclient、minidlna、claws mail、pulseaudio、fonts-ipafont-mincho、fonts-ipafont-gothic、ibus-kkc(fcitx-mozc)、他少々くらいですけどね。
と思いきや、2Bサーバにバックアップできなくなり、バックアップディスクにLVMを使っているので確認するとlvmのlvcreateができなかったり、既存のpvdisplay(pvs)/vgdisplay(vgs)/lvdisplay(lvs)でそれぞれ見えるのに/dev/mapper/VGNAME-LVNAMEがなく(できず)、/dev/VGNAME/LVNAMEもなかったり...。
他方、ラズパイ3B+に替えると正常に存在したりするのでSSDやバックアップ用HDDの故障ではないことはわかり一安心。
起動していたのに、ここにきてmicroSDなのか、ラズパイ2Bなのか、電源を入れてもLEDが点灯するのみ、点滅することもなく、うんともすんともいわなくなったり、もげたものとは別に白いプラのSSDケースも微妙、ということでサーバーはラズパイ3B+、SSDケースは先日買った青いアルミ製に置き換えることにしました。
2Bの動作確認の為、SSDには、32bit Raspberry Pi OSを入れたまま、クライアントは全て64ビットですが、まぁ、良いでしょう。
ちなみに青と同じところから買った赤いアルミ製SSDケースは、3B+で仕掛り中だったカメラサーバ用のSSDを入れましたが、肝心の3B+はNASを始めとするサーバ用となったので市場にダブつくほど出回るまではお預けかな。
微妙な白いプラのSSDケースは、Transcend SSDだとワンクッションあってちょっと遅いのが怪しいですが、オートマウントもできたりするんですよね。
AliExpressでばかり買っていて国産のSSDケースの方が良いのかなと思って買ったGroovyのSSDケースもありますが、他より少し電力欲しがりさんなのか、残念ながらラズパイとの相性が良くないので、微怪しい白のSSDケース、2Bと2Bで使っていたmicroSDカードやSSD、どんな感じで壊れているのか興味もあるので、もう少し様子見してみようかな。
壊れてたかと思ったラズパイ2B、microSDブートでSSDを起動するべく書き込んであったものの、SSDがどれだったか、UUID書き換えるのも、SSDを引っ張り出すのも面倒でmicroSDにImagerでブート及びシステムを書き込み、電源を入れてみたら、あっさり起動しました。
まだ使えるっぽい。
ACアダプタも同じもの、2BでもmicroSDカードでもなかったってこと?
はたまた、壊れかけで日をおいたら起動できちゃっただけなのか、単なる手違いだったのか...。
とはいえ、購入から7年数ヶ月の時を超えていますが、まだ使えそうで何より。