☰

ライブシステムなしでSSH経由でLVMのルートパーティションを別のPVに移動する方法

tag-icon • tag-icon lvm boot rootfs
ライブシステムなしでSSH経由でLVMのルートパーティションを別のPVに移動する方法

Debian 10 を起動するためのルート パーティションを変更するにはどうすればよいですか?

LVM 論理ボリューム上にあるルート ファイル システムのサイズを、SSH 経由のみで、Live CD を起動せずにリモートから縮小したいと考えています。

マウントされている間は rootfs を縮小できないため、既存の rootfs を複製し、そこから起動してサイズ変更を行い、元の rootfs から起動して一時ファイルを削除することにしました。

Ubuntu Server 18.04のVMで試してみました。私の知る限り、Debain 10と同じ「ブートチェーン」を使用しています。しかし、クローンしたパーティションをルートとして確実に設定することはできませんでした。再起動後、確認したところmount、元のルートがまだ使用されています。

  • /etc/fstab更新されました
  • /boot/grub/grub.cfg更新されました
  • initramfs更新されました

現在の構成

  • 1TB RAID1md0
  • 4TB RAID1md1
  • PVオンmd0
  • PVオンmd1p1
  • vg0両方のPVを持つVG
  • root元のルートファイルシステムとしてのLV (UUID xxx)
  • newroot一時的なルートファイルシステムとしてのLV (UUID yyy)
  • ext4 オンvg0-root(UUID aaa)
  • ext4 オンvg0-newroot(UUID bbb)

/etc/fstabそれに応じて変更されました（デバイス マッパー パスが置き換えられました）。

これまで、古いルート全体をaaanewroot にrsync しbbb、すべての UUIDaaaとをxxxとに置き換えました (注:または UEFI ブートは使用していません)。bbbyyy/boot/grub/grub.cfggrub2

initramfsupdate-initramfs -u（ を修正した後）を使用して更新されました/etc/initramfs-tools/conf.d/resume。

その順序です。しかし、VM でのテストでは、古いルートに直接起動するか、GRUB レスキュー シェルに切り替わりました。

update-grubボリュームを認識しnewroot、一致するエントリを追加しましたgrub.cfg。テスト VM での起動時に手動で選択しました (SSH 経由では不可能です...)。また、古いルートも起動しました。

ルート パーティションをハードコードするROOTオプションがあることもわかりました。/etc/initramfs-tools/initramfs.conf

ルート ブート引数を渡すことができない場合に、オプションのルート ブート引数のハードコーディングを許可します。ルート ブート引数はその特別な設定を上書きします。

しかし、私の場合は root 用の bootarg があるため、grub.cfgこの設定は有効にならないはずです。

次回の起動時に別の UUID をルートとして使用するために、他に何を設定する必要がありますか?

答え1

/boot/grub/grub.cfg...の root= bootarg を置き換えるのを忘れていたことが判明しました。

完全を期すために：

ライブシステムなしでSSH経由でLVMのルートパーティションを別のPVに移動する方法

注意: 重要なデータは必ずバックアップしてください。この方法はハックであり、実稼働システムでは使用しないでください。いずれにしても、LV クローンから新しいルート パーティションからの起動までの間に書き込まれたデータは必ず失われます。

他のディスクに新しいLVMを作成する

fdisk /dev/sdb #Create new partition for PV (sdb1)
pvcreate /dev/sdb1
vgcreate vg1 /dev/sdb1
lvcreate -n newroot -L10G vg1 #Size has to be larger than effective usage on current root
mkfs.ext4 -L newroot /dev/mapper/vg1-newroot

新しいLVMに関する情報を収集する

lvdisplay
vgdisplay
pvdisplay
blkid

次のコマンドは、ここで提示される情報を次のように参照します。

  • $pv0uuid = 古いPVのUUID
  • $pv1uuid = 新しいPVのUUID
  • $vg{0,1}uuid = {old,new} VGのUUID
  • $lv{0,1}UUID = {古い、新しい} LVのUUID
  • $root{0,1}UUID = {古い、新しい} ルート ファイルシステムの UUID
  • $vg{0,1} = {古い、新しい}VGの名前
  • $lv{0,1} = {古い、新しい} LV の名前

