Atomic: Resize, defragment, balance LUKS encryped BTRFS partition

Coming from this post I dded a Fedora Kinoite install from a 1TB to a 1,8TB NVME SSD.

I want to now resize it, is this possible on Atomic?

sudo btrfs filesystem resize max /
# told be it worked and resized the partition

Balancing seems to do nothing, no matter the location

for dir in "/" "/var" "/var/home" "/etc"; do
    sudo btrfs balance start -dusage=0 "$dir"

Defragmenting it only worked for the mutable subvolumes, but seemed to work. Still, not being able to defragment some subvolumes sounds problematic?

sudo btrfs filesystem defragment -r -v /var /var/home /etc

it currently looks like this

nvme0n1                         259:0    0   1,8T  0 disk  
├─nvme0n1p1                     259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                     259:2    0     1G  0 part  /boot
└─nvme0n1p3                     259:3    0 929,9G  0 part  
                                253:0    0 929,9G  0 crypt /nix

How can I resize the partition, as it didnt seem to do anything?


It looks like you have a LUKS partition that holds your rootfs, so my guess is that you have to unlock the LUKS partition first and then resize the btrfs filesystem.

A quick search brings up this hit on StackExchange with additional instructions - Extend BTRFS LUKS partition - Unix & Linux Stack Exchange

I’m not familiar with how these kinds of operations are done with btrfs, so be cautious with my advice. :smile:

1 Like

This command:

sudo btrfs filesystem resize max /

resizes the file system, not the partition.

To grow a file system on LUKS/dmcrypt, the underlying partition nvme0n1p3 needs to grow first. The dmcrypt volume that appears asluks-e755629a-0756-4ada-b584-e3dcc8a7f1b4 is sized based on the size of nvme0n1p3.

The resize is quite straightforward. However…

First, backup anything important enough that you’d become aggravated if it were lost.

Second, either using fdisk or gdisk, you should record the starting LBA for nvme0n1p3 and put it somewhere safe i.e. not anywhere on this drive, such as a mobile phone photo. Next you’ll delete this partition, create a new partition confirming it has the same starting LBA. The ending LBA is entered for you, and defaults to the maximum available contiguous free space (usually the end of the drive minus some space for the backup GPT). Write that change to disk.

Third, reboot. And last you can now resize Btrfs as you did before. No subsequent reboot is needed.

Another option: You can also boot any Fedora release Live install media, and use dnf install gparted to do this graphically. I haven’t tested this recently, but it’s reported to work. Whereas I have tested the fdisk and gdisk methods many times, so I know it works.

