So verschieben Sie die Root-Partition per SSH ohne Live-System auf ein anderes PV in LVM

Question

Wie kann ich die Root-Partition ändern, von der Debian 10 booten soll?

Ich möchte die Größe meines Root-Dateisystems, das sich auf einem logischen LVM-Volume befindet, remote verringern, und zwar nur über SSH und ohne von einer Live-CD zu booten.

Da wir das Root-Dateisystem nicht verkleinern können, während es gemountet ist, habe ich mir gedacht, dass ich einfach das vorhandene Root-Dateisystem klone, damit boote und die Größenanpassung von dort aus vornehme, dann mit dem ursprünglichen Root-Dateisystem boote und das temporäre lösche.

Ich habe es in einer VM mit Ubuntu Server 18.04 versucht, da es meines Wissens nach dieselbe „Boot-Kette“ wie Debain 10 verwendet. Allerdings konnte ich die geklonte Partition nicht zuverlässig als Root festlegen. Nach einem Neustart habe ich es mit überprüft mountund das ursprüngliche Root wird immer noch verwendet, obwohl

• /etc/fstabwurde aktualisiert
• /boot/grub/grub.cfgwurde aktualisiert
• initramfswurde aktualisiert

Aktuelle Konfiguration

• 1 TB RAID1md0
• 4 TB RAID1md1
• PV einmd0
• PV einmd1p1
• VG vg0mit beiden PVs
• LV rootals ursprüngliches Root-Dateisystem (UUID xxx)
• LV newrootals temporäres Root-Flash-Laufwerk (UUID yyy)
• ext4 ein vg0-root(UUID aaa)
• ext4 ein vg0-newroot(UUID bbb)

/etc/fstabwurde entsprechend geändert (Device-Mapper-Pfad ersetzt).

Bisher habe ich das komplette alte Root-Verzeichnis per rsync aaamit dem neuen Root-Verzeichnis synchronisiert bbbund sämtliche Vorkommen von UUIDs aaaund xxxdurch bbbund yyyin ersetzt /boot/grub/grub.cfg(Hinweis: Ich verwende keinen grub2UEFI-Boot).

initramfswurde mit aktualisiert update-initramfs -u(nach dem Beheben von /etc/initramfs-tools/conf.d/resume).

In dieser Reihenfolge. Aber meine Tests in einer VM haben entweder direkt zum alten Stamm gebootet oder mich in eine GRUB-Rettungsshell geworfen.

update-grubhat das newrootVolume erkannt und passende Einträge hinzugefügt grub.cfg, diese beim Booten in meiner Test-VM manuell ausgewählt (über SSH nicht möglich ...) und auch das alte Root gebootet.

Ich habe auch gesehen, dass es eine ROOTOption zum /etc/initramfs-tools/initramfs.confFestcodieren der Root-Partition gibt:

Ermöglicht optionales Hardcoding des Root-Bootarguments, wenn kein Root-Bootarg übergeben werden kann. Ein Root-Bootarg überschreibt diese spezielle Einstellung.

Da in meinem aber ein Bootarg für Root vorhanden ist, grub.cfgsollte diese Einstellung keinen Effekt haben.

Was muss sonst noch konfiguriert werden, um beim nächsten Booten eine andere UUID als Root zu verwenden?

Answer 1

/boot/grub/grub.cfgEs stellte sich heraus, dass ich vergessen hatte, das Bootarg „root=“ in … zu ersetzen .

Der Vollständigkeit halber:

So verschieben Sie die Root-Partition per SSH ohne Live-System auf ein anderes PV in LVM

Hinweis: Sichern Sie wichtige Daten immer! Diese Methode ist ein Hack und sollte nicht auf Produktionssystemen verwendet werden. In jedem Fall gehen Daten, die in der Zeit zwischen dem LV-Klon und dem Booten von der neuen Root-Partition geschrieben wurden, immer verloren.

Neues LVM auf anderer Festplatte erstellen

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

Sammeln Sie Informationen über neue LVM

lvdisplay
vgdisplay
pvdisplay
blkid

Die folgenden Befehle beziehen sich auf die hier dargestellten Informationen wie folgt:

• $pv0uuid = UUID des alten PV
• $pv1uuid = UUID des neuen PV
• $vg{0,1}uuid = UUID der {alten,neuen} VG
• $lv{0,1}UUID = UUID des {alten,neuen} LV
• $root{0,1}UUID = UUID des {alten,neuen} Root-Dateisystems
• $vg{0,1} = Name der {alten,neuen} VG
• $lv{0,1} = Name des {alten,neuen} LV

