Mit meiner Entscheidung für Ubuntu auf meinem Laptop bin ich insgesamt zufrieden. Aber ähnlich wie bei meinem Server unter FreeBSD, manche Sysadmin-Tätigkeiten fallen nur sehr selten an, und dann muss ich mich erst informieren, wie es geht. Jetzt schreibe ich es mal hier ins Blog, dann weiß ich es fürs nächste Mal, und andere haben auch was davon.

Mein derzeitiger Laptop ist ein gebraucht gekaufter Dell Latitude E6540. i7 Quad-Core, 12GB RAM, 1920x1080 15,6” Display. Er kam mit einer 500GB HDD, aber nachdem ich vorher schon SSD gewohnt war, wollte ich auch hier eine SSD drin haben, hatte grad eine 120GB SanDisk SSD PLUS da, die ich wegen Defekt nach weniger als einem Jahr umgetauscht bekommen hatte. Für die Ubuntu-Installation und ein paar Basics reichte es, aber es war einfach zu wenig Platz für meine Daten. Also kürzlich mal eine WD 500GB SSD gekauft, das Zeug kostet ja fast nix mehr, schon unglaublich.

Aber wie migriere ich jetzt meine bestehende Ubuntu-Installation am schmerzlosesten? Im Web finden sich unterschiedliche Vorschläge, und in meinem Nerd-Bekanntenkreis gab es auch diverse mehr oder weniger anwendbare Tipps.

Neuinstallation wollte ich nicht, soviel Aufwand. Ubuntu hat die Platte partitiniert in:

/dev/sda1 /boot/efi
/dev/sda2 /boot
/dev/sda3 lvm mit VG ubuntu-vg und darin zwei LV 98.9GiB root, 12GiB swap_1

Ein Vorschlag war neu partitionieren, /dev/sda3 rüberkopieren und den Rest der neuen Platte als /dev/sda4 der VG hinzufügen.

Eleganter schien mir der andere Vorschlag, die komplette /dev/sda kopieren, sda3 und ihren Inhalt vergrößern. So hab ichs auch gemacht, mit großem Erfolg und wenig Aufwand.

Ubuntu Workstation bootet normalerweise direkt das Ubuntu, wenn man ins GRUB-Bootmenü will, muss man das erst sichtbar machen. Also vorbereitend /etc/default/grub editiert mit

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=3

Ich habe bei der Gelegenheit auch das BIOS des Laptops aktualisiert. Dell verwirrt dabei mit seinen Instruktionen, es entsteht der Eindruck, dass für das heruntergeladene E6540A26.exe ein DOS oder Windows benötigt wird. Tatsächlich hat das BIOS selbst im F12 Boot-Menü eine Option “Flash Update BIOS” und es genügt, die Datei auf einen FAT-formatierten USB-Stick zu kopieren.

Nun zur eigentlichen Aktion. Ubuntu trägt in das GRUB Boot-Menü pro installiertem Kernel neben dem normalen Boot auch einen Recovery-Modus ein. In der dargestellten Auswahl gibt es dann eine Option “root - start a root shell”.

Vorher hatte ich versucht, aus dem laufenden Ubuntu mit “systemctl isolate emergency.target” oder “systemctl isolate rescue.target” auf eine single user shell zu kommen, aber bei emergency blieb der Bildschirm komplett schwarz, bei rescue erschien eine Shell, aber die Tastatur wirkte tot und ich konnte nichts tippen.

Im Vorfeld habe ich die neue SSD in einen Optical Bay Adapter-Rahmen eingesetzt und statt des DVD-Laufwerks eingeschoben, damit sie direkt am SATA-Bus hängt. Linux sieht sie als sdb, wovon ich mich mit dmesg überzeugt habe.

Leider ist in der root-Shell / read-write gemountet, und ein mount -o remount,ro / schlägt wegen “device busy” fehl. systemd journald läuft, hat aber vermutlich nicht viel zu melden. Sauberer hätte ich es gefunden, das filesystem während der Kopie read-only zu mounten, aber ich habe das so in Kauf genommen und keine schlimmen Inkonsistenzen erwartet. Also die eigentliche Kopieraktion:

dd if=/dev/sda of=/dev/sdb bs=65536 status=progress

lief von SSD zu SSD recht zügig.

parted /dev/sdb

bei “print” meldet er schon (sinngemäß) “GPT table data differs from disk size. Fix/Ignore?” mit “f” beantwortet. dann “resizepart 3 500GB” und nochmal “print”. Im Gegensatz zu fdisk schreibt parted wohl jede Operation sofort auf die Partitionstabelle, daher reicht “quit” zum Beenden.

das wars erstmal, poweroff.

Eine Eigenschaft dieser Vorgehensweise ist, dass die UUID der Partitionen kopiert wird, also nicht mehr wirklich unique ist. Daher dürfen jetzt nicht beide Platten beim Booten gleichzeitig in Computer sein, sonst wäre nicht klar, auf welche sich die UUID in der fstab beziehen. Aber das war ja eh nicht mein Ziel.

Also jetzt alte SSD ausgebaut, neue SSD aus dem Optical Bay Rahmen in den Festplattenwinkel umgebaut und eingeschoben. Eingeschaltet, im BIOS schon mal nachgeschaut, dass jetzt die 500GB SSD gesehen wird. Booten verlief wie vorher.

Nun musste ich noch die zusätzliche Kapazität verfügbar machen.

lvm

lvm hat einen interaktiven Modus, in dem es sich Status merkt, man könnte die Kommandos auch einzeln auf der Shell absetzen. Erstmal gucken, was Sache ist:

pvs
vgdisplay
lvs

Nun die ganze Plattenkapazität unter die Hoheit von LVM nehmen:

lvm> pvresize /dev/sda3
Physical volume "/dev/sda3" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

lvm> pvs
PV         VG        Fmt  Attr PSize    PFree  
/dev/sda3  ubuntu-vg lvm2 a--  <464,68g 353,87g
lvm> vgdisplay
...
VG Size               <464,68 GiB
PE Size               4,00 MiB
Total PE              118958
Alloc PE / Size       28367 / <110,81 GiB
Free  PE / Size       90591 / 353,87 GiB
...
lvm> lvs
LV     VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
root   ubuntu-vg -wi-ao---- <98,90g
swap_1 ubuntu-vg -wi-ao----  11,91g

lvm> lvextend -A y -r -l +100%FREE ubuntu-vg/root 
Size of logical volume ubuntu-vg/root changed from <98,90 GiB (25318 extents) to <452,77 GiB (115909 extents).
Logical volume ubuntu-vg/root successfully resized.
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/mapper/ubuntu--vg-root is mounted on /; on-line resizing required
old_desc_blocks = 7, new_desc_blocks = 29
The filesystem on /dev/mapper/ubuntu--vg-root is now 118690816 (4k) blocks long.

Vorher/nachher Vergleich:

# df .
Filesystem                  1K-blocks     Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 101942624 90682020   6059096  94% /

$ df .
Filesystem                  1K-blocks     Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 467181144 90692652 356449184  21% /

Siehe da, auf / ist ein Haufen Platz dazugekommen. Juchhu!