GParted で /boot パーティションを編集した VHDX が起動しないので色々試した結果 ( 初心者 )

親記事

Alma Linux 9 で GParted を使って パーティションを 拡張する ( 初心者向け )

※親記事に合わせているので、本投稿だけでは若干何しているかわからないと思うので、そういうひとは親記事を読んでください。( 拡張のところとか )

概要

Alma Linux 9 VM の /boot パーティションを GParted で拡張した結果、起動しなくなった。

• VMとして起動しているVHDXディスクをコピーし、GParted でパーティションテーブルを作成して初期化後、手動でパーティションを切った
• なのでもちろん /boot/efi や /boot パーティションも手動で切っている。
• いやコピーしろよって話だけど、そもそもコピーとかできるのってレベルで分かっていない初心者です。すみません。( vhdxをエクスプローラで複製したら GParted で未割り当てになってた )

ただの試行錯誤の記録なので、そのまま手順を実行しないでください。

最終的に私が取った末路

/boot パーティション拡張は諦めました。全然わからん。。こんなに分からなかったことは初めてです。環境構築こわい。

Linux で /boot パーティションの不足のエラーでたら、いさぎよく
仮想マシンごと作成し直して、十分な/boot パーティションのストレージを確保するほうが早いです。

環境

• 仮想ディスクのファイルシステムは、XFS ( 本投稿の中で ext4 あるいはext3 に変更し、WSL2 や Live ISO/Linux にマウントできるかたちにする )

• Hyper-V ( Alma Linux 9 VM )

パーティション構成

デバイス	パーティション
sda1	/boot/efi
sda2	/boot
sda3	/
sda4	/swap
sda5	/home

やってみたこと

とりあえず、確認もかねて。

• EFI system partition フラグを追加

1. /dev/sda1 を右クリック → 「フラグを編集」
2. msftdata のチェックを外す
3. boot と esp にチェックを入れる

対応方針

• WSL2 にマウントできる ext4 ファイルシステム に変更し、拡張し、起動できない原因をツールで調べる。あるいは resize2fs を使用して拡張する場合、ext3 に変換。
  
  

• 今回 ext4/ ext3 で拡張してもブートできなければ、GParted で パーティションを編集する前に 元々起動させていた Hyper-V の VM が xfs だったから起動しないわけではないので、あきらめて 、最初から /boot パーティションに余裕を持たせ、VM ( ext4/ ext3 で 起動。) ごと作成する。

※ 変換前の xfsの VHDX 仮想ディスクのバックアップは忘れずに。

案1. WSL2 でマウントしていろいろ (dmesgなど) 試す

Hyper-V ホストの Windows で Linux (wsl) にVHDXをマウントします。

/boot パーティションを ext4 に変更

.bash

mkfs.ext4 /dev/sda2

ついでに /, /home も xfs だったので一緒に変えておいてもいいが、あとでやることにします。（タイミングはお好きなように）

GRUB 関連を再インストール

パーティションのファイルシステムを変更したので、関連作業をおこなう。

.bash

# マウント ( /boot パーティション )
mkdir -p /mnt/boot
mount /dev/sda2 /mnt/boot
systemctl daemon-reload

# Linux パーティション ( たぶん 件の /boot ) に修復操作 をおこなう
grub-install --target=x86_64-efi --efi-directory=/mnt/boot/efi --bootloader-id=GRUB
update-grub
# grub の設定ファイル
grub-mkconfig -o /mnt/boot/grub/grub.cfg

.bash

# /dev/sda2 の UUID ( /boot ) を確認
blkid

# UUID を設定する
vim /etc/fstab
# /etc/fstabを編集したらおこなう
systemctl daemon-reload

# /etc/fstab

# / ( root ) パーティション
UUID=xxxxx-xxxx   /       ext4    defaults    0   1
# /dev/sda2 ( /boot パーティション ) の UUID
UUID=yyyyy-yyyy   /boot   ext4    defaults    0   2
# EFI パーティション
UUID=zzzzz-zzzz   /boot/efi vfat  umask=0077  0   1

LiveISO でマウントする理由 (Chatgpt)

GRUB 修復やインストール操作を可能にするための準備なんです。

🧠 なぜマウントが必要か？（目的）

GRUB の設定やインストールは、対象 Linux 環境内で行う必要があります。ただし、Live ISO 環境はあくまで一時的な環境なので、以下のような流れになります：

1. VHDX に含まれる Linux のルートパーティションや /boot を Live ISO 側からマウント
2. GRUB の設定ファイル（grub.cfg）や EFI フックを Live ISO から操作するために chroot 環境を構成
3. grub-install や update-grub を chroot 環境内で実行し、実際の Linux パーティションに対して修復操作を行う

🔄 例えるなら…
Live ISO は “作業員”
対象の Linux ルートパーティションと /boot は “壊れた建物”
マウントと chroot は “作業員を建物の中に連れていく梯子”

なので、マウントしないと建物の中には入れず、修復もできないわけです。

WSL2 にマウント

失敗 ( ここで 案 1 は中断 → 案 2 へ )

wsl --mount "C:\Users\kosuke\Documents\AlmaLinux9WebTest_ext4ConvertedTest.vhdx" --partition 2
ディスク 'C:\Users\kosuke\Documents\AlmaLinux9WebTest_ext4ConvertedTest.vhdx' を WSL2 にアタッチ できませんでした: プロセスはファイルにアクセスできません。別のプロセスが使用中です。
エラー コード: Wsl/Service/AttachDisk/MountDisk/ERROR_SHARING_VIOLATION

