はじめに
訳あって以下の環境下でATDE9を利用していた。
環境 | Version |
---|---|
VirtualBox | 7.1.10 |
ATDE(*1) | 9 |
公式(アットマークテクノ)から提供されているATDEの仮想HDDはVMware形式なっている。
ATDEの容量は30GBになっているが、3つ程のプロジェクトを開発した時点で容量不足気味になっていた。そして今回、4つ目のプロジェクトの開発を進めようとしたのだが、podman system resetなど実施してもどーにもこーにもならない状態に。
そこで仮想HDDのサイズ変更に踏み切ったのだが、その際いきなりVirtualBoxのツールでサイズ変更を試してしまった。ATDEの仮想HDDがVMware形式であることを失念していたためである。(まぁ覚えておいたとしても、お、UIから簡単に変更できそうじゃん、って試しただろうけどw)
しかしというか案の定というか、変更を適用する途中でエラーとなり、さらには対象の仮想マシンが起動できなくなってしまった。参考までにこの時でたエラーを以下に。
Could not open the medium 'E:\VirtualBox VMs\ATDE9\atde9-amd64.vmdk'. VMDK: inconsistency between grain table and backup grain table in 'E:\VirtualBox VMs\ATDE9\atde9-amd64-s009.vmdk' (VERR_VD_VMDK_INVALID_HEADER). VD: error VERR_VD_VMDK_INVALID_HEADER opening image file 'E:\VirtualBox VMs\ATDE9\atde9-amd64.vmdk' (VERR_VD_VMDK_INVALID_HEADER). 終了コード : E_FAIL (0x80004005) コンポーネント: MediumWrap インターフェース: IMedium {7d510820-xxxx-xxxx-xxxx-818dcd3fbed0}
そこで本稿ではその修復方法と本来の増やし方を記載していく。
修復
まずは仮想マシンが再度起動するように修復する必要がある。
ChatGPTに聞くと4つの方法を提案された。1つ目・2つめは成功はしなかった。
3つ目に「atde9-amd64.vmdkをテキストエディタで開いて、、、」という方法があったので実際にテキストエディタで開いてみると、以下の状態になっていた。
# Extent description
RW 8323072 SPARSE "atde9-amd64-s001.vmdk"
・
・
・
RW 8323072 SPARSE "atde9-amd64-s008.vmdk"
RW 4192256 SPARSE "atde9-amd64-s009.vmdk"
・
・
・
RW 4192256 SPARSE "atde9-amd64-s019.vmdk"
RW 55296 SPARSE "atde9-amd64-s020.vmdk"
# The Disk Data Base
・
・
・
エクスプローラで"atde9-amd64-s0NN.vmdk"のファイルサイズをみても、明らかにatde9-amd64-s009.vmdk ~ atde9-amd64-s020.vmdkのサイズがおかしかった。
サイズ変更前の状態を確認していなかったので想像だが、変更前はatde9-amd64-s008.vmdkまで存在しており、サイズ変更によりatde9-amd64-s009.vmdk ~ atde9-amd64-s020.vmdkが追加されたのではないかと考えた。
この点もChatGPTに入力すると、atde9-amd64-s009.vmdk以降が壊れている可能性があり、atde9-amd64-s008.vmdkまでにしてみると動くかも、と言われたのでテキストエディタで以下のよう変更し、保存&起動を試すとうまくいった。
# Extent description
RW 8323072 SPARSE "atde9-amd64-s001.vmdk"
・
・
・
RW 8323072 SPARSE "atde9-amd64-s008.vmdk"
# The Disk Data Base
・
・
・
VMware形式 → VirutalBox形式への変換
これで振り出しに戻ることができたので、再度サイズ変更に挑戦。
サイズ変更に失敗したのはVMware形式の仮想HDDをVirtualBoxのツールで変更しようとしたために起きた可能性がありそうだったので、ここは素直にVirtualBox形式に変換を試してみる。
qemu-img convert -f vmdk -O vdi "E:\VirtualBox VMs\ATDE9\atde9-amd64.vmdk" "E:\VirtualBox VMs\ATDE9\atde9-amd64.vdi"
変換は問題なく完了し、仮想マシンに割り当てられているストレージをatde9-amd64.vmdkからatde9-amd64.vdiに変更して起動すると問題なく起動した。(VirtualBoxでみる仮想的なHDDサイズも50GBに)
パーティションの拡張とボリュームの拡張
あとはパーティションの拡張や(LVMを利用していたので)各ボリュームの拡張を実施していくのみである。
大まかな流れとしては以下の通り。
- パーティションの拡張(fdisk /dev/sda)
- LVMの物理ボリュームの拡張(pvresize /dev/sda5)
- ルート拡張(lvextend -l +100%FREE /dev/atde9-vg/root)
- ファイルシステム拡張(resize2fs /dev/atde9-vg/root)
ところが上記1の「パーティションの拡張」で詰まる。
拡張前のパーティション情報は以下の通り。
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 67106815 66105346 31.5G 5 Extended
/dev/sda5 1001472 67106815 66105344 31.5G 8e Linux LVM
ChatGPTで提示された手順の中にStartセクションの値は同じにする必要がある、とあるのだが/dev/sda5がfdiskで1003518に補正されて1001472が指定できないのである。
fdiskでパーティションを消したりしても、書き込まなければいくらでも試行錯誤できるので、その点だけは注意すること。
そこでさらにChatGPTに聞くと、どうやらMBR+DOSパーティション形式の「アライメント調整」が原因で、最近のfdiskはデフォルトで「1MiB(=2048セクタ)境界」にパーティションを合わせようとするため、勝手に補正されてしまうことがある、と回答があった。さらに提示された実行コマンドが以下であった。
fdisk -c=dos -u=sectors /dev/sda
そしてパーティション削除・再作成を再度実施することで、以下のようにすることができた。
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 104857599 103856130 49.5G 5 Extended
/dev/sda5 1001472 104857599 103856128 49.5G 8e Linux LVM
- Startセクションが同じ値にできつつ、Sizeも拡張できた(31.5G → 49.5G)っぽいので、ここでようやく書き込みを実施。
- /dev/sda5 を Linux LVM(8e)に変更しないといけないのも要注意。(最初に提示されたfdiskでの手順にid変更の話は出てこなかったが、Startセクションの件を色々と聞いているうちにふと出てきた)
その後は前述の手順の2~4を実施するだけで、以下のように無事サイズ変更ができたのであった。
root@atde9:/home/atmark# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
・
・
・
/dev/mapper/atde9--vg-root 48G 27G 20G 58% /
・
・
・