ボリュームがルート (起動可能) デバイスとして使用されている場合、他の解決策はどれも機能しません。

Question 1

ボリュームがルート (起動可能) デバイスとして使用されている場合、他の解決策はどれも機能しません。

新しく作成されたディスクにはブートパーティションがないため、インスタンスがそれをルートボリュームとして使用するには、GRUB をインストールし、いくつかのフラグを正しく設定する必要があります。

私の（今日現在、働く) ルートボリュームを縮小するためのソリューションは次のとおりです。

背景：インスタンスAのルートボリュームを縮小したいとします。このボリュームをVAと呼びましょう。VAを30GBから10GBに縮小したいとします。

インスタンス A と同じ OS を持つ新しい ec2 インスタンス B を作成します。また、カーネルは一致している必要があるため、必要に応じてアップグレードまたはダウングレードします。ストレージとして、VA と同じタイプで、サイズが 10 GB のボリュームを選択します。(または、ターゲットサイズ)。これで、この新しいボリューム (VB と呼びます) をルートボリュームとして使用するインスタンス B ができました。
新しいインスタンス (B) が実行されたら、それを停止し、ルートボリューム (VB) をデタッチします。

注: 以下の手順は主に @bill のソリューションから抜粋したものです。

サイズを変更するインスタンスを停止します (A)。
ボリューム VA のスナップショットを作成し、そのスナップショットから「汎用 SSD」ボリュームを作成します。このボリュームを VASNAP と呼びます。
Amazon Linux で新しいインスタンスを作成します。このインスタンスをインスタンス C と呼びます。このインスタンスを使用して、VASNAP の内容を VB にコピーします。これらの手順を実行するためにインスタンス A を使用することもできますが、独立したマシンで実行することをお勧めします。
次のボリュームをインスタンス C に接続します。VB の場合は /dev/xvdf、VASNAP の場合は /dev/xvdg。
インスタンス C を再起動します。
SSH 経由でインスタンス C にログオンします。
次の新しいディレクトリを作成します。

mkdir /source /target

VB のメインパーティションを ext4 ファイルシステムでフォーマットします。

mkfs.ext4 /dev/xvdf1

エラーが発生しない場合は、手順 11 に進みます。エラーが発生していない場合は、/dev/xvdf1次の i-vii を実行してパーティションを作成する必要があります。

i)/dev/xvdf1何らかの理由で存在しない場合は、作成する必要があります。まず、以下を入力します。

sudo fdisk /dev/xvdf。

ii) 次のように入力してディスクを消去します。 wipefs

iii) 次のように入力して新しいパーティションを作成します。 n

iv)pプライマリパーティションを作成するために入力する

v) Enter キーを押し続けると、デフォルト設定で続行されます。

vi) 再度コマンドを求められた場合は、Enter キーを押してw変更を書き込んで終了します。

vii)/dev/xvdf1次を実行してパーティションがあることを確認します。 lsblk

次のような画面が表示されます。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  250G  0 disk
└─xvda1 202:1    0  250G  0 part
xvdf    202:80   0   80G  0 disk
└─xvdf1 202:81   0   80G  0 part 
xvdg    202:96   0  250G  0 disk
└─xvdg1 202:97   0  250G  0 part

次にステップ 11 に進みます。

このディレクトリにマウントします:

mount -t ext4 /dev/xvdf1 /target

これは非常に重要です。Linux がファイルシステムを認識して起動するには、e2label が必要です。アクティブなインスタンスで「e2label /dev/xvda1」を使用して、ラベルが何であるかを確認します。この場合、ラベルは「/」です。

e2label /dev/xvdf1 /

/source に VASNAP をマウントします:

mount -t ext4 /dev/xvdg1 /source

内容をコピーします:

rsync -vaxSHAX /source/ /target

注意: 「/target」の後に「/」はありません。また、シンボリックリンクと属性に関するエラーがいくつかあるかもしれませんが、サイズ変更は成功しています。

VB のマウント解除:

umount /target

AWS コンソールに戻り、インスタンス C から VB をデタッチし、インスタンス A から VA もデタッチします。
新しいサイズのボリューム (VB) をインスタンスに次のように接続します: "/dev/xvda"
インスタンス A を起動します。ルートデバイスは 10 GB になりました :)
インスタンス B と C の両方と、インスタンス A のルートボリュームとなった VB 以外のすべてのボリュームを削除します。

