Partitioning – Move and Resize a LUKS Partition

gptlukspartitioning

I have a LUKS encrypted partition that is NOT into an LVM volume manager. It's at the end of the hard drive, and its size is 250 GB, but I want to add 50 more GBs to it.

I would normally use GParted for such operations, but it doesn't allow me to do anything with LUKS partitions, not even moving.

How can I do this without losing my data? (I have no other place to back it up)

This is my (GUID) partition table:

GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D630E573-66C0-4902-A4A2-A9D56AE54544
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 262922206 sectors (125.4 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  
   2          411648        63326207   30.0 GiB    8300  Linux filesystem
   3       189155328       273041407   40.0 GiB    AF00  
   4       273041408       304498687   15.0 GiB    8300  
   5       336732160       337141759   200.0 MiB   0700  
   6       337141760       347627519   5.0 GiB     8200  
   8       452485120       976773134   250.0 GiB   8300  Linux filesystem

This is how it looks like in GParted:

enter image description here

As you can see, I want to add those 50GB between sda6 and sda8 to sda8.

Can you help me move /dev/sda8 backwards so that I can then expand the encrypted volume and filesystem inside of it?

Best Answer

This is actually harder to do than it sounds. The reason is that when locked, a LUKS partition must refer to a very specific location on disk as referenced in your partition table in order to be unencrypted. That spot is at the very left of the LUKS partition, I think a few bytes before the start of the file system it's encrypting. A LUKS file system can only be expanded when the LUKS partition is unencrypted. So you can see that it's easier to expand it right than to expand it left, because more can go wrong when you expand left.

I was able to do this with KDE Partition Manager 3.3.1, using a KDE Neon bootable USB. I would caution, however, that I encountered a bug in KDE Partition Manager that was introduced sometime before version 2.2.0. My setup was an encrypted LUKS partition at the front of an extended (logical) partition, with 40 GB of free space on the hard disk in front of the extended partition. I needed to move the extended partition left, then move the LUKS partition left to the front of the extended partition, then unencrypt the LUKS partition, expand the LUKS partition right to include the new data, and finally encrypt the LUKS partition again. An early version of KDE Partition Manager (1.x, which I obtained with apt-get from Ubuntu 16.04 LTS) was able to expand the partition left, but I did not feel comfortable accepting that change because since KDE Partition Manager didn't have support for LUKS in particular, I wasn't completely sure that GRUB would be able to find the partition and unlock it after a reboot. So I tried compiling KDE Partition Manager 2.2.0 on a Ubuntu 16.04 LTS bootable USB, and the application was unable to physically drag the extended partition left in the same way that version 1.x had done. I therefore loaded a Ubuntu 18.04 LTS daily build on a bootable USB, then compiled KDE Partition Manager 3.3.1 on that device (along with KDE Core 3.3.0). Same problem. But in both of those cases, there had been some compilation issues that I had to work around by directly editing the Make files, and the reason for this was that I was compiling in Ubuntu instead of a flavor of Ubuntu with native KDE libraries. So I installed Neon on a bootable USB, directly downloaded and installed KDE Partition Manager 3.3.1 through the software downloader, and once again encountered the same bug -- I was unable to move my extended volume left. Now gparted can do this just fine, but it doesn't have LUKS support. So I took a leap of faith and did the following, which worked:

  1. BACKED UP THE ENTIRE HARD DISK.
  2. sudo apt-get install gparted on KDE Neon.
  3. I used gparted to move the extended partition left 40 GB, and saved changes. (I think I had to turn off my swap space first.) That created 40 GB of free space within the extended partition, to the left of my LUKS volume. I then exited gparted. My major concern for this was that since gparted doesn't have support for LUKS, I was worried that it would potentially move the front of the LUKS volume for alignment reasons and actually render it unopenable. So I made careful note of the exact disk sector where the LUKS partition started prior to making any edits, and then didn't have to use those notes.
  4. In KDE Partition Manager 3.3.1, I moved the (encrypted) LUKS volume left. Just right click on the LUKS volume, select Resize/Move, and I think you just drag the icon in the GUI to the left. You know you will be doing this right because the LUKS partition is red before and after you move it, indicating that it's locked the entire time (and so the partition table is essentially recording the new location of the spot on disk where LUKS will go ahead and do the unencryption when the user logs in). Then I clicked Apply changes and waited.
  5. In KDE Partition Manager 3.3.1, I right-clicked on the LUKS volume and selected Unencrypt (maybe it was open) and typed in my password. Then I right-clicked the same partition, and clicked Resize/Move.... I then dragged the right edge of the partition to the right to encompass the 40 GB of free space. I then clicked Apply changes again.
  6. I right clicked on the unlocked LUKS partition, and encrypted it again. The icon went from light blue back to red.
  7. I turned my swap space back on (necessary because the Linux swap space is inside my extended partition). Then I exited KDE Partition Manager, shutdown and rebooted using the primary hard drive that I just partitioned. I was able to unencrypt the drive and log in without trouble. Whew!

Many thanks to Andrius Stikonas for maintaining this really useful application. The last time I moved a LUKS partition it was using these steps and it was a nightmare.

Here's the output from KDE Partition Manager that prints to console when you run it using sudo partitionmanager from CLI:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Loaded backend plugin:  "pmlibpartedbackendplugin"
"Using backend plugin: pmlibpartedbackendplugin (1)"
"Scanning devices..."
"Device found: ATA ST500LM021-1KJ15"
blkid: unknown file system type  ""  on  "/dev/sda4"
"Partition ‘/dev/sda4’ is not properly aligned (last sector: 976773167,    modulo: 48)."
"Device found:  USB DISK 2.0"
getting smart status failed for  "/dev/sdb" :  Operation not supported
"Partition ‘/dev/sdb2’ is not properly aligned (first sector: 404, modulo: 404)."
"Partition ‘/dev/sdb2’ is not properly aligned (last sector: 5139, modulo: 1044)."
"Scan finished."
"Add operation: Move partition ‘/dev/sda8’ to the left by 40.50 GiB"
"Applying operations..."
"Using backend plugin: pmlibpartedbackendplugin (1)"
"Scanning devices..."
"Device found: ATA ST500LM021-1KJ15"
"Partition ‘/dev/sda4’ is not properly aligned (last sector: 976773167, modulo: 48)."
"Device found:  USB DISK 2.0"
getting smart status failed for  "/dev/sdb" :  Operation not supported
"Partition ‘/dev/sdb2’ is not properly aligned (first sector: 404, modulo: 404)."
"Partition ‘/dev/sdb2’ is not properly aligned (last sector: 5139, modulo: 1044)."
"Scan finished."
"Add operation: Grow partition ‘/dev/sda8’ from 101.77 GiB to 142.26 GiB"
"Applying operations..."
"Using backend plugin: pmlibpartedbackendplugin (1)"
"Scanning devices..."
"Device found: ATA ST500LM021-1KJ15"
"Partition ‘/dev/sda4’ is not properly aligned (last sector: 976773167, modulo: 48)."
"Device found:  USB DISK 2.0"
getting smart status failed for  "/dev/sdb" :  Operation not supported
"Partition ‘/dev/sdb2’ is not properly aligned (first sector: 404, modulo: 404)."
"Partition ‘/dev/sdb2’ is not properly aligned (last sector: 5139, modulo: 1044)."
"Scan finished."
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 28349, result = 0
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Connecting to deprecated signal      QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: opened connection to :0
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: PID 28354 terminated.
kdeinit5: PID 28353 terminated.

See that line that reads blkid: unknown file system type "" on "/dev/sda4"? /dev/sda4 is my extended partition and I suspect this NULL response from the blkid process may be the cause of the bug. But I don't really know. Anyway, hope that helps you.

Related Question