Migrate a Fedora Atomic (Silverblue / Kinoite) install onto another drive

Ask Fedora
, ,
1

Hello,

I’ve recently purchased a larger drive and would like to migrate my luks-encrypted Fedora Atomic install to it, without installing or configuring anything. In other words, I’d like to clone the install, enlarge it to the larger available space, and continue working from there.

The partitions currently look like this:

/boot/efi - encrypted: no, size: 629MB
/boot - encrypted: no, size: 1.1GB
/ (root) - encrypted: yes, size: 75GB
/dev/home - encrypted: yes, size: the remaining size of the drive

Filesystem: EXT4

Now, my questions are the following:

  1. Is this possible?

I know that I can boot a live distro and clone the drive by using Gnome Disks or dd or whatever. Would it work i.e. create a bootable working system?

  1. After being cloned, how can I enlarge the non-system partitions (which is only one: /var/home) to the remaining larger size?

Mind that the drive is luks-encrypted right now, and I’d like the new one to be encrypted as well.

Thanks,

  • A
3

Does this help you?

1 Like
4

Hey Flo, thanks for the link, I also saw that post. It helps me partially i.e. I use EXT4 instead of BTRFS and don’t know if such a resize is possible with it. Is it?

5

Yes, easily possible, just not while mounted, you will have to boot a live system. Gparted can resize the ext4 fs.

6

Thanks for your reply, appreciate it.

So let me get this clear:

  1. I can clone the disk with say Clonezilla. The newly cloned disk will be encrypted with LUKS with the same passphrase / key and will be accessible.

  2. Then I can live-decrypt and open it with GParted, and tell it to enlarge /dev/home to the rest of the disk size. The encryption will remain, everything will be functioning, nothing will break, I will only have a larger /dev/home.

Is this right?

7

Do you use EXT4 in LVM?

I dont know much but afaik EXT4 is very basic and you can only resize it if it lies in an encrypted LVM.

Also, why not BTRFS? It makes stuff so much easier

8

Not true. The partition can be resized into open available space as long as it is contiguous. LVM does not require it to be contiguous, but that is really the only difference between LV and bare metal ext4 file systems.

Also not necessarily true for those of us familiar with ext4. The file system maintenance commands are much different and some do have more risk.

I occasionally use btrfs on some systems but as yet have not committed to btrfs on my main system. I would need to completely replace my 8TB /home with a new drive to make the switch.

2 Likes
9

On LVM: I don’t know. Originally installed Fedora Silverblue / Kinoite without too much going into partition and drive management. So I think yes?

On BTRFS: I had BTRFS break my system twice within a few months, so I decided to stay on EXT4 until things are improved.

1 Like
10

I guess what I’m asking here is, since I will clone my drive, it will clone on exactly half of the new drive (1TB → 2TB).

Will the second remaining half 1TB be encrypted as well when I will open it through GParted? Or should I do something through LUKS to encrypt it first, then mount it, and then enlarge my home?

11

I believe gparted is intended to extend the encryption onto the expanded partition the same as it does the file system. Note that I have not tried it so this is untested in my case.

The file system/partition must be expanded as a unit so the only way to encrypt it before expanding would be to create a new partition and that is not what you indicate you wish to do.

Maybe someone who has actually expanded an encrypted partition could chime in here with first-hand information.

12

cryptsetup resize should be the command to increase the encrypted mapping, IIRC. Afterwards the underlying file system has to be resized too.

13

Do I understand this then requires 3 steps?

  1. resize the partition
  2. run ‘cryptsetup resize’ to fix the encryption for the larger partition
  3. expand the ext4 file system to fill the partition with ‘resize2fs’
2 Likes
14

Well I have used steps 2 and 3 before, when there was unallocated space available on the partition.

Given that in this case the unallocated space is within the disk, but not within the partition, a tool like GParted needs to be used. However, I have made a test to increase a LUKS2 encrypted ext4 partition with GParted, and noticed that it has also increased the underlying filesystem automatically, and there was no need to use the cryptsetup resize and resize2fs commands.

2 Likes
15

Field report: yes Jeff, you are correct. I am currently writing off my newly migrated system :smiley:

Basically, I followed what you wrote here (in some more detail for newbies like me):

  1. Cloned the disk with Rescuezilla
  2. Gparted: resized the LUKS (watch out: not the EXT4 underneath it) partition to the rest of the remaining space
  3. Resized the LUKS encryption to the whole available space with cryptsetup resize /dev/nvme0n1p4 (again, working on the LUKS partition, not the EXT4 underneath which remained unmounted including on this step)
  4. Mounted the EXT4 partition under the LUKS container. As expected it was nominally in full size, but actually in almost half the size.
  5. Tried to resize the EXT4 partition to the remaining encrypted space with Rescuezilla’s resize2fs but it refused citing: “Filesystem has unsupported feature(s)”. It was because Rescuezilla’s supplied resize2fs is old, and ditto for PopOS’ install medium etc.
  6. Luckily, I started the installer (Anaconda) for Fedora Silverblue, and after fiddling with it for awhile, went into console (CTRL + ALT + F1; you can also enter console by choosing other options during boot and there’s a Repair Fedora install option or something).
  7. Found my LUKS block for my partition with lsblk (which was /dev/nvme0n1p4)
  8. From there, mounted the LUKS encrypted partition with cryptsetup luksOpen /dev/nvme0n1p4 (it asks for the password, and mounts it in /dev/mapper)
  9. ? Not sure if I mounted the EXT4 partition first with mount /dev/mapper/[mounted-device] /mnt/[name-of-mount]
  10. Then, FINALLY, used Fedora install disk’s resize2fs -f /dev/mapper/[mounted-device] (or maybe on /mnt/[name-of-mount], don’t remember this last step clearly) to resize the EXT4 filesystem.

Voila! Everything seems to be in order and working, I just continued working as if it is the very same system.

16

Hey Mike,

From what I read today, cryptsetup resize is basically unneeded because LUKS automatically does this on mount. resize2fs, however, was needed, because the system was able to access only half of the whole EXT4 allocated space underneath the LUKS container/partition.

1 Like
17

Mike showed that he tested using gparted and it managed everything in one step. If things are done individually then your method seems to be required.

Apparently gparted is intended to manage all that for the user (which was the understanding I noted in my post #9 above).

1 Like
18

I ran a couple of additional tests. Basically it depends on whether the encrypted mapper was opened/decrypted or not:

  • if GParted is used on a closed LUKS2 partition, then resize2fs has to be used, since (assumingly) only the partition table was manipulated, given that the underlying ext4 file system has not been revealed
  • if, on the other hand, the luks mapper has been opened (e.g. with cryptsetup open <device> <mapper> of via GUI), the ext4 file system becomes accessible, so GParted takes care of the rest, and increases the underlying file system size as well.
2 Likes
19

Thanks for your replies.

I think the issue with the EXT4 filesystem not being automatically extended by GParted is because of the bundled old resize2fs that is unable to do it (with some SSDs).

Still, it was a success. Thanks everyone for your help!

2 Likes