File system resize vs partition resize

[alexivkin]

First - awesome tool, thank you for creating it. Works well, but the readme needs one clarification:

The file system size reduction should NOT be accompanied by reducing the partition size. Most partitioning tools, like gparted treat the file system and the partition containing it as all the same. So, if you use gparted to reduce the file system size you will have a partition that is shrunk to the size of the reduced file system as well. This will cause the file system to be labelled as broken and unmountable ("too big for the parent partition") when luksipc is done. It could be fixed later by removing and recreating the parent partition for the new size of the filesystem, but it's better avoided altogether by only using resize2fs.

Don't ask me how I found out about this ;)

[johndoe31415]

Good catch, I'll update this as soon as I get to it. Thanks for the report!

[Stvad]

Hey @alexivkin can you elaborate on the fixing steps? I basically did the same thing and now trying to fix it -_- @johndoe31415 You should really mention in the big letters this notion, because for me going for gparted was the most natural thing to do :)

[alexivkin]

If you accidentally resize the partition, while resizing the file system, you can recover later by deleting and re-creating the partition to encompass the now enlarged fs. To do this, run fdisk on the whole disk containing the filesystem. Hit P to see the current partition, F to check the free space, then D to delete the partition, n to create a new one, the matching the starting point and the size of the new file system. Press W to write to disk. This action only affects the partitioning table, and does not touch the filesystem itself.

It's absolutely important that the new partition starts at the same sector as the one you delete. If the original partition starts at sector 63 fdisk may not allow you to specify 63 until you run it with the -c=dos option.

[Stvad]

@alexivkin how do I get new fs size?

[alexivkin]

The "new" file system size is the same as the size of original FS before you reduced it to let luksipc do its magic.

[Stvad]

Ah, I see. Thank you it worked! :)

[dominicraf]

I am trying to apply this to system with mdadm RAID1 and LVM. There is one VG (called 'vg') and one PV (called /dev/m0p5), and these both hold two LVs (root and swap). This is currently a test system but I have a very similar real one.

I boot from SystemRescueCD (option 1) and after specifying my keyboard, setting a password (passwd) and logging in remotely, do:

# encrypt existing lvs 'root' and 'swap'
# see http://johndoe31415.github.io/luksipc/introduction.html
# get the code and build luksipc
wget https://github.com/johndoe31415/luksipc/archive/master.zip
unzip master.zip
cd luksipc-master
make
# resize the underlying ext4 fs as well as the LV
lvreduce -r --size -30m vg/root
# we have to move the swap LV so we can resize the PV
lvs
# note size of swap lv (1.25g)
lvremove vg/swap
# best recreate it a little big smaller (by 30m)
lvcreate --size 1.22g -C y -n swap vg
# now we could resize the PV, say 30m smaller - but don't?
# pvresize --set-physical-volume-size 7.73g /dev/md0p5
# good to go?
./luksipc -d /dev/md0p5

it starts but kicks out with:

/dev/md0p5: 7949 MiB = 7.8 GiB
Chunk size: 10485760 bytes = 10.0 MiB
Keyfile: /root/initial_keyfile.bin
LUKS format parameters: None given

Are all these conditions satisfied, then answer uppercase yes: YES
[I]: Created raw device alias: /dev/md0p5 -> /dev/mapper/alias_luksipc_raw_185859ce
[I]: Size of reading device /dev/md0p5 is 8335130624 bytes (7949 MiB + 0 bytes)
[I]: Backing up physical disk /dev/md0p5 header to backup file header_backup.img
[I]: Performing luksFormat of /dev/md0p5
[E]: luksFormat failed (execution successful, return code 5), aborting.
[E]: Exit with code 13 [EC_FAILED_TO_PERFORM_LUKSFORMAT]: Failed to perform luksFormat

I've also tried it resizing the pv (commented out above), with the same result. Any ideas gratefully received!

[johndoe31415]

Hi @dominicraf,

hmmm, this seems like a separate issue -- you do have the right permissions to perform luksFormat (i.e., you work as root or have rw permissions on /dev/md0p5), right? Just checking to be extra sure. Could you run with debug loggin (-l4) and post the output, possibly in a different ticket?

Apart from that issue (which deserves an issue of its own), I still think resizing the LV is the wrong way to go. With resizing the LV you effectively change the size of the block device, which is exactly what you don't want. You want to only change the size of the contained filesystem, but keep the size of the block dev constant. The way to resize the FS is described in the README.

Please feel free to create a new issue for the problem you described and don't forget to post the output of "luksipc -l4 -d /dev/md0p5". Also, if the output of that isn't too helpful, and ONLY if you have a backup (!!!) please try to luksFormat manually, i.e. "cryptsetup luksFormat /dev/md0p5". Don't do the last command if you're unsure how your header can be restored in case the format works.

Thank you and cheers, Joe

[johndoe31415]

I'm assuming this is solved, closing this issue.