[gelöst] /boot vergrössern lvm cryptfs

[Lichtstoff2021]

Hallo liebe Leute,

ich habe einen Computer mit einer Debian Installation:

/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 1550335 499712 244M Linux filesystem
/dev/nvme0n1p3 1550336 4000796671 3999246336 1,9T Linux filesystem

/dev/nvme0n1p3 ist der LUKS gecrypted Kontainer mit einem LVM für stamm, var, swap_1, tmp und home. Damit ist alles in Ordnung.
/dev/nvme0n1p2 ist /boot und die Partition ist zu klein. Das Ziel ist, diese Partition zu vergrößern.

Ganz ähnlich, wie [gelöst] Kernel /boot ist "zu klein", jedoch betreibe ich die "Lösung" jedesmal, wenn ein neuer Kernel installiert werden muss und beim letzten Mal musste ich den Kernel des laufenden Systems deinstallieren. Das ist gut gegangen, aber ein deutliches Zeichen, endlich aktiv zu werden. Ich konnte keine Dokumentation finden, wie es zu bewerkstelligen wäre, den verschlüsselten Kontainer zu verkleinern, zu verschieben und die eine Partition zu vergrößern. Wohl aber habe ich gefunden, dass es besser wäre neu zu installieren.

LVM nutze ich nur, weil es toll ist, einen verschlüsselten Kontainer und darin das System mit verschiedenen Mountpoints zu haben. Das ist wirkich eine elegante Lösung, vielen Dank dafür.

Ist es wirklich so, dass man ganz elegant eine Installation mit einem verschlüsselten Kontainer und darin ein LVM anlegen kann, danach aber nicht wie früher mit einer schönen Boot-CD und parted Partitionen verkleinern und verschieben kann?

[mcb]

Du könntest die EFI verkleinern - die sollte fast leer sein und dann boot vergrößern - habe ich selbst noch nicht gemacht. Also Vorsicht.

[Lichtstoff2021]

Das ist keine Antwort auf meine Frage und wie du selbst sagst, riskant. Dennoch danke für deine Antwort!

[smutbert]

Ist es wirklich so, dass man ganz elegant eine Installation mit einem verschlüsselten Kontainer und darin ein LVM anlegen kann, danach aber nicht wie früher mit einer schönen Boot-CD und parted Partitionen verkleinern und verschieben kann?

Ja, nur mit /boot muss man aufpassen, weil grub ja den Kernel und das initramfs von dort laden muss. grub kann zwar grundsätzlich mit Verschlüsselung umgehen, aber zumindest frühere Versionen nicht mit jedem luks-Format und ob die Kombination mit lvm unterstützt wird, weiß ich nicht. Es ist also meistens einfacher /boot auf eine nicht verschlüsselte Partition zu legen (ich denke das macht der Debianinstaller bei einer Installation mit Verschlüsselung+lvm).
Bei einem UEFI-System könnte man mit etwas Handarbeit den Kernel samt initramfs auch auf die EFI System Partition legen, die ja sowieso außerhalb der Verschlüsselung liegen muss.


Mit lvm ist gparted ist nicht mehr das richtige Werkzeug, aber du kannst bei lvm die Logical Volumes, beliebig vergrößern und verkleinern – verschieben ist nicht notwendig, weil es es sozusagen keine Reihenfolge gibt. Wenn es das Dateisystem unterstützt lässt sich das alles auch im laufenden Betrieb machen.
Grundsätzlich funktioniert das auch von einem von CD aus gestarteten System, es muss halt die lvm2-Tools (lvm2) installiert haben und mit der Verschlüsselung umgehen können.

[Lichtstoff2021]

Ist es wirklich so, dass man ganz elegant eine Installation mit einem verschlüsselten Kontainer und darin ein LVM anlegen kann, danach aber nicht wie früher mit einer schönen Boot-CD und parted Partitionen verkleinern und verschieben kann?

...
Mit lvm ist gparted ist nicht mehr das richtige Werkzeug, aber du kannst bei lvm die Logical Volumes, beliebig vergrößern und verkleinern – verschieben ist nicht notwendig, weil es es sozusagen keine Reihenfolge gibt. Wenn es das Dateisystem unterstützt lässt sich das alles auch im laufenden Betrieb machen.
Grundsätzlich funktioniert das auch von einem von CD aus gestarteten System, es muss halt die lvm2-Tools (lvm2) installiert haben und mit der Verschlüsselung umgehen können.

Gut, dass parted damit nicht umgehen kann hatte ich auch verstanden und nicht versucht.
Dass ich LVs und GVs verkleinern kann habe ich auch gelesen.
Wie ich dann aber dem GV sage, schiebe dich mal nach ganz hinten auf die Platte, bzw. wenn du Platz machst, dann ganz vorne, das ist mir nirgendwo aufgefallen...

[smutbert]

Bei lvm hast du zuerst einmal ein oder mehrere Blockgeräte, das können eine ganze Festplatten, SSDs, Partitionen, verschlüsselte Geräte,... sein.
Die fügst du also Physical Volume (PV) zu einer Volume Group (VG) hinzu und in der Volume Group kannst du schließlich beliebig Logical Volumes (LV) anlegen, vergrößern, verkleinern, löschen, Snapshots anlegen, u. s. w..
Innerhalb der logischen Einheiten (VG, LV, LE – letzteres sind die Logical Extents, die logischen Speichereinheiten innerhalb einer VG) hat ein Begriff wie verschieben, so wie du es meinst, keinen Sinn.