Answer

ボリュームがルート (起動可能) デバイスとして使用されている場合、他の解決策はどれも機能しません。

新しく作成されたディスクにはブートパーティションがないため、インスタンスがそれをルートボリュームとして使用するには、GRUB をインストールし、いくつかのフラグを正しく設定する必要があります。

私の（今日現在、働く) ルートボリュームを縮小するためのソリューションは次のとおりです。

背景：インスタンスAのルートボリュームを縮小したいとします。このボリュームをVAと呼びましょう。VAを30GBから10GBに縮小したいとします。

インスタンス A と同じ OS を持つ新しい ec2 インスタンス B を作成します。また、カーネルは一致している必要があるため、必要に応じてアップグレードまたはダウングレードします。ストレージとして、VA と同じタイプで、サイズが 10 GB のボリュームを選択します。(または、ターゲットサイズ)。これで、この新しいボリューム (VB と呼びます) をルートボリュームとして使用するインスタンス B ができました。
新しいインスタンス (B) が実行されたら、それを停止し、ルートボリューム (VB) をデタッチします。

注: 以下の手順は主に @bill のソリューションから抜粋したものです。

サイズを変更するインスタンスを停止します (A)。
ボリューム VA のスナップショットを作成し、そのスナップショットから「汎用 SSD」ボリュームを作成します。このボリュームを VASNAP と呼びます。
Amazon Linux で新しいインスタンスを作成します。このインスタンスをインスタンス C と呼びます。このインスタンスを使用して、VASNAP の内容を VB にコピーします。これらの手順を実行するためにインスタンス A を使用することもできますが、独立したマシンで実行することをお勧めします。
次のボリュームをインスタンス C に接続します。VB の場合は /dev/xvdf、VASNAP の場合は /dev/xvdg。
インスタンス C を再起動します。
SSH 経由でインスタンス C にログオンします。
次の新しいディレクトリを作成します。

mkdir /source /target

VB のメインパーティションを ext4 ファイルシステムでフォーマットします。

mkfs.ext4 /dev/xvdf1

エラーが発生しない場合は、手順 11 に進みます。エラーが発生していない場合は、/dev/xvdf1次の i-vii を実行してパーティションを作成する必要があります。

i)/dev/xvdf1何らかの理由で存在しない場合は、作成する必要があります。まず、以下を入力します。

sudo fdisk /dev/xvdf。

ii) 次のように入力してディスクを消去します。 wipefs

iii) 次のように入力して新しいパーティションを作成します。 n

iv)pプライマリパーティションを作成するために入力する

v) Enter キーを押し続けると、デフォルト設定で続行されます。

vi) 再度コマンドを求められた場合は、Enter キーを押してw変更を書き込んで終了します。

vii)/dev/xvdf1次を実行してパーティションがあることを確認します。 lsblk

次のような画面が表示されます。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  250G  0 disk
└─xvda1 202:1    0  250G  0 part
xvdf    202:80   0   80G  0 disk
└─xvdf1 202:81   0   80G  0 part 
xvdg    202:96   0  250G  0 disk
└─xvdg1 202:97   0  250G  0 part

次にステップ 11 に進みます。

このディレクトリにマウントします:

mount -t ext4 /dev/xvdf1 /target

これは非常に重要です。Linux がファイルシステムを認識して起動するには、e2label が必要です。アクティブなインスタンスで「e2label /dev/xvda1」を使用して、ラベルが何であるかを確認します。この場合、ラベルは「/」です。

e2label /dev/xvdf1 /

/source に VASNAP をマウントします:

mount -t ext4 /dev/xvdg1 /source

内容をコピーします:

rsync -vaxSHAX /source/ /target

注意: 「/target」の後に「/」はありません。また、シンボリックリンクと属性に関するエラーがいくつかあるかもしれませんが、サイズ変更は成功しています。

VB のマウント解除:

umount /target

