☰

LUKS-LVMパーティションのサイズ変更の問題

tag-icon • tag-icon filesystems lvm luks forensics
LUKS-LVMパーティションのサイズ変更の問題

LUKS lvmパーティションのサイズを変更（縮小）しようとする心配な冒険に遭遇しました。システムをより小さいサイズの新しいドライブに簡単にコピーできるように、パーティションを縮小したいと思います。始める前に空き容量を確保するために、既存のディスクからいくつかのファイルを削除しました。その後、USB Live Ubuntuから起動し、KDEパーティションマネージャを使用して最初にLUKSパーティションのロックを解除しました。その後、LVMルートパーティションを使用可能にし、KDEパーティションマネージャのサイズ変更オプションを使用して縮小しました。残念ながら、これはここで説明したのと同じ問題を引き起こします。 「パーティションのサイズ変更後、スーパーブロックまたはパーティションテーブルが破損している可能性があります！」

私の問題は、答えの1つを誤解することから始まります。だから私がしたことは、次のコマンドを実行することでした。

e2fsck -f /dev/the_unlocked_lvm_root

次のオプションから選択します。

e2fsck 1.45.5 (07-Jan-2020)
The filesystem size (according to the superblock) is 239771648 blocks
The physical size of the device is 125080576 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
Pass 1: Checking inodes, blocks, and sizes
Error reading block 126877728 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes

時々私は私がしなければならないことをしていないことに気づくまで「はい」を押します。これで、コンピュータを再起動したり、他の操作を実行していません。私の質問は、基本的に私がどれだけのダメージを与えたか、問題が回復可能であるか、またはすべてのデータが失われたかです。 e2fsckコマンドを停止すると、「ファイルシステムが修正されました」というメッセージが表示されるため、非常に心配です。

どんなフィードバックでも大変感謝します！

ベストアンサー1

ちょうど同様の問題があったが、解決することができた。 KDE Partition Managerを使用する代わりに、lvresize次のコマンドを使用して論理ボリュームのサイズを変更しました。

このコマンドを実行しないでください:lvresize --verbose -L -40G /dev/mapper/vgubuntu-root

私の質問は、基本的に私がどれだけのダメージを与えたか、問題が回復可能であるか、またはすべてのデータが失われたかです。

どうしたの？

次の説明は私の仮説そして、いくつかのエラーがあるかもしれませんので、誤解を解消するために自由に修正/コメントをお願いします。

  1. まず、論理ボリュームは、パーティションテーブルやファイルシステムではなく、ハードドライブに似たボリュームです。

  2. ファイルシステムは論理ボリュームの内部にあるので、私が理解している限り、論理ボリュームにはパーティションテーブルはありません。 （パーティションではなくディスク全体にファイルシステムを作成することは可能ですが、一般的ではありません。)

  3. ファイルシステムを縮小せずにボリュームを縮小することは、ハードドライブのセクタを切り捨てるのと同じです。パーティションテーブルがないため、KDEパーティションマネージャはボリュームが空であると見なし、ユーザーが自由に編集できるようにします。

  4. ボリュームは縮小しましたが、ファイルシステムにはまだボリューム範囲外のブロックがあるため、読み取ることができず、e2fsckボリュームblock 126877728範囲外にあります。

  5. e2fsck望んでいますが、rewriteブロックにまったくアクセスできないため、できません。

  6. ボリュームサイズとファイルシステムに関する情報は、パーティションの先頭を覆っている物理ハードドライブに保存されるため、データはほとんど失われません。、少なくともHDDでは（おそらくSSDで）。今回もe2fsckブロックを書き換えることができず、ビットとバイトは実際のハードドライブのどこかにほとんどそのまま残ります。

  7. したがって、ファイルシステムに触れることなく、単に論理ボリュームサイズを増やして縮小をキャンセルすると、問題が解決します。

長い話を短く

ボリュームを元のサイズに復元すると、データを失うことなく問題を解決できます。

lvresize --verbose -L +SIZE /dev/mapper/vgubuntu-root
    # SIZE you shrunk the volume
    # `lvresize` <volume> => resize a logical volume
    #   --verbose  => Give more info.
    #   --resizefs => Resize filesystem AND LV with fsadm(8).
    #   -L         => Specifies the new size of the LV, 
    #                 +/- add/subtracts to/from current size, e.g. g|G is GiB.

e2fsck -f /dev/mapper/vgubuntu-root
    # `e2fsck` <fs-path> => Check a Linux ext2/ext3/ext4 file system
    #   -f => Force checking even if the file system seems clean.

    # Output should look like this:
    #   Pass 1: Checking inodes, blocks, and sizes
    #   Pass 2: Checking directory structure
    #   Pass 3: Checking directory connectivity
    #   Pass 4: Checking reference counts
    #   Pass 5: Checking group summary information

元のサイズがわからない場合以降のボリュームサイズ（親パーティションの境界内）を増やすことができます。その後、エラーレポートには少ないブロック数を含める必要がe2fsckあります。

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Block bitmap differences:  +121110528 +(121110532--121110533) +(121110537--121111049) +(121112586--121113097)

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Block bitmap differences:  +(121110537--121111049) +(121112586--121113097)

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Pass 5: Checking group summary information

論理ボリュームとファイルシステムを縮小する方法

lvresizeオプションを含む--resisefs（ファイルシステムのサイズが変更されます。- キャプテンオビアス）：

# Shrink logical root volume AND filesystem
lvresize --verbose --resizefs -L -SIZE /dev/mapper/vgubuntu-root

おすすめ記事