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:
- BACKED UP THE ENTIRE HARD DISK.
sudo apt-get install gparted on KDE Neon.- 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.
- 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.
- 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.
- I right clicked on the unlocked
LUKS partition, and encrypted it again. The icon went from light blue back to red.
- 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.
Best Answer
solved on ubuntu...might require a little tweaking for debian, but you get the idea http://ubuntuforums.org/showthread.php?t=843571
note you wouldn't need the mmc options added to ramdisk as he did in that tutorial since usb should already be loaded anyway...if it isn't you might need to add that module instead