今回は、超小型KVMデバイス「NanoKVM」のOSストレージ（SDカード）を、128GBの無駄な大容量から8GBの適正サイズへダウンサイズ（縮小クローン）した際の備忘録です。
「容量の小さいカードにコピーするだけだし、ddコマンドとPiShrinkで一発でしょ？」と高を括っていたのですが……見事にLinuxコマンドの泥沼にハマりました。エラーと格闘しながら手動でパーティションを切り刻んでいく、ディープな解決手順をご覧ください。
舐めてかかった最初の dd コマンド
NanoKVMのシステム自体は数GBしかありません。しかしNanoKVMをセットアップする際に128GBのSDカードしか手元になく大容量SDカードにOSをインストールしました。
128GBのSDカードも高騰しておりもったいないので今回は必要最低限の8GBのSDカードへ環境をまるごと移行することにしました。
まずは定石通り、Ubuntu OSの入ったPCに128GBのSDカードを挿し、イメージファイルとして外付けSSDに吸い出します。
sudo dd if=/dev/sdX of=/外付けSSD/nanokvm_backup.img bs=4M status=progressしかし、これが長い戦いの始まりでした。
第1の沼：100GB地点のフリーズと ddrescue
順調に進んでいた dd コマンドの進捗バーが、ピッタリ100GB地点で完全にフリーズしました。
【原因】 SDカードの100GB地点に不良セクタ（物理的な寿命）が存在しており、几帳面な dd コマンドが「読めない！」とパニックを起こして無限リトライに陥っていたのです。
【解決策：ddrescueの投入】 エラー箇所に執着せず、読めない部分はサクッと無視してとにかく最後まで走り切ってくれるデータ救出のプロ ddrescue に選手交代します。
sudo apt install gddrescue
sudo ddrescue -f -n /dev/sdX /外付けSSD/nanokvm_backup.img /外付けSSD/rescue.logこれで不良セクタを華麗にスキップし、なんとか128GB分の .img ファイルを作成することに成功しました。
第2の沼：PiShrinkを拒絶する「exFATの壁」
吸い出した128GBのイメージファイルを、8GBに収まるようにダイエットさせます。ラズパイ界隈で有名な全自動縮小スクリプト PiShrink の出番です。
sudo ./pishrink.sh /外付けSSD/nanokvm_backup.imgこれで一発解決……と思いきや、無情にもエラーが。
tune2fs: Bad magic number in super-block while trying to open /dev/loop31 /dev/loop31 contains a exfat file system pishrink.sh: ERROR occurred in line 320: tune2fs failed. Unable to shrink this type of image【原因】 PiShrinkはLinux標準の ext4 しか自動縮小できません。しかし、NanoKVMはターゲットPCに対して「仮想USBメモリ」としても振る舞う機能があるため、イメージ内部に巨大なデータ共有領域（exFAT）が含まれていました。これを見たPiShrinkが「自分には処理できない！」とサジを投げてしまったのです。
最終奥義：losetup と GParted による手動解体
全自動ツールが使えないなら、手動で直接ファイルシステムをいじるしかありません。Linuxの強力なコマンド losetup を使い、単なるイメージファイルを「仮想的な物理ドライブ」としてUbuntuにマウントします。
① イメージを仮想ドライブ化
# -Pオプションで中のパーティション（p1, p2, p3）も個別に認識させる
sudo losetup -fP /外付けSSD/nanokvm_backup.img
# 割り当てられたデバイス名を確認（今回は /dev/loop31 でした）
lsblk② GPartedでゴリゴリ削る 仮想ドライブとして認識されれば、GUIのパーティション編集ツール GParted が使えます。
sudo gparted /dev/loop31GPartedの画面上で、PiShrinkを泣かせた一番後ろの巨大なexFATパーティション（約111GB）を右クリックして「削除」！ さらに、残ったシステム領域（ext4）を、8GBのSDカードに確実に収まるよう「6.5GB〜7.2GB」まで縮小（リサイズ）して適用します。
終わったら、忘れずに仮想ドライブを解除します。
sudo losetup -d /dev/loop315. 仕上げ：先頭の7.0GBだけを切り取って焼く
ここまで来れば勝ったも同然です。 イメージファイルの先頭約7.0GBにすべてのシステムデータが凝縮されたので、その部分だけを切り取って新しい8GBのSDカードに焼きます。
実際の使用領域は前述した通り1GB程度のため基本的には問題ありません。
# bs=1M と count=7500 で「先頭から7.5GB分だけ」を指定
sudo dd if=/外付けSSD/nanokvm_backup.img of=/dev/sdY bs=1M count=7000 status=progress
sync書き込み完了後、最後にファイルシステムが壊れていないか e2fsck で健康診断を行います。
まず書き込みしたSDカードをアンマウントするために名前を調べます。
lsblk
#結果
mmcblk0 179:0 0 7.2G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part /media/ubuntu/boot
└─mmcblk0p2 179:2 0 6.8G 0 part /media/ubuntu/rootfs以下のコマンドでアンマウントします。
sudo umount /dev/mmcblk0p1
sudo umount /dev/mmcblk0p2以下の
sudo e2fsck -f -y /dev/mmcblk0p2結果はクリーン！エラーの自動修復もゼロ。完璧なクローンSDカードが完成しました。
まとめ：全自動ツールがダメなら手で削れ！
このSDカードをNanoKVMに挿し込んだところ、何事もなかったかのように爆速で起動しました。
今回のダウンサイズ作業では、
- 不良セクタによる
ddのフリーズ - 特殊なパーティション構成による
PiShrinkの敗北 losetupによるイメージファイルの手動マウント＆解体
と、Linuxのストレージ操作に関するトラブルをフルコースで味わうことになりました。便利な全自動ツールもブラックボックスではありません。裏で何が起きているのかを理解し、いざという時にコマンドとGUIツールを組み合わせて手動で突破できると、対応力がグッと上がりますね。
同じようにNanoKVMのストレージ移行で謎のエラーに悩まされている方の参考になれば嬉しいです！
コメント