Atomic Desktops: Increase Size of GPT partition table, keeping LUKS partitions and all data

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 tried that?
Hands on testing is the best teacher.

yes I dont want to rush things. I cannot reinstall as anaconda is broken. And I did not find the time to search for other tools, but yes fdisk and gdisk seem to be good ones.

$ sudo fdisk -l
GPT PMBR size mismatch (1953525167 != 3907029167) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/nvme0n1: 1,82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: CT2000P5PSSD8                           
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5FD134DE-5CB2-432F-822C-05DEE5D0692D

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1    2048    1230847    1228800   600M EFI System
/dev/nvme0n1p2 1230848    3327999    2097152     1G Linux filesystem
/dev/nvme0n1p3 3328000 1953523711 1950195712 929,9G Linux filesystem

Disk /dev/mapper/luks-e755629a-0756-4ada-b584-e3dcc8a7f1b4: 929,91 GiB, 998483427328 bytes, 1950162944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/zram0: 8 GiB, 8589934592 bytes, 2097152 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

So, what I will do (?)

  1. backup
  2. boot to fedora usb with gdisk installed
  3. resize the GPT partition table to max
  4. udisksctl mount and unlock the luks encrypted partition
  5. resize BTRFS partition to max
  6. rebalance btrfs.

Probably best to not mount at that step, but definitely unlock it.
Everything else would be mostly correct. I would use gdisk or gparted to resize the partition since both are designed for use with gpt partitions. You should only need to

  1. unlock the partition
  2. resize it with gparted (it should automatically resize the file system at the same time)
  3. If necessary do repairs on btrfs, but I would expect very little needing done.
1 Like

I don’t think it will with btrfs, if you resize the partition the volume is on I think you will find you have to resize the FS too, and likely balance and possibly scrub the FS after.

Okay I will see. Another point, should I balance and scrub from external media? Because when booted most of it is read only.

Actually that sounds like a flaw in immutable BTRFS.

Okay, so Fedora 40 KDE didnt want to boot off Ventoy, and also not from normal burned stick.

I then user my good old Debian 11 based Clonezilla, which was fine. Load to RAM, exit to shell.

sudo -i

# get device location
fdisk -l

# enter gdisk shell
gdisk /dev/nvme0n1

# list partitions
p          # make photo !

# delete table and all partitions and recreate table

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

# write changes

shutdown now

That was it. It is booting… and login works!

The last partition, standard to be storage on Fedora Kinoite “auto partition” has the correct size!

Some optional stuff that should not be needed

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

sudo bash
for dir in "/var" "/var/home" "/etc"; do
      btrfs balance start "$dir"

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

Even though it is basically all /var, I think this should do it as these are the mutable BTRFS subvolumes?

Also, no idea how I can balance and defragment the immutable partitions, is that just not needed? Should I do that from an external media?

Wouldnt want to do that on outdated Clonezilla which likely uses an older version of BTRFS than Fedora.

It worked, thanks for the help! But please understand that for a guy with ADHD, not rushing and destroying stuff is like peak behavior ;D.

1 Like

I am now rescanning all my torrents, to see if the strange filesystem write issues are gone. For now it seems to be solved!

Edit: no that seems to be a differen issue…

Added fdisk, filesystem, gdisk, gpt

It’s not necessary to balance following a resize on Btrfs. A scrub is also not necessary, if you’re going to scrub you might as well start with one because ideally you don’t want to start the resize if there are unfixable problems with data or metadata.

Anyway, congrats!

1 Like