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:
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 theLUKS
partition, I think a few bytes before the start of the file system it's encrypting. ALUKS
file system can only be expanded when theLUKS
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 aKDE Neon
bootable USB. I would caution, however, that I encountered a bug inKDE Partition Manager
that was introduced sometime before version2.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 theLUKS
partition left to the front of the extended partition, then unencrypt theLUKS
partition, expand theLUKS
partition right to include the new data, and finally encrypt theLUKS
partition again. An early version ofKDE Partition Manager
(1.x
, which I obtained withapt-get
fromUbuntu 16.04 LTS
) was able to expand the partition left, but I did not feel comfortable accepting that change because sinceKDE Partition Manager
didn't have support forLUKS
in particular, I wasn't completely sure thatGRUB
would be able to find the partition and unlock it after a reboot. So I tried compilingKDE Partition Manager 2.2.0
on aUbuntu 16.04 LTS
bootable USB, and the application was unable to physically drag the extended partition left in the same way that version1.x
had done. I therefore loaded aUbuntu 18.04 LTS
daily build on a bootable USB, then compiledKDE Partition Manager 3.3.1
on that device (along withKDE 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 installedKDE 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. Nowgparted
can do this just fine, but it doesn't haveLUKS
support. So I took a leap of faith and did the following, which worked:sudo apt-get install gparted
onKDE Neon
.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 myLUKS
volume. I then exitedgparted
. My major concern for this was that sincegparted
doesn't have support for LUKS, I was worried that it would potentially move the front of theLUKS
volume for alignment reasons and actually render it unopenable. So I made careful note of the exact disk sector where theLUKS
partition started prior to making any edits, and then didn't have to use those notes.KDE Partition Manager 3.3.1
, I moved the (encrypted)LUKS
volume left. Just right click on theLUKS
volume, selectResize/Move
, and I think you just drag the icon in the GUI to the left. You know you will be doing this right because theLUKS
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 clickedApply changes
and waited.KDE Partition Manager 3.3.1
, I right-clicked on theLUKS
volume and selectedUnencrypt
(maybe it wasopen
) and typed in my password. Then I right-clicked the same partition, and clickedResize/Move...
. I then dragged the right edge of the partition to the right to encompass the 40 GB of free space. I then clickedApply changes
again.LUKS
partition, and encrypted it again. The icon went from light blue back to red.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 usingsudo partitionmanager
from CLI: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 theblkid
process may be the cause of the bug. But I don't really know. Anyway, hope that helps you.