はじめに

訳あって以下の環境下でATDE9を利用していた。

環境	Version
VirtualBox	7.1.10
ATDE(*1)	9

*1

公式(アットマークテクノ)から提供されているATDEの仮想HDDはVMware形式なっている。

ATDEの容量は30GBになっているが、3つ程のプロジェクトを開発した時点で容量不足気味になっていた。そして今回、4つ目のプロジェクトの開発を進めようとしたのだが、podman system resetなど実施してもどーにもこーにもならない状態に。

そこで仮想HDDのサイズ変更に踏み切ったのだが、その際いきなりVirtualBoxのツールでサイズ変更を試してしまった。ATDEの仮想HDDがVMware形式であることを失念していたためである。(まぁ覚えておいたとしても、お、UIから簡単に変更できそうじゃん、って試しただろうけどｗ)

しかしというか案の定というか、変更を適用する途中でエラーとなり、さらには対象の仮想マシンが起動できなくなってしまった。参考までにこの時でたエラーを以下に。

起動時のエラー

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をテキストエディタで開いて、、、」という方法があったので実際にテキストエディタで開いてみると、以下の状態になっていた。

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までにしてみると動くかも、と言われたのでテキストエディタで以下のよう変更し、保存＆起動を試すとうまくいった。

atde9-amd64.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を実施するだけで、以下のように無事サイズ変更ができたのであった。

df -hの結果(抜粋)

root@atde9:/home/atmark# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
・
・
・
/dev/mapper/atde9--vg-root    48G   27G   20G   58% /
・
・
・