プロセスを確認してみたけど、ない。ってことはマウント後で自動で消えたか、そもそもプロセスは動かなかった。ただ「マウントに失敗」。出た、Microsoftの何にもヒントにならないメッセージ。それならプロセスは〜のくだりいらないでしょ

# mount のプロセスを取得
Get-Process | Where-Object { $_.ProcessName -like "*mount*" }
# 出力なんもなし

Get-Process -Name mount
Get-Process : 名前 "mount" のプロセスが見つかりません。プロセス名を確認し、コマンドレットを再度
呼び出してください

案2.xfs_growfs を使ってみる

この方法は、/boot パーティションには使えません。UEFI, grub の設定を行わないといけないようです。初心者には難しいです。

• これは、root パーティションや /home パーティションのために使える方法です。
• 今回は /boot パーティションの拡張が目的ですので、以下の手順は検証していません。

Alma Linux の Live 環境 (※1) や Ubuntu で、dd、resize2fs xfs_growfs コマンドで拡張する。

• 今回、手元に Live 環境をイチから起動できるマシンがなかったので 、Ubuntu Desktop の物理環境 (※2) を使いました。

※1 → ただし、Live環境を起動できる物理マシン (OS 未インストールの状態) が必要.

※2 → Hyper-V の Ubuntu VM でも可いと思います。物理マシンじゃなくても Ubuntu & .VHDX が読めればok。

大体の流れ

(1) ファイルコンテナ作成

仮想ドライブボリュームを保持するためのファイルを作成します。

• (オプションで) なにかしらのデータで埋めてファイルを初期化

1.ボリュームをフォーマット

2.ボリュームをマウントして使用できる状態にする

(2) 仮想ドライブボリュームのリサイズ

1.xfsを ext3 に変換。 ファイルシステムの指定

• Ubuntu や Live ISO ( CentOS 8か Stream, Alma Linux 9 )を使って、mkfs でファイルシステムを ext3 xfs にする。

2.(1) で作成した仮想ドライブボリュームファイルを介して、マウント先の Linux 環境 ( Ubuntu や Live ISO レスキューモード ) から ddコマンドで拡張。

**注意: alma Linux のLive ISO ( USB ) は、Hyper-V では認識できない。**なので、物理的な環境を使う。( 今回はUbuntu の実マシン )

3.resize2fs xfs_growfs でターゲットのパーティションにリサイズをかける

詳細な手順

【レスキューモードで拡張する場合】
必要なもの (任意) : レスキューモードで Live 起動するための USB フラッシュメモリ

※ 今回は Ubuntu でやるので、Live 起動はしません。なのでレスキューモードのでのこのやり方は、 参考までに。

• Alma Linux Live ISOを使って、VMを起動。

• 「Troubleshooting」→「Rescue a CentOS system」 を選択。

【Ubuntuで拡張する場合】

今回は、こちらの方法を選択しました。手順は、どちらの場合でも同じ。

仮想ドライブボリュームファイル作成・初期化・マウント

必要なもの: Windows あるいは VM のホスト側のマシンから VHDX ファイル ( 対象の仮想ディスク ) を 共有する USBフラッシュメモリ

まず、USBメモリを Ubuntu に接続。

次に以下を実行。

.bash

# 仮想ドライブボリュームを保持する新しいファイルを作成
fallocate -l 500M MyDrive.vhdx

# (たぶん) 仮想ドライブボリューム全体のサイズが変わらないように 0バイトのデータで埋める
dd if=/dev/zero of=MyDrive.vhdx bs=1M count=500       # 500MiBの仮想ドライブボリュームファイル作成
mkfs -t xfs MyDrive.vhdx                                # ext3でフォーマット

mount -t auto -o loop MyDrive.vhdx /some/mount/point # 指定したマウントポイントに 仮想ディスクをマウント ( MyDrive.vhdxは、loopマウントする必要がある ) 

VHDの拡張（+1GiB）

.bash

truncate -s +1G MyDrive.vhdx                          # 拡張

sudo losetup -fP MyDrive.vhdx
                          # VHDXをループバックデバイスに接続
                          
xfs_growfs /dev/loop0                                # xfsファイルシステムを拡張

/dev/zeroからファイルを作成する

Linuxには、ユーザーが尋ねなくなるまでひたすらゼロを生成する便利な組み込みツールが搭載されています。このツールを「読み込み」、この目的のために作成したファイルに出力することで活用できます。

.bash

dd if=/dev/zero of=~/zeroes 
sudo sync 
rm ~/zeroes

物理システムでは、この操作はファイルシステム内の未使用ブロックすべてに文字通りゼロを書き込むため、常に非常に長い時間がかかります。
Hyper-V は、書き込まれるビットがゼロであると認識します。そのため、まだ拡張されていないブロックに遭遇した場合、書き込みは無視されます。ただし、データを含むブロックはゼロで埋められるため、それでも時間がかかることがあります。
つまり、fstrimほど高速ではありませんが、VHDXのサイズがこれ以上大きくなることもありません。

参考

結論

初心者は /boot パーティション不足のエラーが出たら諦めましょう。

• 仮想マシンごと作成し直して、十分な/boot パーティションのストレージを確保しましょう。サイズは慎重に調査してから決めましょう。ChatGpt にきいて鵜呑みにすると、私のように痛い目をくらいます。

感想

理解していないことに色々手を出すもんじゃないですね。/boot パーティションは結局、拡張の仕方がよく分かりませんでした。初心者がやるもんじゃないです。