GPartedによる/bootパーティションの拡張
序論
背景
Fedora 43が2025年10月にリリースされました。 そこで以下の変更点が告知されました。
Changes in Fedora 43 For System Administrators - #Default /boot partition is now 2G
従来は/bootパーティションの推奨サイズが1 GiBでしたが、今後は2 GiBになります。
私の環境では/bootの使用率はまだ50%程度です。
(※) GPUなど追加のドライバを要求するハードウェアを搭載している方は使用率が高いかもしれません。そういった方は対策したほうが良さそうです
大丈夫です。 まだ慌てるときではありません。
ですが、今後時間が経つにつれて/bootのサイズは徐々に大きくなってきます。
その前にPCが壊れてOS入れ直しになる気はするものの...良い機会なので/bootの拡張にチャレンジすることにしました。
やりたいこと
下図のように、/bootパーティションを拡張します。
Fedora 43の要件を満たすには2 GiBに拡張すれば十分ですが、数年後にまた拡張が必要になるのは嫌なので少し大きめに拡張します。
(※) 流石に8 GiBへの拡張はやりすぎました。GPUを搭載する可能性を考慮しても、さすがに4 GiBで良かったと今は思います
ご参考までに、現在のパーティションサイズとファイルシステム構成を確認するコマンドも貼っておきます。
sudo fdisk /dev/nvme0n1 -l # (snip) # Device Start End Sectors Size Type # /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System # /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem # /dev/nvme0n1p3 3328000 1953523711 1950195712 929.9G Linux LVM df --output=source,fstype,size,target -h /boot/efi /boot / /home # Filesystem Type Size Mounted on # /dev/nvme0n1p1 vfat 599M /boot/efi # /dev/nvme0n1p2 ext4 974M /boot # /dev/mapper/fedora_pc-root ext4 49G / # /dev/mapper/fedora_pc-home ext4 865G /home
/bootパーティション拡張の難しいところ
/bootの拡張は思ったよりも厄介です。
なぜなら、/bootを拡張するには、後続のパーティション3 (/dev/nvme0n1p3) の先頭アドレスを2 GiB分空けてもらわなければならないためです。
「若番のパーティション拡張」というのは、後ろのパーティションを動かさないことには実現できません。
嫌な予感がしてきましたね。
/bootが枯渇するまで放置...？
OS再構築...？
rsyncでファイルを退避して、パーティションを書き換えてからリストアするのはどうか？
live USBでFedora Cinnamon Spinを起動して、ローカルディスクから外付けHDDにファイルをフルバックアップ。
ローカルディスクに新たなパーティション構成でFedora 43を新規インストール。
その後、またlive USBで起動し、外付けHDDからファイルを書き戻せば...？
コマンドの行数で言えば約20行です。
rsync -a -ADHRSX -vi --delete --force --statsというコマンドラインオプションも過去の経験で知っています。
...とはいえ、GUI操作と放置時間もあるので中々の苦行です。
前置きが長くなりましたが、そんなことはしなくても大丈夫です。 GPartedというツールが救世主でした。
GParted
GParted (GNOME Partition Editor) は、GUIベースのパーティションエディタです。
GPLv2 (またはそれ以降) のライセンスが適用されたOSSです。
GNOME Partition Editor
パーティションを編集するコマンドとしてfdiskやpartedなどがありますが、GPartedはfdiskやpartedにはない機能があります。
それは、パーティションの移動という機能です。
(※) 他にもすごい機能がたくさんあるようです
パーティションの移動機能は、下図のとおりまさに今回必要としている機能でした。
作業に必要なハードウェア
前置きが長くなりましたが、いよいよ本編に入ります。
まずは、作業に必要なハードウェアを揃えましょう。
- 容量1 GiB以上のUSB x 2
- (※) USB内のデータは全て上書きされます
- データバックアップ先のディスク (外付けHDDなど)
GPartedを動かすだけならUSB 1つだけで十分です。 ルートファイルシステムをアンマウントした状態で作業するため、今回はGPartedをLive USBから起動する構成を取ります。
作業前にバックアップを取る場合は、追加でUSB1つとディスク1つを用意します。
(※) 詳細はこのあと書きますが、今回はClonezillaというバックアップツールをご紹介します。Clonezillaの起動にはUSBが必要です
Clonezillaによるバックアップ
(参考) Clonezillaとは
GUI操作でディスク丸ごとバックアップ・リストア・複製する機能を提供するOSSです。 使用済みのディスクブロックを複製するという動作原理です。
ファイルバックアップソリューションのrsyncと比較すると、主に以下の違いがあります。
- 復元対象
- 差分バックアップの可否
今回はパーティションを破壊する可能性があるため、Clonezillaでバックアップを取ります。
Clonezilla Live USBの作成
まずはClonezilla Live Imageをダウンロードします。
Clonezilla Live Downloadにアクセスし、alternative stable (Ubuntu-based)をダウンロードします。
stable (Debian-based)との違いは、より多くのドライバを含んでいることです。
ハードウェア互換性の問題が発生する可能性を少しでも減らすため、ここはUbuntu版を使っておきましょう。
参考: Why stable and testing Clonezilla live are based on Debian, but alternative one is based on Ubuntu ?
続いて、ダウンロードしたISOファイルを用意したUSBに書き込みます。 Fedoraをお使いでしたらFedora Media Writer (GUIツール)が有名です。 以下のコマンドでインストールできます。
sudo dnf install mediawriter
Fedora Media Writerを起動したら、最初にSelect .iso fileを選択し、あとは画面の流れに従ってISOファイル内のデータをUSBに書き込みます。
Clonezilla Live USBから起動する
作成したUSBをPC本体に挿して電源を入れます。 そして起動順序の指定画面を開き、Clonezillaのイメージを書き込んだUSBから起動します。
"起動順序の指定画面" の開き方は、お使いのPCによって異なります。 私が使っているNUC10でしたら "F7キー連打" ですが、PCによってはF12キーや異なるキーである可能性があります。 詳しくはPCやマザーボードの説明書をご参照ください。
Clonezillaのバックアップ操作
その後はTUI画面で操作を続けます。 基本的には画面に従ってデフォルトの選択肢を選んでいくだけでバックアップ操作が完了します。
具体的な操作画面は、以下の動画が参考になります。
投稿主は英語話者ですが、YouTubeの字幕機能で日本語字幕を出せますのでご安心ください。
"5:45" あたりからClonezillaによるバックアップ操作の説明が始まります。
YouTube - Veronica Explains - Clonezilla: disk cloning, but it's easier than dd
ここでは具体的な操作方法を簡単に示すのみにとどめます。
| # | 画面のタイトル / プロンプト | 実施すべき操作 |
|---|---|---|
| 1 | GNU GRUB (オレンジと白の画面) |
Clonezilla live (VGA 800x600)(デフォルト) |
| 2 | Choose language | en_US.UTF-8 (English)(デフォルト) |
| 3 | Keyboard configuration | Keep(デフォルト) |
| 4 | Start Clonezilla | Start_Clonezilla(デフォルト) |
| 5 | Clonezilla - Opensource Clone System (OCS) | device-image(デフォルト) (※) イメージファイルを生成するバックアップ方式 |
| 6 | Mount Clonezilla image directory | local_dev(デフォルト) (※) バックアップ先の領域を選択。外付けHDDならlocal_dev。環境に応じて変更すること |
| 7 | Press "Enter" to continue...... (※) 下半分の黒画面の最後の行 |
バックアップ先のデバイスを接続した上でEnterキーを押す |
| 8 | Press Ctrl-C to exit this window. (※) 黒画面の最後の行 |
バックアップ先のデバイスが表示されていることを確認し、Ctrl+Cを押す |
| 9 | Clonezilla - Opensource Clone System (OCS) | Mode: | バックアップ先のデバイスを選択する |
| 10 | Clonezilla - Opensource Clone System (OCS): REPOSITORY | no-fsck(デフォルト) (※) ファイルシステム未作成だと This directory is not a mount pointとエラーになる |
| 11 | Directory Browser for Clonezilla image repository | Done(※) ディレクトリパスを指定。Clonezillaはこのパス配下にディレクトリをもう1つ作成し、イメージを書き込む |
| 12 | Press "Enter" to continue...... (※) 下半分の黒画面の最後の行 |
Enterキーを押す(デフォルト) |
| 13 | Do you want to synchronyze the time...[Y/n] |
y(デフォルト) |
| 14 | No Internet connection was found... Press "Enter" to continue...... |
Enterキーを押す(※) インターネット接続がなくNTP同期に失敗したため、BIOSクロックを参照する |
| 15 | Please choose your time zone... ...you want to continue? (Y/n) |
y(デフォルト) |
| 16 | Configuring tzdata | Asia(※) aキーを複数回押すとカーソル移動が早い |
| 17 | Configuring tzdata | Tokyo(※) tキーを複数回押すとカーソル移動が早い |
| 18 | Press "Enter" to continue...... | Enterキーを押す(デフォルト) |
| 19 | Clonezilla - Opensource Clone System (OCS) | Beginner(デフォルト) |
| 20 | Clonezilla - Opensource Clone System (OCS): Select mode | savedisk(デフォルト) |
| 21 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | yyyy-mm-dd-img(※) バックアップイメージを格納するディレクトリ名を指定。変えても変えなくても良い |
| 22 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | バックアップ対象のディスクを指定 |
| 23 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | -z9p(デフォルト) |
| 24 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | -sfsck(デフォルト) |
| 25 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | Yes, check the saved image(デフォルト) |
| 26 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | -senc(デフォルト) |
| 27 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | -plu(デフォルト) |
| 28 | Clonezilla - Opensource Clone System (OCS) | Mode: savedisk | -p poweroff(※) バックアップ先の容量不足などで失敗した場合は電源オフされずエラー表示してくれる |
| 29 | Press "Enter" to continue... | Enterキーを押す(デフォルト) (※) TUI操作の選択肢と同等のコマンドを表示してくれる |
| 30 | Are you sure you want to continue? (y/n) | y(※) バックアップ元・バックアップ先情報の確認画面 |
(参考) Clonezillaのリストア操作
リストア操作は、バックアップとほぼ同じです。 以下の部分のみ操作が変わります。
- 20にて、restorediskを選択
- 21にて、イメージバックアップ先ディレクトリ (
yyyy-mm-dd-img) が見える状態で<Done>を選択する - 続いてリストアに使用するイメージ名を選択する (
yyyy-mm-dd-img) - パーティションテーブル選択画面では
-k0を選択 (デフォルト)
GPartedによるパーティション移動
ディスクのバックアップを取得できたので、いよいよ/bootの拡張に移ります。
GParted Live USBの作成
#Clonezilla Live USBの作成と同様の手順で、GParted Live USBを作成します。
GUIを付属したLive USBであれば何を使っても大丈夫です。
今回はFedora Cinnamon Spinをダウンロードします。
(※) 他のイメージを使う方は必要に応じて読み替えてください
ダウンロードしたISOファイルを、Clonezillaのときと同様の手順でUSBに書き込みます。
GParted Live USBから起動する
#Clonezilla Live USBから起動するのときと同様に、GParted Live USBからマシンを起動します。
起動メニューを適切に選択し、Linuxを起動します。
ターミナルを起動し、以下のコマンドでGPartedをインストールします。
sudo dnf install -y gparted
/bootの隣接パーティションを7 GiB縮小する
準備は整いました。
/boot拡張作業の内容を改めて確認しましょう。
まずは、/bootに7 GiBを追加で確保するために、隣接するパーティションを7 GiB縮小します。
今回は仮想マシンで作業内容を再現しつつブログを書いているので、LVMのVGは/のみです。
/homeは分かれていない構成となりますが、ご了承ください。
パーティションを書き換えるデバイスを確認します。
パーティション数、ファイルシステム情報 (ext4)、LVMフラグなどの情報から/dev/vdaが作業対象と理解します。
/dev/vda3はext4ファイルシステムであるため、ファイルシステムの縮小に対応することもわかります。
RHEL10 - Managing file systems - 1.5. Comparison of XFS and ext4
sudo -i lsblk --fs # NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS # (snip) # vda # ├─vda1 # ├─vda2 ext4 1.0 4150e5a1-0b75-42a4-b844-30cdaf5e871e # └─vda3 LVM2_member LVM2 001 A9Qc6e-sVC0-FF1L-uSv2-kiAy-81Uv-eT9W5c # └─fedora-root # ext4 1.0 e881b911-fab2-41a4-96e1-10625564b47c
/dev/vdaのパーティションテーブルから詳細を確認します。
以下の用途であると確認できます。
/dev/vda1: EFIパーティション。UEFIブートローダーを利用する場合は必要な領域/dev/vda2:/bootパーティション。今は1 GiBだが、8 GiBに拡張したい/dev/vda3: LVM領域。今は26 GiBだが、19 GiBに縮小したい
fdisk -l /dev/vda # Disk /dev/vda: 27 GiB, 28991029248 bytes, 56623104 sectors # Units: sectors of 1 * 512 = 512 bytes # Sector size (logical/physical): 512 bytes / 512 bytes # I/O size (minimum/optimal): 512 bytes / 512 bytes # Disklabel type: gpt # Disk identifier: BE0547C7-0175-42B2-AA31-EA72BA85D98C # Device Start End Sectors Size Type # /dev/vda1 2048 4095 2048 1M BIOS boot # /dev/vda2 4096 2101247 2097152 1G Linux filesystem # /dev/vda3 2101248 56623070 54521823 26G Linux LVM
LVMを構成するLV (Logical Volume) のサイズを確認します。 26 GiB程度のサイズであるとわかります。
lvdisplay # --- Logical volume --- # LV Path /dev/fedora/root # LV Name root # VG Name fedora # LV UUID 5Ec62m-HIrH-xkp1-IkAq-xJxI-h32O-MDBZeT # LV Write Access read/write # LV Creation host, time localhost.localdomain, 2026-01-04 09:17:05 -0500 # LV Status available # # open 0 # LV Size <26.00 GiB # Current LE 6655 # Segments 1 # Allocation inherit # Read ahead sectors auto # - currently set to 16384 # Block device 252:0
ファイルシステムの使用量を確認するため、マウントしてdfコマンドを実行します。
(※) GPartedの操作を行うために、後でアンマウントする必要があります
容量は26 GiBあり、21 GiBは空き容量であることがわかります。 7 GiBの縮小には十分耐えられます。
mkdir /mnt/sysroot mount /dev/fedora/root /mnt/sysroot -o ro df -h /mnt/sysroot # Filesystem Size Used Avail Use% Mounted on # /dev/mapper/fedora-root 26G 4.1G 21G 17% /mnt/sysroot
では、いよいよファイルシステムとLVを同時に7 GiB縮小します。
lvredudceはLVの領域を縮小するコマンドですが、-rをつけることでlvreduceコマンドが対応するファイルシステムの縮小を直前に実施してくれます。
man lvreduce
lvreduceコマンドのオプションの説明を以下に貼っておきます。
| オプション | 意味 |
|---|---|
| -l size, --extents size |
縮小後のLVのサイズ。 数値のみ記載した場合、LE (Logical Extent) 数での指定となる。 他に %を後置した動的な指定も可能。・ %VG: VGの総容量・ %FREE: VGの空き容量・ %PVS: 指定したPVの空き容量・ %ORIGIN: スナップショット元 (Original) のVGの合計サイズ(LVM Snapshot領域のLVに対して使う) +か-を先頭に付けると、今のLV Sizeに対する相対値になる。-L, --sizeと併用すると、sizeが上限値となる |
| -L size, --size size |
縮小後のLVのサイズ。 単位としてbBsSkKmMgGtTpPeEが使える。 bBはByte, sSはセクタ, kKは1024Bといった意味。 +か-をつけると、今のLV Sizeに対する相対値になる。 -L, --sizeの代わりに-l,--extentsを使ってもよい |
| -r, --resizefs |
ファイルシステムのサイズ変更も同時に行う。 内部的にはファイルシステム固有のリサイズコマンドを実行する。 詳細はman fsadmを参照 |
| -t, --test |
テストモード実行になる。 LVMのメタデータを書き込まずに成功扱いで終了する |
| -v, --verbose |
より詳細な情報を画面出力する。 -vを複数指定するとより詳細に出力する (最大4回) |
| -d, --debug |
syslogにも結果を出力する。 -dを複数指定するとより詳細に出力する (最大6回) |
まずは-tをつけてテスト実行します。
テスト実行により以下のことがわかります。
- 26 GiBから19 GiBに縮小している
fsckとresize2fsによるファイルシステム縮小を実施している
lvreduce -r -L -7G /dev/fedora/root -t # TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated. # File system ext4 found on fedora/root mounted at /mnt/sysroot. # File system size (<26.00 GiB) is larger than the requested size (<19.00 GiB). # File system reduce is required using resize2fs. # File system unmount is needed for reduce. # File system fsck will be run before reduce. # Continue with ext4 file system reduce steps: unmount, fsck, resize2fs? [y/n]:y # Skip unmount in test mode. # Skip fsck in test mode. # Skip fs reduce in test mode. # Size of logical volume fedora/root changed from <26.00 GiB (6655 extents) to <19.00 GiB (4863 extents). # Logical volume fedora/root successfully resized.
変更内容が想定通りかつ、エラーにもならなかったので本実行します。
lvreduce -r -L -7G /dev/fedora/root # File system ext4 found on fedora/root mounted at /mnt/sysroot. # File system size (<26.00 GiB) is larger than the requested size (<19.00 GiB). # File system reduce is required using resize2fs. # File system unmount is needed for reduce. # File system fsck will be run before reduce. # Continue with ext4 file system reduce steps: unmount, fsck, resize2fs? [y/n]:y # Reducing file system ext4 to <19.00 GiB (20396900352 bytes) on fedora/root... # unmount /mnt/sysroot # unmount done # e2fsck /dev/fedora/root # /dev/fedora/root: 57890/1703936 files (0.1% non-contiguous), 1202895/6814720 blocks # e2fsck done # resize2fs /dev/fedora/root 19918848k # resize2fs 1.47.3 (8-Jul-2025) # Resizing the filesystem on /dev/fedora/root to 4979712 (4k) blocks. # The filesystem on /dev/fedora/root is now 4979712 (4k) blocks long. # resize2fs done # remount /dev/fedora/root /mnt/sysroot # remount done # Reduced file system ext4 on fedora/root. # Size of logical volume fedora/root changed from <26.00 GiB (6655 extents) to <19.00 GiB (4863 extents). # Logical volume fedora/root successfully resized.
ファイルシステムとLVが26Gから19Gに縮小されたことを確認します。
df -h /mnt/sysroot/ # Filesystem Size Used Avail Use% Mounted on # /dev/mapper/fedora-root 19G 4.1G 14G 23% /mnt/sysroot lvdisplay # --- Logical volume --- # LV Path /dev/fedora/root # LV Name root # VG Name fedora # LV UUID 5Ec62m-HIrH-xkp1-IkAq-xJxI-h32O-MDBZeT # LV Write Access read/write # LV Creation host, time localhost.localdomain, 2026-01-04 09:17:05 -0500 # LV Status available # # open 1 # LV Size <19.00 GiB # Current LE 4863 # Segments 1 # Allocation inherit # Read ahead sectors auto # - currently set to 16384 # Block device 252:0
GPartedの操作を行うために、操作対象のパーティションに属するファイルシステムをアンマウントします。
umount /mnt/sysroot
↓続いて、GUIでGPartedを起動します。 右上のドロップダウンリストで操作対象のデバイスが選択されていることを確認します。 また、LVMの行に鍵マークがついていることを確認します。 LVMが有効状態 (activate) 状態だとGPartedによる操作を行うことができません。 次工程で無効化し、鍵マークを外したあとで操作を続行します。
↓LVMの行を右クリックし、Deactivateを選択してLVMパーティションを編集可能な状態にします。
この操作は即時反映されます。
↓LVMの行を右クリックし、Resize/Moveからパーティション/LVM/ファイルシステムの編集画面に移動します。
↓今回はディスクアドレスの前半部分を7 GiB分空けたいので、Free space preceding (MiB)に7168 (※) と入力します。
すると、New size (MiB)が自動的に更新されて7168だけ減算されます。
最後にResize/Moveボタンをクリックして編集画面を閉じます。
(※) 7 GiB = 7 * 1024 MiB = 7168 MiB
↓定型文の警告が表示されます。 構わずOKを押します。 バックアップを取っていれば大丈夫です。
↓/bootの後ろに7 GiBの空きができたことを確認します。
この時点ではまだ「変更後の想定状態」を画面表示しているだけで、実際のパーティションは書き換わっていません。
チェックマークをクリックして変更を反映します。
(※) この後の/bootの拡張まで実施してから反映しても良いのですが、この時点でも想定外のエラーが出る可能性があります。エラーの発生箇所を特定しやすくするため、細かく刻んで反映しておきます。
↓処理結果が表示されます。
全行にチェックマークがついていることから、一連の反映処理が成功したことがわかります。
Closeで結果画面を閉じます。
↓忘れないうちにLVMを再度有効化しておきます。
LVMの行を右クリックし、Activateを選択します。
/bootを7 GiB拡張する
引き続きGPartedで操作を続行します。
↓/bootを拡張します。
/bootの行を右クリックし、Resize/Moveからパーティション/LVM/ファイルシステムの編集画面に移動します。
↓今回は7 GiB分拡張して合計8 GiBに変更したいので、New size (MiB)に8192 (※) と入力します。
すると、Free space preceding (MiB)が自動的に更新されて7168だけ減算されます。
最後にResize/Moveボタンをクリックして編集画面を閉じます。
(※) 8 GiB = 8 * 1024 MiB = 8192 MiB
↓最後にチェックマークをクリックして変更を反映します。
↓定型文の警告が表示されるのでApplyを選択します。
↓処理の成功を確認して画面を閉じます。
事後確認
上記スクリーンショットを見る限り、GParted上は目的の状態になったことを確認できました。 最後に、コマンドベースで目的の状態になったことを細かく確認していきます。
dfコマンドで容量を確認するために、確認したいディスクをマウントします。
(※) 最後のLVM領域のマウントに失敗した場合は、GParted上のLVM領域のactivate忘れを疑ってください。activateを忘れた場合は、lvdisplayのコマンド上もLV StatusがNOT availableと表示されます
sudo -i lsblk /dev/vda --fs # NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS # vda # ├─vda1 # ├─vda2 ext4 1.0 4150e5a1-0b75-42a4-b844-30cdaf5e871e # └─vda3 LVM2_member LVM2 001 A9Qc6e-sVC0-FF1L-uSv2-kiAy-81Uv-eT9W5c lvdisplay # --- Logical volume --- # LV Path /dev/fedora/root # LV Name root # VG Name fedora # LV UUID 5Ec62m-HIrH-xkp1-IkAq-xJxI-h32O-MDBZeT # LV Write Access read/write # LV Creation host, time localhost.localdomain, 2026-01-04 09:17:05 -0500 # LV Status available # LV Size <19.00 GiB # Current LE 4863 # Segments 1 # Allocation inherit # Read ahead sectors auto mkdir -p /mnt/sysroot/boot mount /dev/fedora/root /mnt/sysroot/ -o ro mount /dev/vda2 /mnt/sysroot/boot -o ro df -h /mnt/sysroot/boot /mnt/sysroot # Filesystem Size Used Avail Use% Mounted on # /dev/vda2 7.9G 311M 7.2G 5% /mnt/sysroot/boot # /dev/mapper/fedora-root 19G 4.1G 14G 23% /mnt/sysroot
参考情報
(参考) Clonezillaのイメージファイルからファイルを取り出す
Clonezillaにより取得したイメージファイルからファイルを取り出す手順を解説します。
本手順は、以下の公式情報を参考にしました。
How can I restore those *-ptcl-img.* images into a file manually ?
まずは必要なプログラムをインストールします。
sudo dnf install partclone
続いてバックアップディスクを特定します。
今回は/dev/vdb1だったとします。
# バックアップ先のデバイスファイルを特定する # 今回は/dev/vdb1だったとする lsblk # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS # (snip) # vda 253:0 0 20G 0 disk # ├─vda1 253:1 0 1M 0 part # ├─vda2 253:2 0 1G 0 part /boot # └─vda3 253:3 0 19G 0 part # └─fedora-root 252:0 0 19G 0 lvm / # vdb 253:16 0 20G 0 disk # └─vdb1 253:17 0 18.6G 0 part
適当なパスにバックアップディスクをマウントします。
今回は/mntのサブディレクトリをマウントポイントとします。
man hier - #/mnt
さらにバックアップ情報を含むイメージファイル名を特定します。
今回はrootファイルシステムに対応するfedora-root.ext4-ptcl-img.zstがPartcloneイメージファイル名だったとします。
# 適当なパスにマウントする sudo mkdir /mnt/backup sudo mount /dev/vdb1 /mnt/backup -o ro # イメージファイルを確認する # 今回はfedora-root.ext4-ptcl-img.zstのファイルを取り出す (rootファイルシステム) ls -1 /mnt/backup/2026-01-12-17-img/*.zst # /mnt/2026-01-12-17-img/fedora-root.ext4-ptcl-img.zst # /mnt/2026-01-12-17-img/vda1.dd-ptcl-img.zst # /mnt/2026-01-12-17-img/vda2.ext4-ptcl-img.zst
圧縮されたPartcloneイメージファイルから、loopデバイスとしてマウント可能な形式のファイルを生成します。
生成するイメージファイルは、バックアップされたパーティションと同じサイズを持ちます。
展開先のファイルシステムに十分な空き領域があることをご確認ください。
(※) loopデバイスとは、ブロックデバイスのようにマウント可能な疑似デバイスファイルのことです (Wikipedia - Loop device)
cat /mnt/backup/2026-01-12-17-img/fedora-root.ext4-ptcl-img.zst | zstd -d -c | partclone.ext4 -r --restore_raw_file -s - -o fedora-root.ext4.img
loopデバイスをマウントします。
あとはマウント先の/mnt/oldrootから好きなようにファイルを取り出せます。
sudo mkdir /mnt/oldroot sudo mount fedora-root.ext4.img /mnt/oldroot -o ro ls /mnt/oldroot/ # afs boot etc lib lost+found mnt proc run srv tmp var # bin dev home lib64 media opt root sbin sys usr
(参考) GParted上でLVM領域のMoveに失敗する
LVM領域の縮小は以下の流れで実行します。
lvreduce -r ...コマンドによりファイルシステムとLVを縮小する- GParted上でLVMをdeactivateする (コマンドでも可)
- GParted上でLVMをmoveする (ディスクブロックの前半アドレスを削ることでパーティションを縮小する)
この中で曲者なのがpvresizeコマンドによるPVの縮小です。
うまく行かないときは、以下のエラーが発生します。
cannot resize to XXX extents as later ones are allocated
このエラーに対する解決策は、以下のブログに書いてあります。
私は上記ブログ情報とman pvresize - #NOTES、man pvs、man pvmoveの組み合わせで解決しましたが、情報源を補完する意味で以下のリンクも掲載しておきます。
- Unix & Linux - How to shrink LVM physical volume with free space
- Red Hat knowledge base - pvresize fails with cannot resize to extents as later ones are allocated message.
- Red Hatアカウントのログインが必要です
以降は、私なりに「何が起こったか」、「どう解決したか」をご説明します。
事象発生時、私の環境は以下の状況でした。
pvdisplay # --- Physical volume --- # PV Name /dev/nvme0n1p3 # VG Name fedora_pc # PV Size <929.93 GiB / not usable 4.00 MiB # Allocatable yes # PE Size 4.00 MiB # Total PE 238060 # Free PE 127724 # Allocated PE 110336 # PV UUID 8YLtdy-5itA-1PwJ-8BYJ-vjcI-Nf6C-iihOsr pvs --segments -v # PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 0 97536 home 0 linear /dev/nvme0n1p3:0-97535 # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 97536 127488 0 free # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 225024 12800 root 0 linear /dev/nvme0n1p3:225024-237823 # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 237824 236 0 free
前半のpvdisplayの出力で、PE (Physical Extent) 1つあたり4.00 MiBのサイズであることがわかります。
後半のpvsの出力からは、PEのアドレスのフラグメント (データの断片化) っぷりがわかります。
pvsから読み取れる情報を下表にまとめました。
| # | 開始アドレス | 終了アドレス | セグメントサイズ | LV |
|---|---|---|---|---|
| 1 | 0 |
97535 |
97536 |
home |
| 2 | 97536 |
225023 |
127488 |
free (未使用) |
| 3 | 225024 |
237823 |
12800 |
root |
| 4 | 237824 |
238060 |
236 |
free (未使用) |
表の各列の法則性は以下のようになっています。
開始アドレスはStart列から読み取れる終了アドレスは次の行の開始アドレスから1を引いた値になるセグメントサイズはSSize列から読み取れる開始アドレス + セグメントサイズ - 1 = 終了アドレスPE Rangesの表記はデバイス名:開始アドレス-終了アドレスとなっている
上表から読み取れるように、homeとrootのPE番号は連続していません。
LV (Logical Volume) の作成・拡張時には基本的には連続するようにPEがアサインされます。
このことはType列がlinearであることと、man lvextendの--typeの説明、そして/etc/lvm/lvm.confのuse_linear_target = 1という設定値などから読み取れます。
ではなぜhomeとrootの間にfreeが入り込んでいるかというと、過去に私がlvextendによるLV拡張やlvreduceによるLV縮小を何度か実施した結果として "隙間" が生まれたことが原因です。
この隙間が (間接的に) 悪さをして、今回のエラーに繋がっています。
以下がエラーになったときのコマンドです。
pvresize -v --yes --setphysicalvolumesize 967757824K '/dev/nvme0n1p3'
サイズ変更後のPVは967757824Kとあります。
967757824 / 1024 / 1024 = 922.92578125です。
GPartedを操作する前のPVサイズは、pvdisplayより929.93 GiB (以下) と読み取れます。
pvresizeコマンドにより、約7 GiBを縮小しようとしていることがわかります。
この"7 GiB"という値は、"私がGPartedによってLVMパーティションの前半アドレスから削ろうとしたサイズ"と一致します。
つまり、GPartedによって前半7 GiBを削るためには、先にPVの後半アドレスを7 GiB削る必要があります。
その後に"ファイルシステムを後ろのアドレスに移動"することで"前半7 GiBを削った"ことになります。
(※) ここで間違えないでいただきたいのは、末尾に7 GiBの空きを作ることが要件です。冒頭に7 GiBの空きを作ってもGPartedの移動処理は失敗します。 (実機検証済)
上の表を改めてみてみましょう。
一番最後のfreeとなっている領域のサイズはわずか236 PEsです。
1 PEあたり4 MiBなので、236 PEs = 944 MiBと、1 GiBにも満たないサイズです。
7 GiB縮小しようとしても当然失敗します。
当時のPVサイズの内訳は以下のようになっています。
| 用途 | 容量 |
|---|---|
/home |
381 GiB |
/ |
50 GiB |
| 空き領域 | 498.9 GiB |
うまいことPEのアドレスをスライドしてあげれば、末尾の7 GiBは簡単に工面できます。
ここで使うのがpvmoveコマンドになります。
pvmove --alloc anywhere 移動元 移動先というコマンドにより、PEの場所を移動することができます。
移動先はfreeと書いてある部分のみが指定可能です。
移動元や移動先の表現の仕方はいくつかあります。 詳細はman pvmoveの"VARIABLES -> PV"や"EXAMPLES"のあたりに書いてあります。 具体例を示すと以下の通りです。
/dev/nvme1p3:225024-237823→ アドレス225024から237823の範囲移動元の指定に便利な表現方法- 移動元の
PE Rangesからコピペするのが実践的
/dev/nvme0n1p3:97536+12800→ アドレス97536から110335の範囲 (97536を開始点に、12800の幅を持つ範囲。110336 = 97536 + 12800 - 1)移動先の指定に便利な表現方法- 開始点の
97536はfree行のStart列の値をコピペする - 幅を表現する
+12800は、移動元のSSize列からコピペする
図に表すと以下のとおりです。
(※) 元ブログのほうが見やすい...ですが、移動元の表現方法が若干異なります
以上を踏まえてpvmoveを実行した結果がこちらになります。
rootが移動してフラグメントがなくなったことがわかると思います。
pvs --segments -v # PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 0 97536 home 0 linear /dev/nvme0n1p3:0-97535 # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 97536 127488 0 free # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 225024 12800 root 0 linear /dev/nvme0n1p3:225024-237823 # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 237824 236 0 free pvmove --alloc anywhere /dev/nvme0n1p3:225024-237823 /dev/nvme0n1p3:97536+12800 # /dev/nvme0n1p3: Moved: 0.10% # (snip) # /dev/nvme0n1p3: Moved: 100.00% pvs --segments -v # PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 0 97536 home 0 linear /dev/nvme0n1p3:0-97535 # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 97536 12800 root 0 linear /dev/nvme0n1p3:97536-110335 # /dev/nvme0n1p3 fedora_pc lvm2 a-- 929.92g 498.92g 110336 127724 0 free
...ちなみに、このあとhomeとrootの順番を入れ替えました。
実際の用途ではhomeを容量いっぱいに使い切りたいのでhomeをlvextend -r ...により拡張することになります。
ここで拡張すると、home > root > homeというデータの並びになってしまいます。
LVMの柔軟性によりこの並びでも全く問題なく動作しますが、なんとなくもやもやしたので私の環境では並べ替えちゃいました。
まとめ
Fedoraバージョンアップに伴う/bootサイズの推奨値変更に伴い、Clonezilla, GParted, そしてLVMのデフラグという盛りだくさんの学びを得られました。
Changes/2GbootPartitionによると、2016年に/bootサイズの推奨値が500 MBから1 GBに増加、そして今回は2025年に1 GBから2 GBに増加、という経緯を辿ってきたそうです。
5年後は3 GBや4 GBになっているかもしれません。
そう考えると、今回大変な手間がかかりましたが/bootを大きめサイズに拡張できて安心を買えたかなと思います。
この記事が似たような悩みを抱えるLinuxユーザの皆様の安心材料に繋がれば幸いです。