(Yes it seems scary to delete a partition, but it’s not literally being deleted - it’s just an edit list, and a GPT partition is really just a partition entry. You’re deleting an entry, creating a new one, then writing it to disk. In effect, you’re writing a modification of the partition entry to disk. Also, the write order for GPT primary and backup locations is specifically coded in fdisk and gdisk to be crash safe, so in no case will partition #3 just go missing in action.)

1 Like

hey thanks, I will try to follow your instructions.

You are of course right, after mounting with udisksctl and then unlocking (both possible in KDE Dolphin) I could then resize the BTRFS filesystem to max, but there was nothing to resize.

I already did an rsync backup.

I am on a secondary disk with Kinoite 40 prerelease, ensuring I have the latest driver for my NVME (which I think caused the problem of Anaconda not booting, which is why I needed to dd at all)

So I just delete the Luks encrypted partition, I would do this in KDE File manager? and then create a new one and also encrypt that, with the same password?

That works???

Step 1

1.1 inspect the starting and end block

1.2 now delete the LUKS partition (DO NOT SHRED)

1.3 create a new partition

1.4 Use exactly the same defaults as Fedora

  • primary
  • encrypt with LUKS, use the same password
  • Label: fedora_fedora
  • click “advanced”, verify that the first sector is the same

Step 2

2.1 In KDE Partitionmanager, unlock the luks volume

2.2 KDE Partitionmanager has a “auto repair partition” feature that resizes the BTRFS filesystem to match the new partition size.

PROBLEM: when creating a new partition (1.4), the max size is not 1,7xTB but still 9.000.000MB. But there is no “unallocated space” like it is normally shown.

Do I need to recreate the partition table? Is that dangerous?

So, the suggested solution only works when there is unallocated space left.

The problem is, there isnt any unallocated space shown. Do I need to fix the GPT partition table to match the correct unallocated space?

I get strange write issues with qBittorrent, saying I dont have storage space left, while I have.

Meanwhile, I cannot reinstall to that SSD, probably, because Anaconda fails to boot with that NVME attached

I wrote:

Second, either using fdisk or gdisk

You wrote:

So I just delete the Luks encrypted partition, I would do this in KDE File manager? and then create a new one and also encrypt that, with the same password?

Absolutely not! Creating a new LUKS partition will destroy all the data in the partition because it will overwrite the current LUKS header. Don’t do this with KDE Partition Manager.

That’s why I mentioned fdisk or gdisk which only modify the partition map, the contents of the partition are not touched, thus leaving your data intact. If you overwrite anything inside an encrypted partition, it’s virtually certain all data will be lost.

1 Like

Could you give me an example with fdisk how this can be done ? Thanks!

fdisk is pretty low level so if you’re going to use that you should first understand those concepts. Otherwise I recommend gparted, which should be able to do this for you. I’m pretty sure KDE Partition Manager’s “resize/move” option is similar, I just haven’t used it. You might be best off creating an identical layout in a VM, and doing some trial resizes in Partition Manager within the VM to make sure the end result is expected.

Unfortunately this is why most of the more experienced folks just recommend backing up, and starting over. It’s a lot easier to explain that. The advanced partition stuff is not easy to explain, you kinda just have to experience it. I have induced my own simulated data loss many times building up that experience.

A file manager is for managing files – NOT PARTITIONS.

To manage partitions use a partition manager such as fdisk, gdisk, parted, or gparted (graphical).

Your goal is apparently to enlarge a partition that was sized exactly as on the old disk and is smaller than the physical disk it now resides upon.

The instructions by Chris, just above, seem very clear as long as you use the proper tool and read and follow the instructions carefully. As recommended, a good and verified backup should be done before starting. The partition usually may be enlarged by gparted but probably should not be mounted when the size is changed. In my experience gdisk is able to extend the file system as well as the partition, but the file system should be unlocked before doing so.

I dont think gparted can do more than KDE Partitionmanager.

As said, KDE Partitionmanager showed no free space, so a normal resize is not possible.

@computersavvy Dolphin allows to mount and unlock drives using udisks2 in the background. Of course not for anything else.

  1. I need to increase the detected size of that partition table (?) or something
  2. I need to increase the partition?
  3. I need to increase the decrypted LUKS partition?

the problem is not as easy as you both assume. I guess resizing to max would be possible completely in the GUI. The problem is, that every tool shows a max size (of the entire partition table, partition set, disk, whatever) matching the old SSD, 1TB instead of the correct 1,8TB

So there is no unallocated space detected.

Note that it would be possible for me to reinstall but

  1. I think having this solved is a huge learning and could be documented (btw the normal resize to max, including LUKS, should be documented)
  2. Anaconda doesnt start, I am trying to resolve the multipart issue in some time

Note that you can use the tools already named (fdisk, etc.) and use them to display the status of the device, partitions, etc.
Try sudo fdisk -l and show us the result related to that drive. It may surprise you what information it actually provides. Just as an example:
I use a 64G flash drive and write the fedora install iso image to that drive. It now shows ~2G as the device size. When I want to use it for another purpose I use fdisk, create a new partition table, and the entire device is now usable. Walla – the device is restored.
Are you so afraid of what might happen that you will not even try?

Using dd to copy a smaller device to a larger device will result in the partition table on the device only knowing about the size of the original device. This is what needs changed so it sees the size of the physical device, not the original (smaller) device

You could have done several backups and a full reinstall in the time you have been hesitating to try the suggested commands.

Note also that the command sudo fdisk /dev/nvme0n1 will oopen the device where you can view its status and config before changes. As will parted, gdisk, etc. Read the man pages on how to use them.

you said I dont think gparted can do more than KDE Partitionmanager but did you test to see? They are not identical. I don’t know the differences but I am 100% certain they are not clones.

Peruse the man pages for each of those tools to see the differences, and if you have a backup then do not be afraid to try things out. This dilly - dallying and back and forth with indecision is not helping you or us. You seem to want us to give you a step by step, guaranteed to work solution, but without doing exactly the same on the same hardware and the same config it is impossible for us to do so. Step up and do something instead of being indecisive and demanding a guarantee.

We make suggestions based on experience and you take action or not based on those suggestions. This is not the first thread where you have demanded assurances on each step before you would move forward.

It was even suggested that you try a VM to see how that would work. Have you tired that?
Hands on testing is the best teacher.