AWS コンソールに戻り、インスタンス C から VB をデタッチし、インスタンス A から VA もデタッチします。
新しいサイズのボリューム (VB) をインスタンスに次のように接続します: "/dev/xvda"
インスタンス A を起動します。ルートデバイスは 10 GB になりました :)
インスタンス B と C の両方と、インスタンス A のルートボリュームとなった VB 以外のすべてのボリュームを削除します。

Question 2

AWS コンソールの場合:

サイズを変更したいインスタンスを停止します
アクティブボリュームのスナップショットを作成し、そのスナップショットから「汎用 SSD」ボリュームを作成します。
必要なサイズに合わせて別の「汎用 SSD」ボリュームを作成します。
これらの 3 つのボリュームを次のようにインスタンスに接続します。
- アクティブボリュームの /dev/sda1。
- ターゲットサイズのボリュームの /dev/xvdf。
- アクティブボリュームのスナップショットから作成されたボリュームの /dev/xvdg。
インスタンスを起動します。
SSH 経由で新しいインスタンスにログオンします。
次の新しいディレクトリを作成します。

mkdir /source /target

新しいボリュームに ext4 ファイルシステムを作成します。

mkfs.ext4 /dev/xvdf

このディレクトリにマウントします:

mount -t ext4 /dev/xvdf /target

これは非常に重要です。Linux がファイルシステムを認識して起動するには、e2label が必要です。アクティブなインスタンスで「e2label /dev/xvda1」を使用して、ラベルが何であるかを確認します。この場合、ラベルは「/」です。

e2label /dev/xvdf /

スナップショットから作成されたボリュームをマウントします。

mount -t ext4 /dev/xvdg /source

内容をコピーします:

rsync -ax /source/ /target

^{注意: 「/target」の後に「/」はありません。また、シンボリックリンクと属性に関するエラーがいくつかあるかもしれませんが、サイズ変更は成功しています。}

ファイルシステムをアンマウントします。

umount /target
umount /source

AWS コンソールに戻り、インスタンスを停止し、すべてのボリュームをデタッチします。
新しいサイズのボリュームをインスタンスに「/dev/sda1」として接続します。
インスタンスを起動すると、起動するはずです。

ステップ10は重要です: 上記のように、新しいボリュームに「e2label」というラベルを付けます。そうしないと、インスタンスは AWS で起動しているように見えますが、接続チェックに合格しません。

Answer

AWS コンソールの場合:

サイズを変更したいインスタンスを停止します
アクティブボリュームのスナップショットを作成し、そのスナップショットから「汎用 SSD」ボリュームを作成します。
必要なサイズに合わせて別の「汎用 SSD」ボリュームを作成します。
これらの 3 つのボリュームを次のようにインスタンスに接続します。
- アクティブボリュームの /dev/sda1。
- ターゲットサイズのボリュームの /dev/xvdf。
- アクティブボリュームのスナップショットから作成されたボリュームの /dev/xvdg。
インスタンスを起動します。
SSH 経由で新しいインスタンスにログオンします。
次の新しいディレクトリを作成します。

mkdir /source /target

新しいボリュームに ext4 ファイルシステムを作成します。

mkfs.ext4 /dev/xvdf

このディレクトリにマウントします:

mount -t ext4 /dev/xvdf /target

これは非常に重要です。Linux がファイルシステムを認識して起動するには、e2label が必要です。アクティブなインスタンスで「e2label /dev/xvda1」を使用して、ラベルが何であるかを確認します。この場合、ラベルは「/」です。

e2label /dev/xvdf /

スナップショットから作成されたボリュームをマウントします。

mount -t ext4 /dev/xvdg /source

内容をコピーします:

rsync -ax /source/ /target

^{注意: 「/target」の後に「/」はありません。また、シンボリックリンクと属性に関するエラーがいくつかあるかもしれませんが、サイズ変更は成功しています。}

ファイルシステムをアンマウントします。

umount /target
umount /source

AWS コンソールに戻り、インスタンスを停止し、すべてのボリュームをデタッチします。
新しいサイズのボリュームをインスタンスに「/dev/sda1」として接続します。
インスタンスを起動すると、起動するはずです。

ステップ10は重要です: 上記のように、新しいボリュームに「e2label」というラベルを付けます。そうしないと、インスタンスは AWS で起動しているように見えますが、接続チェックに合格しません。