PVs lassen verkleinern oder vergrößern. Will man ein PV vergrößern muss man zuerst das zugrundeliegende Blockgerät, also zB die Partition vergrößern und kann hinterher in lvm die PV auf die neue Größe vergrößern.
Verkleinern geht in der umgekehrten Richtung, also zuerst das PV in lvm verkleinern und hinterher die Partition, aber das geht nur wenn keine PEs (Physical Extents, das sind die Speichereinheiten auf den PVs) in dem Speicherbereich belegt sind, den man sozusagen abschneiden will.


Du meinst vor allem das Verschieben von PVs. Das ist nichts worum sich LVM selbst kümmert – es müsste aber funktionieren ein Image von dem PV (also zB der Partition) anzulegen, die Festplatte neu zu partitionieren und dann das Image auf die Partition zurückzuspielen. Das geht aber keinesfalls im laufenden Betrieb und ist natürlich lästig, weil man viel Speicherplatz braucht. Das würde ich eher vermeiden.

Was ginge, wäre die Festplatte in mehrere Partitionen aufzuteilen und dann diese Partitionen einer PVs einer VG zuzuweisen oder sie wieder zu entfernen. Das ist aber allgemein eher nur eine Notlösung und wäre in deiner Situation auch aufwändig, weil jede Partition sozusagen für sich verschlüsselt werden müsste.

mcbs Vorschlag ist da meiner Meinung nach am praktikabelsten. Und weil ich gparted nicht besonders mag, würde ich das ungefähr so machen

1. sicherstellen, dass ein Backup vorhanden ist
2. ein Linux von CD, DVD oder USB starten
3. ein Image von /dev/nvme0n1p2 (/boot) anlegen
4. mit fatresize das Dateisystem der EFI System Partition (/dev/nvme0n1p1) auf z.B. etwa 150 MB verkleinern (sicherheitshalber auf jeden Fall etwas kleiner kleiner als die EFI System Partition am Ende sein soll)
5. mit gdisk eine neue Partitionstabelle schreiben, wobei /dev/nvme0n1p3 gleich sein muss wie davor. Größenordnumgsmäßig also etwa so

   Code: Alles auswählen

   Device           Start        End   Sectors   Size Type
   /dev/nvme0n1p1    2048     526335     524288  250M EFI System
   /dev/nvme0n1p2  526336    1550335   10241000  506M Linux filesystem
   /dev/nvme0n1p3 1550336 4000796671 3999246336  1,9T Linux filesystem
   

6. das Dateisystem der EFI System Partition auf die volle Partitionsgröße vergrößern, wieder mit fatresize
7. das Image /dev/nvme0n1p2 (/boot) zurückspielen
8. das Dateisystem von /dev/nvme0n1p2 (/boot) auf die neue Partitionsgröße vergrößern (resize2fs)

[Lichtstoff2021]

Hallo smutbert,
vielen Dank, dass du dir soviel Mühe gemacht hast. Vermutlich ist die Anleitung für jemand anders genau die Lösung, die gesucht wurde.

Ich hatte aber gehofft, dass es eine moderne Boot-CD dafür geben könnte, die den Job machen kann. Dass die Aufgabe komplexer ist, als früher, als man mit parted Partitionsoperationen gemacht hatte, davon war ich ausgegangen, ohne LVM im Detail zu kennen - deshalb hätte ich ja auch gerne ein Werkzeug dafür gefunden. Meine Suche ohne Fund wollte ich aber nicht abschliessen, ohne danach zu fragen.

Meine Frage danach konnte niemand beantworten, ich gehe also davon aus, dass es dieses Werkzeug nicht gibt.

Ich werde mein Problem also so lösen, wie ich es kann.

Ich habe ein offline-Datei-basiertes Backup von System und Daten. Ich führe eine Neuinstallation durch, wobei /boot mehr Platz bekommt und spiele danach mein Backup ein, wobei /boot und Moduldateien, sowie /etc/lvm und /etc/grub nicht überschrieben werden dürfen.

Es sei allen gedankt, die sich mit meiner Frage beschäftigt haben!

[mcb]

Das was ursprünglich gewünscht war geht bestimmt auch, ich kann es dir aber nicht gut erklären ... Ich habe mich damals nicht getraut (es droht Datenverlust).

Wenn du sowieso alles gesichert hast und neu Installieren willst könntest du es probieren. Ich halte die EFI verkleinern und den Platz /boot zuzuordnen für wesentlich leichter und weniger risekobehaftet. Auch sehr einfach zu reparieren im Fall der Fälle. Ist ja schließlich nur fat.

Code: Alles auswählen

marc@mb:~$ df /boot/efi/ -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  477M  7.7M  469M   2% /boot/efi

[Lichtstoff2021]

Nach dem Anlegen eines frischen Systembackups habe ich es ausprobiert.
Gparted beschwert sich, wenn ich 256 MB freien Platz auf der FAT32 Partition schaffen möchte, weil es dann FAT16 einrichten müsse.
Ich habe die Größe auf 378 MB belassen, das ging dann ohne Beschwerde und habe danach die /boot Partition um den frei gewordenen Bereich erweitert. Ich habe einen Hinweis bekommen, dass das System nicht mehr booten könnte. Ich habe es aber einfach ausprobiert und das System hatte keine Problem damit.
Ich schaue mir an, wie das läuft.
So sieht das jetzt aus:

$ df -h /boot
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/nvme0n1p2 367M 101M 247M 29% /boot