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.
Did you manage this? I'm wanting to do the same. I assume I need to follow a similar process to enlarging. Although it sounds like it might be easier just to create a new partition and copy the data. – Jamie Kitson – 2016-04-04T08:48:44.067