Und /etc/grub/grub.cfgwird als angezeigt $grubcfg. Bei UEFI-Systemen ist dies höchstwahrscheinlich /boot/grub2/grub.cfg.

Ich empfehle, diese als Variablen festzulegen, bashdamit pv0uuid=xxxxxx-xxxx...die folgenden Befehle kopiert und eingefügt werden können.

Neues Root-Recht in der GRUB-Konfiguration festlegen

Diese Befehle ersetzen Text in der GRUB-Konfiguration:

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

Vorsicht vor gebräuchlichen Namen: sedwird ersetzenjedenVorkommen von übereinstimmendem Text. Es wird daher empfohlen, diese Änderungen manuell vorzunehmen, da das Ersetzen von Wörtern, wie sie rootan anderer Stelle in der GRUB- oder fstab-Konfiguration verwendet werden, diese ungültig macht!

Ich empfehle, die VG- und LV-Namen zu verwenden nanound danach zu suchen ( CTRL+W) und sie dann manuell zu ersetzen. Es wird auch empfohlen, für alle Fälle nach dem PV-Gerätenamen zu suchen ...

Klonen Sie das Stammvolume

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

Neustart

Neustart (und beten). Überprüfen Sie, ob das neue LV gemountet wird /.

Altes LVM löschen

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

Aufräumen

Optional, aber empfohlen

• Löschen Sie abschließend das alte VG, /etc/lvm/archiveda es sonst bei jedem Bootvorgang gesucht wird und dadurch Verzögerungen entstehen.
• update-grub
• update-initramfs -u

Anmerkungen

Getestet auf Ubuntu 18.04. Andere Distributionen handhaben die GRUB-Konfiguration möglicherweise anders (in Bezug auf UUIDs vs. Gerätepfade und Aktualisierungsbefehle).

Um den Datenverlust zu minimieren, sollten Sie natürlich vorher alle nicht benötigten Dienste beenden.

Es könnte eine Möglichkeit geben, (die meisten) Datenverluste durch die Verwendung von Systemd-Zielen, benutzerdefinierten Skripten und LVM-Snapshots zu vermeiden. Man müsste die Daten im letztmöglichen Moment vor dem Neustart erneut synchronisieren $lv0. $lv1Dies würde den Rahmen dieses Beitrags sprengen ...

Wenn /bootes sich nicht um eine separate Partition handelt, überprüfen Sie $grubcfgdas neue Stammverzeichnis noch einmal, bevor Sie erneut einen Neustart durchführen.

Answer 2

Ich bin nicht sicher, ob Ihnen das hilft, aber ich habe erfolgreich versucht, die Root-Partition auf LV zu verkleinern:

1. Erstellen Sie einen Snapshot der Root-Partition. Stellen Sie sicher, dass genügend Speicherplatz zugewiesen ist, da Sie ihn ändern werden.
2. Führen Sie einen Fsck-Vorgang für den Schnappschuss durch.
3. Passen Sie die Größe des Snapshots an (verkleinern Sie ihn) und stellen Sie sicher, dass zwischen der Oberseite des Dateisystems und der Grenze der Zielgröße des LV ein Puffer vorhanden ist – nur um auf Nummer sicher zu gehen.
4. Führen Sie den Snapshot wieder mit Ihrem Rootfs-LV zusammen.
5. Neustart. Die Zusammenführung wird tatsächlich an diesem Punkt durchgeführt (wahrscheinlich während des Bootens).
6. Nach einem Neustart verkleinern Sie das RootFS-Volume und passen die Größe des RootFS ggf. erneut an, sodass der gesamte Speicherplatz bis zum oberen Rand des LV ausgefüllt wird.

Es gibt jedoch einen Nachteil: Sie VERLIEREN zwischen den Schritten 1 und 5 einige Daten und es KÖNNEN in Schritt 1 (abhängig vom verwendeten FS) einige Inkonsistenzen auftreten, da Sie einen Snapshot auf einem Live-Dateisystem erstellen.

Bei mir hat es überraschend gut funktioniert.

Im Idealfall würde Schritt 1 während des Bootvorgangs ausgeführt, bevor rootfs rw erneut gemountet wird, damit der Snapshot sauber ist. Ich habe nicht herausgefunden, wie das von Dracut aus geht – die Tools, die ich zu verwenden versucht habe, haben bei mir nicht funktioniert.