Question 3

1. 新しい ebs ボリュームを作成し、インスタンスにアタッチします。

新しい EBS ボリュームを作成します。たとえば、元々 20G あったものを 8G に縮小したい場合は、同じアベイラビリティーゾーンに新しい 8G EBS ボリュームを作成します。ルートパーティションを縮小する必要があるインスタンスにそれをアタッチします。

2. 新しく作成した ebs ボリューム上のファイルをパーティション分割し、フォーマットし、同期します。

（1.パーティション状況を確認する

まず、次のコマンドを使用してsudo parted -l、元のボリュームのパーティション情報を確認します。

[root@ip-172-31-16-92 conf.d]# sudo parted -l
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 20G
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2097kB  1049kB               bbp   bios_grub
 2      2097kB  20480MB  24G  xfs          root

この 20G のルートデバイスボリュームは、bbp と root という 2 つのパーティションに分割されていることがわかります。bbp パーティションにはファイルシステムはありませんが、bios_grub というフラグがあり、このシステムが grub によって起動されていることを示しています。また、ルートボリュームが gpt を使用してパーティション分割されていることを示しています。bios_grub とは何かというと、実際には BIOS ブートパーティションです。参照は次のとおりです。

https://en.wikipedia.org/wiki/BIOS_ブートパーティション https://www.cnblogs.com/f-ck-need-u/p/7084627.html

これは約 1MB で、注目すべきはルートと呼ばれるパーティションです。このパーティションには、元のシステムのすべてのファイルが保存されます。したがって、バックアップの考え方は、このパーティションから新しい ebs ボリューム上の別の小さなパーティションにファイルを転送することです。

