Das Problem
Die Datenplatte eines Fileservers läuft auf 100%. LVM, ext4, Proxmox VM — die übliche Homelab-Kombi. Plan: Disk in Proxmox um 50 GiB vergrößern, dann Partition, PV, LV und Filesystem nachziehen. Kein Downtime, ext4 unterstützt Online-Resize.
Der erste Schritt klappt reibungslos: Proxmox vergrößert die virtuelle Disk. lsblk zeigt danach 700G statt 650G. Dann kommt der erste Rückschlag:
# growpart nicht installiert
which growpart
# growpart: NICHT INSTALLIERT
# apt-get schlägt fehl weil /mnt/share bei 100% ist
# (apt braucht Platz auf /tmp und /, beides hat noch Platz — aber man nervt sich)
Kein Problem, parted ist immer vorinstalliert. Einfach im Script-Modus:
parted -s /dev/sdb resizepart 1 100%
Ausgabe:
Warning: Not all of the space available to /dev/sdb appears to be used,
you can fix the GPT to use all of the space (an extra 104857600 blocks)
or continue with the current setting?
Error: Unable to satisfy all constraints on the partition.
Kein Rollback, keine Partition vergrößert. lsblk zeigt sdb1 immer noch bei 650G.
Die Ursache: GPT Secondary Header
GPT (GUID Partition Table) speichert seinen Header zweimal: einmal am Anfang der Disk (Primary Header) und einmal am Ende der Disk (Secondary/Backup Header). Das ist das Redundanz-Feature von GPT.
Das Problem: Nach dem Vergrößern der virtuellen Disk in Proxmox liegt der Secondary Header noch am alten Disk-Ende — also bei 650 GiB, obwohl die Disk jetzt 700 GiB hat.
Alt:
[Primary Header][Partition 1: 650G][Secondary Header]<-- alte Disk-Ende
|<-- 50G neu -->|
Neu:
[Primary Header][Partition 1: 650G][Secondary Header] [50G ungenutzt]
parted -s bemerkt das und gibt die Warning aus (“Not all of the space available…”). Im interaktiven Modus würde man mit “Fix” antworten. Im Script-Modus (-s) ignoriert parted das Problem stillschweigend und versucht dann, die Partition ohne den nötigen Platz am Disk-Ende zu erweitern — was scheitert.
Warum schweigt parted so laut? Die Fehlermeldung “Unable to satisfy all constraints on the partition” klingt nach einem Partitionierungs-Konflikt. Dass der echte Grund ein verrutschter GPT-Backup-Header ist, erschließt sich nicht ohne Hintergrundwissen. Schöner wäre: “Fix GPT secondary header first.”
Die Diagnose
# Bestätigen: Disk ist tatsächlich größer
lsblk /dev/sdb
# sdb 700G
# Partition aber noch alt
# sdb1 650G
# GPT-Status prüfen
parted /dev/sdb print
# Warning: Not all of the space available to /dev/sdb appears to be used...
# -> Bestätigt: Secondary Header am falschen Ende
Die Lösung
Schritt 0: Kernel-Rescan (nach Proxmox-Resize)
echo 1 > /sys/class/block/sdb/device/rescan
# Prüfen
lsblk /dev/sdb
# sdb muss jetzt die neue Größe zeigen (z.B. 700G)
Falls sdb noch die alte Größe zeigt, alternativ:
echo "- - -" > /sys/class/scsi_host/host0/scan
Schritt 1: GPT Backup Header verschieben (der nicht-offensichtliche Schritt)
# gdisk installieren (braucht freien Platz auf /, nicht auf der vollen Datenplatte!)
apt-get install -y gdisk
# Secondary Header ans neue Disk-Ende verschieben
sgdisk -e /dev/sdb
Erwartete Ausgabe:
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Die Kernel-Warnung ist harmlos — LVM liest die Partition-Grenzen direkt, ein Reboot ist nicht nötig.
Schritt 2: Partition erweitern
parted -s /dev/sdb resizepart 1 100%
# Prüfen
lsblk /dev/sdb
# sdb1 muss jetzt 700G zeigen
Jetzt klappt es ohne Fehlermeldung.
Schritt 3: LVM nachziehen
# Physical Volume erweitern
pvresize /dev/sdb1
# Prüfen: PFree muss ~50G zeigen
pvs
# /dev/sdb1 vgdata <700,00g 50,00g
Schritt 4: Logical Volume + Filesystem in einem Schritt
# -r: ruft resize2fs automatisch auf (Online-Resize für ext4!)
# -l +100%FREE: alle freien PEs nutzen
lvextend -r -l +100%FREE /dev/vgdata/lvshare
# Erwartete Ausgabe (Auszug):
# Size of logical volume vgdata/lvshare changed from <650,00 GiB to <700,00 GiB.
# resize2fs ... is mounted on /mnt/share; on-line resizing required
# The filesystem on /dev/mapper/vgdata-lvshare is now XXXXXXXX (4k) blocks long.
Kein Unmount nötig. ext4 unterstützt Online-Resize vollständig.
Schritt 5: Verifikation
df -h /mnt/share
# /dev/mapper/vgdata-lvshare 679G 597G 82G 88% /mnt/share
# ^^^
# ~50 GiB mehr als vorher
# Schreibtest
touch /mnt/share/.resize-test && rm /mnt/share/.resize-test && echo "OK"
Warum nicht growpart?
growpart (aus dem Paket cloud-guest-utils) macht genau das: GPT-Header verschieben + Partition erweitern in einem Befehl. Es wäre einfacher gewesen — aber es war nicht installiert, und apt-get install auf einem Server mit voller Datenplatte fühlt sich riskant an (auch wenn / noch Platz hatte).
sgdisk -e + parted -s resizepart ist der manuelle Weg, der auf jedem Debian-System ohne zusätzliche Pakete funktioniert — außer dass man gdisk für sgdisk braucht.
Priorität:
growpart /dev/sdb 1— wenncloud-guest-utilsinstalliert istsgdisk -e /dev/sdb && parted -s /dev/sdb resizepart 1 100%— der manuelle Weg
Lessons Learned
parted -s im Script-Modus ist tückisch. Im interaktiven Modus fragt parted “Fix/Ignore?” und mit “Fix” läuft alles durch. Im Script-Modus (-s) ist die Antwort implizit “Ignore” — aber die Fehlermeldung verrät das nicht. Wer das nicht weiß, sucht an der falschen Stelle.
sgdisk -e ist der unbekannte Held. Es verschiebt nur den Backup-Header — keine Partitionen, keine Daten werden angefasst. Schnell, sicher, genau das Richtige.
Der komplette Ablauf für Proxmox VMs mit GPT + LVM + ext4:
# 1. Kernel-Rescan nach Proxmox-Resize
echo 1 > /sys/class/block/sdb/device/rescan
# 2. GPT Secondary Header verschieben
sgdisk -e /dev/sdb
# 3. Partition erweitern
parted -s /dev/sdb resizepart 1 100%
# 4. PV erweitern
pvresize /dev/sdb1
# 5. LV + Filesystem (Online, kein Unmount!)
lvextend -r -l +100%FREE /dev/vgdata/<LV-NAME>
# 6. Prüfen
df -h /mnt/<MOUNTPOINT>
Gesamtdauer: ~5 Minuten. Kein Reboot, kein Service-Restart, kein Datenverlust.