Uwe Hermann - Resizing a dm-crypt / LVM / ext3 partition - Comments

Thanks (and an Ubuntu live-cd note)

Anonymous — Thu, 18 Dec 2008 04:35:42 +0100

Great post, your method worked like a charm for me. Just a tip for anyone booting from a Ubuntu live cd: run sudo modprobe dm-crypt before trying to open the luks partition with cryptsetup, or you'll get cryptic errors about "no keyfile found that matches this passphrase".

Why don't u just add a new

Kir — Fri, 07 Nov 2008 07:42:10 +0100

Why don't u just add a new Physical Volume to your Volume Group and then resize target Logical Volume?

resize2fs

Uwe Hermann — Wed, 23 Apr 2008 18:17:39 +0200

Yes, resize2fs should work just fine for ext2, too. But of course the usual disclaimer applies, make sure you have recent backups!

Uwe.

ext2 ..?

Rostyslav — Wed, 23 Apr 2008 17:31:00 +0200

nice article...but can this be applied to ext2...?
will there be any change in commands...? coz mine is ext2 filesystem and i need to resize it...

Do not know how to resize extra disk space after cloning disk

dstme — Mon, 21 Apr 2008 17:41:53 +0200

Hi, I google around and lucky I found your blog regarding resizing. I have trouble resizing after similar issue like you. But the difference is I'm newbie with Linux, so hope you can help me. Appreciate if you can help. If possible let me knowin step by steps. I'm almost give up. Here is my problem:

I've a 160Gb HD running with Centos5. I have just clone the 160Gb to 500Gb HD with G4U. After disk cloning, I have about 317Gb unused space. Because G4U copy bit by bits, system will show it is 80Gb even physically it is 500Gb. Basically, I like to merge the 317GB unused space to sda2 or at least make it useable. Understand from Gparted, that it does not support LVM, but I used it to show my status as below:

When I run Gparted for 500GB HD, it is showing:
/dev/sda1 ext3 /boot size:102MB used: 20MB Unused: 82MB
/dev/sda2 unknown size: 148.95GB used: --- Unused: ---- Flag: lvm
unallocated unallocated size: 317GB used: --- Unused: ----

On top right-hand corner, it's showing:
/dev/sda
/dev/mapper/VolGroup00-LogVol00 (148Gb)
/dev/mapper/VolGroup00-LogVol01 (988Mb)

If I select /dev/mapper/VolGroup00-LogVol00 (148Gb), it will display:
/dev/mapper/VolGroup00-LogVol00 ext3 Size: 148GB Used:8.6GB Unused: 139.4GB

If I select /dev/mapper/VolGroup00-LogVol01 (998GB), it will display:
/dev/mapper/VolGroup00-LogVol01 linux-swap Label:ID_FS_USAGE=other size: 992MB

fdisk

Uwe Hermann — Wed, 16 Apr 2008 00:49:06 +0200

Sure, if you know what you're doing and you are only messing with the partition table but not with the data itself, there's no problem. I'm just stressing the point that you shouldn't blindly type stuff at an fdisk prompt unless you know what you're doing ;-) I don't want to be responsible for other people losing their data.

Uwe.

Interesting

er:c — Tue, 15 Apr 2008 09:49:10 +0200

Really interesting information. I never had to resize an LUKS-encrypted volume, but it can happen, so I hope I will remember to come here when i'll need it :)

fdisk

blindcoder — Tue, 15 Apr 2008 08:00:18 +0200

Changing the partition size is a lot less scary than you make it out to be.
The partition table is a few bytes at the beginning of the harddisk. Changing it is about as scary as editing my ~/.profile file.
If you want to be extra super careful, make a dump of the partition table before:

sfdisk -d /dev/hda > hda.partitionlist

This can then be reimported in case something Bad happend:

sfdisk /dev/hda < hda.partitionlist

Resizing a dm-crypt / LVM / ext3 partition

Uwe Hermann — Mon, 14 Apr 2008 17:32:18 +0200

I've bought a new hard drive for my laptop recently, because I finally got fed up with my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk.

As I didn't want to re-install from scratch I started with dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise.

The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course).

0. Perform backups, boot from a live CD

Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!

First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance.

1. Resize partition

This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space.

Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted!

2. Resize dm-crypt volume

Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using cryptsetup now:

  $ cryptsetup luksOpen /dev/hda3 foo

3. Resize LVM physical volume

Next step is to tell LVM about the new space. We first resize the LVM physical volume on the foo "partition" to use up all newly-available space.

  $ pvresize /dev/mapper/foo

4. Resize LVM logical volume

Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:

  $ lvresize -L +74 GB /dev/vg-whole/lv-home

5. Resize ext3 filesystem

The final step is to resize the ext3 filesystem on the lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:

  $ fsck -n /dev/vg-whole/lv-home
  $ ext2resize /dev/vg-whole/lv-home
  error: Invalid argument: seeking to 3258921205760

This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:

  $ fsck -n /dev/vg-whole/lv-home
  $ resize2fs /dev/vg-whole/lv-home

That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!