と/etc/grub/grub.cfg表示されます$grubcfg。UEFI システムの場合、これはおそらく です/boot/grub2/grub.cfg。

以下のコマンドをコピーして貼り付けることができるように、bashこれらを変数として設定することをお勧めします。pv0uuid=xxxxxx-xxxx...

GRUB設定で新しいルートを設定する

次のコマンドは、GRUB 構成内のテキストを置き換えます。

sed -i "s/$pv0uuid/$pv1uuid/g" $grubcfg
sed -i "s/$vg0uuid/$vg1uuid/g" $grubcfg
sed -i "s/$lv0uuid/$lv1uuid/g" $grubcfg
sed -i "s/$root0uuid/$root1uuid/g" $grubcfg
sed -i "s/$vg0/$vg1/g" $grubcfg #BEWARE COMMON NAMES
sed -i "s/$lv0/$lv1/g" $grubcfg #BEWARE COMMON NAMES
sed -i "s/\/dev\/mapper\/$vg0-$lv0/\/dev\/mapper\/$vg1-$lv1/g" /etc/fstab #BEWARE COMMON NAMES

一般的な名前には注意:sed置き換えます毎root一致するテキストが見つからない場合、 GRUB または fstab 構成の他の場所で使用されているような単語を置き換えると無効になるため、これらの変更を手動で行うことをお勧めします。

nanoVG 名と LV 名を検索 ( )し、手動で置き換えることをお勧めしますCTRL+W。念のため、PV デバイス名を検索することもお勧めします...

ルートボリュームのクローンを作成する

mount /dev/mapper/$vg1-$lv1 /mnt
rsync -rAa --one-file-system / /mnt/
umount /mnt

リブート

再起動します（そして祈ります）。新しい LV がマウントされていることを確認します/。

古いLVMを削除する

lvremove /dev/$vg0/*
vgremove $vg0
pvremove /dev/sda2 #Path to $pv0uuid

掃除

オプションですが推奨されます

  • 最後に古いVGを削除してください/etc/lvm/archive。そうしないと、起動時に毎回検索され、遅延が発生します。
  • update-grub
  • update-initramfs -u

ノート

Ubuntu 18.04 でテストされていますが、他のディストリビューションでは GRUB 構成の処理方法が異なる場合があります (UUID とデバイス パス、更新コマンドに関して)。

当然のことながら、データの損失を最小限に抑えるために、事前に不要なサービスをすべて停止してください。

$lv0systemd ターゲット、カスタム スクリプト、LVM スナップショットを使用して、(ほとんどの) データ損失を回避する方法があるかもしれません。再起動の直前に、データをからに再度同期する必要があります$lv1。この投稿の範囲外です...

/boot別のパーティションでない場合は、$grubcfg再起動する前に新しいルートを再確認してください。

答え2

これが役に立つかどうかはわかりませんが、LV 上のルート パーティションを縮小するために私が試した方法は次のとおりです。

  1. ルート パーティションのスナップショットを作成します。変更する予定なので、必ず領域を割り当ててください。
  2. スナップショットを fsck します。
  3. 安全のために、スナップショットのサイズを変更 (縮小) し、ファイルシステムの先頭と LV のターゲット サイズの境界の間にバッファーがあることを確認します。
  4. スナップショットを rootfs LV にマージします。
  5. 再起動します。マージは実際にはこの時点で実行されます (おそらく起動中)。
  6. 再起動後、rootfs ボリュームを縮小し、必要に応じて rootfs のサイズを再度変更して、LV の上部のスペースを埋めます。

欠点が 1 つあります。ライブ ファイル システムのスナップショットを作成するため、手順 1 と 5 の間で一部のデータが失われ、手順 1 で不整合が発生する可能性があります (使用している FS によって異なります)。

私にとっては驚くほどうまくいきました。

理想的には、ステップ 1 は起動中、rootfs rw の再マウント前に実行されるため、スナップショットはクリーンです。dracut からそれを実行する方法がわかりません。使用しようとしたツールはそこでは機能しませんでした。

関連情報