I don’t purport to be an expert on any of this, but I can tell you what worked for me when I replaced the NVMe SSD on my laptop from a 256GiB SSD to one that was 1TiB. (Steel yourself; this will be a bit painful to read, I’m sure…)
Note that the following occurred after I’d already installed f33, I believe, and that was after doing all of the necessary re-partitioning/resizing of my main, Bitlocker-encrypted, WindowsOS partition up front.
My LUKS-encrypted, btrfs filesystem, with /
and /home
subvolumes was the last partition on the native drive with no blank space at the end, iirc:
- I plugged in an external SSD controller with the 1TiB SSD installed in it via a USB C connection and booted the then current Fedora Workstation live iso;
- From the live iso, I installed
gparted
and ddrescue
using dnf
;
- Fired up
gparted
to find the device identifiers for the source and target drives so that I could clone my native SSD;
- Did the clone of the entire native drive to the target, 1TiB SSD using
ddrescue
with the previously identified source and target drives;
- Once that finished, back in
gparted
, I refreshed the device list, and, at refresh time, that application showed output that indicated that the still present target drive appeared to be smaller than its physical size; this warning queried whether I wanted to extend it to reflect its physical size. I responded by clicking the ‘Yes’ button.
So, my memory is that this last partition was already LUKS resized to the size of the entire partition.
After all of that, I did couple of syncs
just to be safe and shut down the system, and I physically replaced the native SSD with the larger, now cloned and extended SSD. Everything worked exactly like I’d hoped: I could boot both Windows and Fedora, and all the filesystems were present, as before the swap, on each.
- My last step was to boot into Fedora and resize the btrfs file system. The command to do that looked something like
btrfs filesystem resize max /
. Obviously, you’ll have to use a different command than that for your system.
Okay, if you’re with me this far, I guess the answer to your question is that, within the constraints of my old-guy memory, resizing a LUKS-encrypted partition using gparted
will resize the LUKS container automagically. You should be able to boot your installed Fedora system and check that this is the case by using df
and cryptsetup status
and comparing the results.
Here’s how to do that last bit, from your now-booted, installed Fedora system, which I’ll show you with the example of how I do that on mine.
- First, find the name of your LUKS device:
ls -l /dev/mapper/
.
- Mine comes back as
luks-d32f8c7c-a450-4d8e-884a-965066607f69
, which is a symbolic link to a device in /dev
.
- Using that name, I can check the LUKS container size in one of the fields returned by
sudo cryptsetup status luks-d32f8c7c-a450-4d8e-884a-965066607f69
.
I can tell you that mine checks out consistently using various cross checking methods, such as gparted
, df
, etc.
Wow, that was a lot longer than I set out to make it! I hope it helps you get started. Good luck!