HowTo: clone a LUKS encrypted install to a bigger disk

Ask Fedora
, , , , , , , , ,
1

If you want to clone an install to a bigger disk, without reinstalling, this is possible.

I did this with Fedora 40 Kinoite, LUKS encrypted.

I used a Clonezilla flashdrive I had laying around, load to RAM, exit to shell. But you can also use a live Fedora install medium.

If the system you are cloning is the one you use, close as many running programs, disable internet, disable background services (syncthing, nextcloud, VPN, …). But this is not recommended!

A: Use Clonezilla

This is very easy. You can follow this guide.

For flashing Clonezilla to a pendrive/usb-stick, you can use Fedora-Media-Writer, KDE IsoImageWriter, Impression or dd (instead or UnetBootin).

  1. Choose “load to RAM”
  2. Choose “clone local disk to local disk” (make sure both drives are connected securely)
  3. During clone, choose “proportionally -k1” to automatically use the new size

Do get Clonezilla, go to their download page and select “iso”. If you are on an AMD or Intel Computer, choose “amd64”.

If you use very recent hardware (newer than 3 years), you may want to use the “alternative” version, which uses Ubuntu instead of Debian, supporting more recent hardware and nonfree drivers.

After using Clonezilla, skip to step 4 below.

B: Manual Way

This is manual, you can learn something and it works if for whatever reason Clonezilla does not work.

1. Clone the drive

This is dangerous, be sure to check the commands!

Make sure all the drives are connected securely.

# list block devices
lsblk

# here my devices are "sda" and "nvme0n1"

# clone the drive
sudo dd if=/dev/sda of=/dev/nvme0n1 status=progress && sync

2. Resize the partition table

The issue is, that after the dd also the partition table is cloned. The partitions cannot be enlarged, there is no free space shown.

To fix this, you need to recreate the partition table bit-by-bit using the exact numbers.

A misalignment will result in data loss.

Use gdisk to do this.

sudo gdisk /dev/nvme0n1

# list partitions, this is critical, take a photo!
p

# delete table and all partitions and recreate table
o 

# create new partitions
n          # default start sector, define end sector, Code EF00 (EFI)
n          # default start sector, define end sector, default Code 8300 (Linux Filesystem)
n          # default start and end sectors, default Code 8300

# write changes
w

Turn off the device

shutdown now

3. Boot into destination disk

Start the device again, boot into the newly cloned system.

In a GUI partiton manager you can see the free space left. The last partition, default to be storage, can just be resized to max.

4. Resize the BTRFS partition to max

sudo btrfs filesystem resize max /
# tells me it worked
# repeat to see the new size, it worked

5. BTRFS care

sudo btrfs balance start /

sudo btrfs filesystem defragment -r -v /
3

Added luks2

4

Another semi-command line way to accomplish this is to use ddrescue instead of dd. I do think that the docs recommend against going this route if the two drives have different logical block sizes, however.

I say semi because both before and after, I like to have gparted open to help me ensure which of the two drives is the source and which is the target, along with giving me their respective device names.

Afterwards, if you select “refresh devices” from the gparted main menu, it asks if you want to update the gpt partition table to reflect the actual size of the larger target drive. Responding yes takes care of the final detail.

I use this method for doing monthly backups as well—since I have both bitlocker and LUKS encrypted partitions, so I have to randomize the disk and partition GUIDs to have both disks present when I boot the live system USB to do backups; this helps also when I need to extract data from backups from my normally booted system. I use sgdisk -G just after a full-disk clone to do that.

I’ve successfully recovered data on the Fedora side of things using this method. If you have thoughts on whether that way of going about things is flawed, I’d love to know them. :slight_smile:

5

I used the manual way in the past, but Clonezilla worked so well… That there are no real reasons to not use it when possible.

6

Oh, I get that, definitely. I was only commenting on your manual way method. I wasn’t trying to say it wouldn’t be easier doing the whole thing with Clonezilla.

Btw, will the latter boot without turning off Secure Boot now?

7

Secureboot depends on the boot shim and that is cloned, so yes it boots normally.

8

I didn’t make myself clear: Is the Clonezilla Live system bootable with Secure Boot on?

9

If your UEFI allows custom keys then maybe.

If it only allows signed keys by microsoft, then no.

10

Is there any way to resize an EXT4 filesystem, instead of BTRFS?

11

Please use the other thread