(2partedを使用して、新しい ebs ボリュームをパーティション分割し、フォーマットします。

lsblkブロックをリストするために使用します:

NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0   20G  0 disk 
├─nvme0n1p1 259:1    0   1M  0 part 
└─nvme0n1p2 259:2    0   20G  0 part /
nvme1n1     270:0    0   8G  0 disk

新しい ebs ボリュームはデバイス nvme1n1 であり、これをパーティション分割する必要があります。

~# parted /dev/nvme1n1
GNU Parted 3.2 
Using /dev/xvdg 
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt  #Using the gpt layout would take up the first 1024 sectors 
(parted) mkpart bbp 1MB 2MB # Since the first 1024 sectors are used, the start address here is 1024kb or 1MB, and bbp is the partition name, that is, BIOS boot partition, which needs to take up 1MB, so the end address is 2MB
(parted) set 1 bios_grub on #Set partition 1 as BIOS boot partition

(parted) mkpart root xfs 2MB 100% #allocate the remaining space (2MB to 100%) to the root partition.

分割後、lsblk再度使用すると、

NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0   20G  0 disk 
├─nvme0n1p1 259:1    0   1M  0 part 
└─nvme0n1p2 259:2    0   20G  0 part /
nvme1n1     270:0    0   8G  0 disk 
├─nvme1n1p1 270:1    0   1M  0 part 
└─nvme1n1p2 270:2    0   8G  0 part /

さらに 2 つのパーティション (nvme1n1p1 と nvme1n1p2) があることがわかります。nvme1n1p2 は新しいルートパーティションです。次のコマンドを使用してパーティションをフォーマットします。

mkfs.xfs /dev/nvme1n1p2

フォーマット後、パーティションをマウントする必要があります。たとえば、/mnt/myroot にマウントします。

mkdir -p /mnt/myroot
mount /dev/nvme1n1p2 /mnt/myroot

（3）rsyncを使用して、すべてのコンテンツを新しいボリュームの対応するルートパーティションに転送します。

sudo rsync -axv / /mnt/myroot/

上記の-xパラメータは、現在のインスタンスのルートディレクトリをバックアップするため、非常に重要です。このパラメータを追加しないと、/mnt/myroot 自体が /mnt/myroot にバックアップされ、無限ループに陥ります。(–exclude パラメータも OK) rsync コマンドは cp コマンドとは異なります。cp コマンドは上書きしますが、rsync は同期増分バックアップです。これにより、多くの時間を節約できます。コーヒーを飲みながら、同期が完了するまでお待ちください。

3. 対応するファイル内の uuid を置き換えます。

ボリュームが変更されたため、ボリュームの uuid も変更されました。ブートファイル内の uuid を置き換える必要があります。次の 2 つのファイルを変更する必要があります。

/boot/grub2/grub.cfg #or /boot/grub/grub.cfg
/etc/fstab

では、何を変更する必要があるのでしょうか? まず、blkid を使用して関連するボリュームの uuid をリストする必要があります。

[root@ip-172-31-16-92 boot]# sudo blkid
/dev/nvme0n1p2: LABEL="/" UUID="add39d87-732e-4e76-9ad7-40a00dbb04e5" TYPE="xfs" PARTLABEL="Linux" PARTUUID="47de1259-f7c2-470b-b49b-5e054f378a95"
/dev/nvme1n1p2: UUID="566a022f-4cda-4a8a-8319-29344c538da9" TYPE="xfs" PARTLABEL="root" PARTUUID="581a7135-b164-4e9a-8ac4-a8a17db65bef"
/dev/nvme0n1: PTUUID="33e98a7e-ccdf-4af7-8a35-da18e704cdd4" PTTYPE="gpt"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot Partition" PARTUUID="430fb5f4-e6d9-4c53-b89f-117c8989b982"
/dev/nvme1n1: PTUUID="0dc70bf8-b8a8-405c-93e1-71c3b8a887c7" PTTYPE="gpt"
/dev/nvme1n1p1: PARTLABEL="bbp" PARTUUID="82075e65-ae7c-4a90-90a1-ea1a82a52f93"

add39d87-732e-4e76-9ad7-40a00dbb04e5古い大きな EBS ボリュームのルートパーティションの uuid はで、新しい小さな EBS ボリュームの uuid はであることがわかります566a022f-4cda-4a8a-8319-29344c538da9。sed コマンドを使用してこれを置き換えます。

sed 's/add39d87-732e-4e76-9ad7-40a00dbb04e5/566a022f-4cda-4a8a-8319-29344c538da9/g' /boot/grub2/grub.cfg
sed 's/add39d87-732e-4e76-9ad7-40a00dbb04e5/566a022f-4cda-4a8a-8319-29344c538da9/g' /etc/fstab

grub-installもちろん、便宜上、ここで(一部のシステムでは)を使用して grub ファイルを手動で生成することもできますgrub2-install。

4. 2 つのボリュームをデタッチし、新しい小さなボリュームを再度アタッチします。

次に、umount新しい ebs ボリュームをアンマウントします。

umount /mnt/myroot/

ターゲットがビジー状態であるというプロンプトが表示された場合、を使用して、fuser -mv /mnt/myrootその中でどのプロセスが動作しているかを確認できます。私が見つけたのは bash です。つまり、bash でこのディレクトリを終了する必要があります。を使用してcdホームディレクトリに戻り、上記のコマンドを再度入力してアンマウントします。

次に、2 つのボリュームを両方ともデタッチし (もちろん、最初にインスタンスを停止します)、デバイス名を入力して新しいボリュームをルートデバイスとして再アタッチします。以下に/dev/xvda示すように

次にインスタンスを起動します。SSH が失敗した場合は、次の方法を使用してデバッグできます。

1. システムログを取得する

2.スクリーンショットを取得する

参照：

1.https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#InitialSteps

2.https://www.daniloaz.com/en/partitioning-and-resizing-the-ebs-root-volume-of-an-aws-ec2-instance/

3.https://medium.com/@m.yunan.helmy/decrease-the-size-of-ebs-volume-in-your-ec2-instance-ea326e951bce

Answer

1. 新しい ebs ボリュームを作成し、インスタンスにアタッチします。

新しい EBS ボリュームを作成します。たとえば、元々 20G あったものを 8G に縮小したい場合は、同じアベイラビリティーゾーンに新しい 8G EBS ボリュームを作成します。ルートパーティションを縮小する必要があるインスタンスにそれをアタッチします。

2. 新しく作成した ebs ボリューム上のファイルをパーティション分割し、フォーマットし、同期します。

（1.パーティション状況を確認する

まず、次のコマンドを使用してsudo parted -l、元のボリュームのパーティション情報を確認します。

[root@ip-172-31-16-92 conf.d]# sudo parted -l
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 20G
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2097kB  1049kB               bbp   bios_grub
 2      2097kB  20480MB  24G  xfs          root

この 20G のルートデバイスボリュームは、bbp と root という 2 つのパーティションに分割されていることがわかります。bbp パーティションにはファイルシステムはありませんが、bios_grub というフラグがあり、このシステムが grub によって起動されていることを示しています。また、ルートボリュームが gpt を使用してパーティション分割されていることを示しています。bios_grub とは何かというと、実際には BIOS ブートパーティションです。参照は次のとおりです。

https://en.wikipedia.org/wiki/BIOS_ブートパーティション https://www.cnblogs.com/f-ck-need-u/p/7084627.html

これは約 1MB で、注目すべきはルートと呼ばれるパーティションです。このパーティションには、元のシステムのすべてのファイルが保存されます。したがって、バックアップの考え方は、このパーティションから新しい ebs ボリューム上の別の小さなパーティションにファイルを転送することです。

(2partedを使用して、新しい ebs ボリュームをパーティション分割し、フォーマットします。

lsblkブロックをリストするために使用します:

NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0   20G  0 disk 
├─nvme0n1p1 259:1    0   1M  0 part 
└─nvme0n1p2 259:2    0   20G  0 part /
nvme1n1     270:0    0   8G  0 disk

新しい ebs ボリュームはデバイス nvme1n1 であり、これをパーティション分割する必要があります。

~# parted /dev/nvme1n1
GNU Parted 3.2 
Using /dev/xvdg 
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt  #Using the gpt layout would take up the first 1024 sectors 
(parted) mkpart bbp 1MB 2MB # Since the first 1024 sectors are used, the start address here is 1024kb or 1MB, and bbp is the partition name, that is, BIOS boot partition, which needs to take up 1MB, so the end address is 2MB
(parted) set 1 bios_grub on #Set partition 1 as BIOS boot partition

(parted) mkpart root xfs 2MB 100% #allocate the remaining space (2MB to 100%) to the root partition.

分割後、lsblk再度使用すると、

NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0   20G  0 disk 
├─nvme0n1p1 259:1    0   1M  0 part 
└─nvme0n1p2 259:2    0   20G  0 part /
nvme1n1     270:0    0   8G  0 disk 
├─nvme1n1p1 270:1    0   1M  0 part 
└─nvme1n1p2 270:2    0   8G  0 part /

さらに 2 つのパーティション (nvme1n1p1 と nvme1n1p2) があることがわかります。nvme1n1p2 は新しいルートパーティションです。次のコマンドを使用してパーティションをフォーマットします。

mkfs.xfs /dev/nvme1n1p2

フォーマット後、パーティションをマウントする必要があります。たとえば、/mnt/myroot にマウントします。

mkdir -p /mnt/myroot
mount /dev/nvme1n1p2 /mnt/myroot

（3）rsyncを使用して、すべてのコンテンツを新しいボリュームの対応するルートパーティションに転送します。

sudo rsync -axv / /mnt/myroot/

上記の-xパラメータは、現在のインスタンスのルートディレクトリをバックアップするため、非常に重要です。このパラメータを追加しないと、/mnt/myroot 自体が /mnt/myroot にバックアップされ、無限ループに陥ります。(–exclude パラメータも OK) rsync コマンドは cp コマンドとは異なります。cp コマンドは上書きしますが、rsync は同期増分バックアップです。これにより、多くの時間を節約できます。コーヒーを飲みながら、同期が完了するまでお待ちください。

3. 対応するファイル内の uuid を置き換えます。

ボリュームが変更されたため、ボリュームの uuid も変更されました。ブートファイル内の uuid を置き換える必要があります。次の 2 つのファイルを変更する必要があります。

/boot/grub2/grub.cfg #or /boot/grub/grub.cfg
/etc/fstab

では、何を変更する必要があるのでしょうか? まず、blkid を使用して関連するボリュームの uuid をリストする必要があります。

[root@ip-172-31-16-92 boot]# sudo blkid
/dev/nvme0n1p2: LABEL="/" UUID="add39d87-732e-4e76-9ad7-40a00dbb04e5" TYPE="xfs" PARTLABEL="Linux" PARTUUID="47de1259-f7c2-470b-b49b-5e054f378a95"
/dev/nvme1n1p2: UUID="566a022f-4cda-4a8a-8319-29344c538da9" TYPE="xfs" PARTLABEL="root" PARTUUID="581a7135-b164-4e9a-8ac4-a8a17db65bef"
/dev/nvme0n1: PTUUID="33e98a7e-ccdf-4af7-8a35-da18e704cdd4" PTTYPE="gpt"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot Partition" PARTUUID="430fb5f4-e6d9-4c53-b89f-117c8989b982"
/dev/nvme1n1: PTUUID="0dc70bf8-b8a8-405c-93e1-71c3b8a887c7" PTTYPE="gpt"
/dev/nvme1n1p1: PARTLABEL="bbp" PARTUUID="82075e65-ae7c-4a90-90a1-ea1a82a52f93"

add39d87-732e-4e76-9ad7-40a00dbb04e5古い大きな EBS ボリュームのルートパーティションの uuid はで、新しい小さな EBS ボリュームの uuid はであることがわかります566a022f-4cda-4a8a-8319-29344c538da9。sed コマンドを使用してこれを置き換えます。

sed 's/add39d87-732e-4e76-9ad7-40a00dbb04e5/566a022f-4cda-4a8a-8319-29344c538da9/g' /boot/grub2/grub.cfg
sed 's/add39d87-732e-4e76-9ad7-40a00dbb04e5/566a022f-4cda-4a8a-8319-29344c538da9/g' /etc/fstab

grub-installもちろん、便宜上、ここで(一部のシステムでは)を使用して grub ファイルを手動で生成することもできますgrub2-install。

4. 2 つのボリュームをデタッチし、新しい小さなボリュームを再度アタッチします。

次に、umount新しい ebs ボリュームをアンマウントします。

umount /mnt/myroot/

ターゲットがビジー状態であるというプロンプトが表示された場合、を使用して、fuser -mv /mnt/myrootその中でどのプロセスが動作しているかを確認できます。私が見つけたのは bash です。つまり、bash でこのディレクトリを終了する必要があります。を使用してcdホームディレクトリに戻り、上記のコマンドを再度入力してアンマウントします。

次に、2 つのボリュームを両方ともデタッチし (もちろん、最初にインスタンスを停止します)、デバイス名を入力して新しいボリュームをルートデバイスとして再アタッチします。以下に/dev/xvda示すように

次にインスタンスを起動します。SSH が失敗した場合は、次の方法を使用してデバッグできます。

1. システムログを取得する

2.スクリーンショットを取得する

参照：

1.https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#InitialSteps

2.https://www.daniloaz.com/en/partitioning-and-resizing-the-ebs-root-volume-of-an-aws-ec2-instance/

3.https://medium.com/@m.yunan.helmy/decrease-the-size-of-ebs-volume-in-your-ec2-instance-ea326e951bce

Question 4

以下の記事は、EBS ボリュームのサイズを縮小する方法に関するわかりやすくわかりやすいチュートリアルです。わかりやすいステップバイステップのガイドとスクリーンショットが掲載されています。

EC2インスタンスのEBSボリュームのサイズを縮小する

Answer

以下の記事は、EBS ボリュームのサイズを縮小する方法に関するわかりやすくわかりやすいチュートリアルです。わかりやすいステップバイステップのガイドとスクリーンショットが掲載されています。

EC2インスタンスのEBSボリュームのサイズを縮小する

ボリュームがルート (起動可能) デバイスとして使用されている場合、他の解決策はどれも機能しません。

答え1

ボリュームがルート (起動可能) デバイスとして使用されている場合、他の解決策はどれも機能しません。

答え2

答え3

1. 新しい ebs ボリュームを作成し、インスタンスにアタッチします。

2. 新しく作成した ebs ボリューム上のファイルをパーティション分割し、フォーマットし、同期します。

3. 対応するファイル内の uuid を置き換えます。

4. 2 つのボリュームをデタッチし、新しい小さなボリュームを再度アタッチします。

答え4

関連情報