[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cloning a lvm crypto volume to a bigger disk

> I want to move the crypto volume to new disk so I can use it and boot
> from the new.

Thanks for the information. Now I know what your setup looks like. I am
still a bit unsure about your exact partition layout, because I didn't
ask for that either, but AFAICS you have at least this:

- /boot is somewhere on sda, I suppose sda1.
- sda5 is an extended partition.
- sda5 is encrypted using dm-crypt and LUKS. The decrypted mapping of
  sda5 is called sda5_crypt.
- sda5_crypt is used as physical volume for LVM.
- There is one volume group "laptop" om sda5_crypt which hosts three
  logical volumes:
  - /home
  - /
  - swap

Are there any other partitions besides sda1 und sda5?

> The old disk with the old crypto will be recycled to another machine.

Ok, that makes the whole thing a little bit trickier, because we need to
move /boot and the MBR as well.

> $ pvs
>   PV                     VG          Fmt  Attr PSize   PFree
>   /dev/mapper/sda5_crypt laptop lvm2 a-   465.52g    0

Didn't you say your old disk only has 160GB? Is sda actually the new

Anyway, to get you started, the process is roughly as follows. I am
assuming sda is your old disk and sdb is the new one. If anything isn't
clear, feel free to ask.

Preparation of the new disk:

  - partition it
  - format the boot-fs
  - Initialize dm-crypt
  - Initialize LVM

I assume you know how to do the first two steps. Setting up dm-crypt is
easy, too. If sdb2 is the newly created partition you want to encrypt:

# cryptsetup luksFormat /dev/sdb2

This will ask for a passphrase that is used for encryption. You can then
unlock the encrypted partition like this:

# cryptsetup luksOpen /dev/sdb2 sdb2_decrypted

"sdb2_decrypted" is a name you can choose freely. It plays the same role
as "sda5_crypt" in your current setup. Of course, you need to enter your
passphrase again.

Afterwards you should have a device node /dev/mapper/sdb2_decrypted
which you can treat like any other block device. As you want to use it
for LVM, you need to "format" it first:

# pvcreate /dev/mapper/sdb2_decrypted

Moving data:
  - /boot
  - LVM

/boot is easy, because you just need to copy the data from the old
filesystem to the new one. Again, I am assuming you know how to do that.

In order to cleanly migrate your LVM volumes to the new disk, proceed as

# vgextend laptop /dev/mapper/sdb2_decrypted

This will put your new encrypted partition into the existing volume
group, which, up to now, only containted your old disk. You can now tell
LVM to move everything on sda5_crypt somewhere else:

# pvmove -i 60 /dev/mapper/sda5_crypt

The argument '-i 60' will make pvmove report prograss every 60 seconds.
Beware that this is a very time consuming operation, because pvmove will
move all LVs (including unused space!) to the other disk. Additionally,
all data has to be decrypted when read from the old disk and encrypted
again when written to the new disk.

It might be faster to move the data on filessystem level (using tar,
rsync, cp etc.), but you would have to create a new VG, LVs and adjust a
few config files accordingly. And you would probably need to do that in
single-user mode or using a rescue disc. The nice thing about pvmove is
that your filesystems (including their UUIDs) and device names don't
change at all and that you can use it without rebooting.

Another option to speed things up is might be to resize your filesystems
and LVs before pvmoving. It isn't possible to shrink ext[234]
filesystems when they are mounted, though, so you would have to resort
to a rescue disc again.

After moving the LVs off of sda5_crypt, you can remove the device from
the volume group:

# vgreduce laptop /dev/mapper/sda5_crypt

Please understand that your data is now only retrievable from the new
disk (except for /boot, if you didn't erase it).

  - /etc/fstab
  - /etc/crypttab
  - grub config + MBR

Before rebooting, make sure to tweak your configuration files where
necessary. Create backups of all files you edit.

Your /boot filesystem has been newly created, so you have to change its
UUID in /etc/fstab.  You can use the command blkid to find out the new
UUID. You need to do the same for /etc/crypttab. The mapping name
'sda5_crypt' doesn't matter much in your case, because the system will
find your LVs regardless of the PV's name.

The most critical part is grub configuration. I am assuming you are
using the new grub, as opposed to grub-legacy. You probably need to
tweak its configuration, too, because your /boot's UUID changed. But I
am currently unable to tell you how to do that. I am even unsure whether
grub's root= parameter need the UUID of the root filesystem or of the
/boot filesystem, but you can check that by looking into
/boot/grub/grub.cfg and comparing with the UUIDs from blkid.

Maybe simply running update-grub magically works it out if you change
/etc/fstab and mount your new /boot before running it.

As your last step, run

# grub-install /dev/sdb

Then shutdown, remove the old disk and pray. :) You should definitely
have some kind of rescue disc handy in case you or me forgot something
important. OTOH, you probably can still boot from your old disk if you
leave it intact.

I want to keep my skin looking good but I believe all computers do the
same job.
[Agree]   [Disagree]

Attachment: signature.asc
Description: Digital signature

Reply to: