Partitionen vergrößern (GParted)
Manchmal muss man die Partitionierung eines konfigurierten Systems ändern, beispielsweise weil sich einzelne Partitionen als zu klein herausgestellt haben. Dieser Artikel beschreibt beispielhaft ein Verfahren, bei welchem der Umbau ohne Neuinstallation und vor allem ohne Datenverlust durchgeführt werden kann.
Hierzu wird die Live-Version von GParted verwendet. Das Beispiel wurde in einer virtualisierten Umgebung unter VirtualBox durchgeführt.
| Achtung: |
|
Warnung: Es ist absolut notwendig, von allen relevanten Daten zuvor eine valide Sicherheitskopie anzufertigen. Die hier behandelten Schritte bergen ein hohes Risiko für die Konsistenz des gesamten Datenbestandes! |
Inhaltsverzeichnis
Ausgangsbasis
Das folgende Partitionierungsschema zeigt die aktuelle Konfiguration:
localhost:~ # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 8G 0 disk ├─sda1 8:1 0 101M 0 part /boot ├─sda2 8:2 0 6.6G 0 part │ ├─system-root 253:0 0 6.1G 0 lvm / │ └─system-swap 253:1 0 512M 0 lvm [SWAP] └─sda3 8:3 0 1.3G 0 part /images-pp sdb 8:16 0 8G 0 disk └─sdb1 8:17 0 8G 0 part /root/sdb1
Hinweis: Hier handelt es sich um eine Konfiguration für einen ganz bestimmten Zweck, diese soll keinesfalls als beispielhaft für eine sinnvolle Partitionierung im produktiven Einsatz gelten!
Ziel
Was soll gemacht werden?
- sda1 soll auf 4GB erweitert werden.
- sda2 soll auf 15GB erweitert werden.
- sda3 wird gelöscht.
- sdb dient nur temporär der Aufnahme der Images und ist nicht Gegenstand einer Partitionsbearbeitung.
Sicherung
Zuvor wurden von 'sda1' und 'sda2' per dd Images in 'sdb1' erstellt. Dies geschah in einer separaten Sitzung, gebootet in einem Recovery-System - also nicht am laufenden System!
Test, ob die Images valide sind:
localhost:~ # mkdir /root/sdb1 localhost:~ # mount -o ro /dev/sdb1 /root/sdb1 localhost:~ # mkdir /root/sda1; mount -o loop /root/sdb1/sda1-boot.img /root/sda1 localhost:~ # mkdir /root/sda2; mount -o loop /root/sdb1/sda2-root-lvm.img /root/sda2 mount: unknown filesystem type 'LVM2_member'
Das sollte in diesem Kontext ausreichen...
Vergrößerung
Schritt 1: sda vergrößern
Das wird mit VirtualBox-Werkzeugen auf dem Host erreicht, während die VM down ist.
j2:~ # ls -ltar /home/user/VirtualBox\ VMs/OpenSUSE\ 13.1\ NoCrypt/OpenSUSE\ 13.1\ NoCrypt.vdi -rw------- 1 user 1000 7703924736 Dec 22 15:45 /home/user/VirtualBox VMs/OpenSUSE 13.1 NoCrypt/OpenSUSE 13.1 NoCrypt.vdi j2:~ # VBoxManage modifyhd "/home/user/VirtualBox VMs/OpenSUSE 13.1 NoCrypt/OpenSUSE 13.1 NoCrypt.vdi" --resize 19456 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% j2:~ # ls -ltar /home/user/VirtualBox\ VMs/OpenSUSE\ 13.1\ NoCrypt/OpenSUSE\ 13.1\ NoCrypt.vdi -rw------- 1 user 1000 7704973312 Dec 24 09:58 /home/user/VirtualBox VMs/OpenSUSE 13.1 NoCrypt/OpenSUSE 13.1 NoCrypt.vdi
Die geringe Größenänderung hier scheint plausibel durch die Sparse-Konfiguration erklärbar zu sein. VirtualBox meldet jedenfalls die neue Größe von 19 GB.
In der realen Welt entspricht dieser Schritt dem Einbau einer größeren Festplatte und dem Übertragen des Diskimages per dd von der alten auf die neue Platte.
Danach startet die VM problemlos, nutzt aber den zusätzlichen Speicher nicht:
localhost:~ # fdisk -l /dev/sda Disk /dev/sda: 8589 MB, 8589934592 bytes, 16777216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000d8d71 Device Boot Start End Blocks Id System /dev/sda1 * 2048 208895 103424 83 Linux /dev/sda2 208896 14057471 6924288 8e Linux LVM /dev/sda3 14057472 16756735 1349632 83 Linux
Das System hat von dem neuen Speicherplatz noch nichts mitbekommen. Das Verhalten zeigt sich ebenfalls, wenn die VM von einer Live-Version von GParted gebootet wird:
Hier wird ein Bug von VirtualBox vermutet. Es ist ein kleiner Trick notwendig, um die Änderung in der VM zu reflektieren. Dabei wird eine neue virtuelle Maschine erzeugt, welche das vergrößerte Image als Festplatte enthält und das ISO-Image der Live-Version von GParted als CD zum Booten zugeteilt bekommt. Darin wird die neue Größe dann erkannt.
Schritt 2: Änderung der Partitionierung
Zur Änderung der Partitionierung wird das System mit einer Live-Version von GParted gebootet. Innerhalb von GParted wird dort ein Bereich von 11 GB als 'unallocated' vermerkt.
Die Schritte im einzelnen:
Löschen von 'sda3'
Erfolgt über das Kontextmenü, danach sind 12.3 GB frei.
'sda2' verschieben und vergrößern
Das erfolgt ebenfalls über das Kontextmenü 'Resize/Move' mit diesen Parametern:
- Free space preceding (MiB): 4098
- New size (MiB): 15360
- Free space following (MiB): 0
'sda1' vergrößern
Parameter:
- Free space preceding (MiB): 0
- New size (MiB): 4095
- Free space following (MiB): 0
Durchführung der Schritte
Abschließend auf 'Apply' klicken, um alle Schritte durchzuführen. Es werden noch mal alle Schritte aufgeführt, die durchgeführt werden sollen und eine explizite Bestätigung eingeholt, weil die folgenden Aktivitäten Datenbestände löschen können bzw. werden.
Die folgende Durchführung kann einige Zeit in Anspruch nehmen.
Abschließend sollte die virtuelle Maschine sauber beendet werden.
Vergrößerung der Dateisysteme
Nach dem Start der VM wird überprüft, ob die Partitionierung nun den Erwartungen entspricht.
Hinweis: Der erste Start der virtuellen Maschine kann unverhältnismäßig lange dauern, weil nach der Partitionsänderung Dateisystem-Checks durchgeführt werden.
localhost:~ # fdisk -l /dev/sda Disk /dev/sda: 20.4 GB, 20401094656 bytes, 39845888 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000d8d71 Device Boot Start End Blocks Id System /dev/sda1 * 2048 8386559 4192256 83 Linux /dev/sda2 8388608 39843839 15727616 8e Linux LVM localhost:~ # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 19G 0 disk ├─sda1 8:1 0 4G 0 part /boot └─sda2 8:2 0 15G 0 part ├─system-root 253:0 0 6.1G 0 lvm / └─system-swap 253:1 0 512M 0 lvm [SWAP] localhost:~ # pvs PV VG Fmt Attr PSize PFree /dev/sda2 system lvm2 a-- 15.00g 8.40g localhost:~ # lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert root system -wi-ao--- 6.10g swap system -wi-ao--- 512.00m localhost:~ # df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 5.9G 4.5G 1.2G 81% / devtmpfs 486M 32K 486M 1% /dev tmpfs 499M 80K 499M 1% /dev/shm tmpfs 499M 2.7M 496M 1% /run tmpfs 499M 0 499M 0% /sys/fs/cgroup tmpfs 499M 2.7M 496M 1% /var/lock tmpfs 499M 2.7M 496M 1% /var/run /dev/sda1 3.9G 50M 3.7G 2% /boot
Man erkennt, dass /boot auf sda1 und das PV auf sda2 vergrössert wurde.
Aber das LV für /root ist noch unverändert und muss separat vergrößert werden. Auch dies sollte auf keinen Fall im laufenden System durchgeführt werden, sondern stattdessen nochmal mit dem GParted-ISO gebootet werden:
user@debian:~$ sudo lvchange -a y system/root user@debian:~$ sudo lvresize --resizefs --size +8.3G system/root Rounding size to boundary between physical extents: 8.30 GiB fsck from util-linux 2.20.1 /dev/mapper/system-root: clean, 147123/399840 files, 1184202/1598464 blocks Extending logical volume root to 14.40 GiB Logical volume root successfully resized resize2fs 1.42.8 (20-Jun-2013) Resizing the filesystem on /dev/mapper/system-root to 3774464 (4k) blocks. The filesystem on /dev/mapper/system-root is now 3774464 blocks long.
Anschließend steht der Speicherplatz vollständig zur Verfügung:
localhost:~ # lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root system -wi-ao--- 14.40g
swap system -wi-ao--- 512.00m
localhost:~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/system-root 15G 4.5G 8.9G 34% /
devtmpfs 486M 32K 486M 1% /dev
tmpfs 499M 80K 499M 1% /dev/shm
tmpfs 499M 2.6M 496M 1% /run
tmpfs 499M 0 499M 0% /sys/fs/cgroup
tmpfs 499M 2.6M 496M 1% /var/lock
tmpfs 499M 2.6M 496M 1% /var/run
/dev/sda1 3.9G 240M 3.5G 7% /boot
