I have tested this with LVM2 devices containing nothing important, it worked for me but you are advised to have current working backups if the data matters to you... you have been warned
In the following example we convert /dev/hda3 to use dm-crypt as the device /dev/mapper/hda3-aes
- Make sure you have compiled the kernel the right way
- Cryptographic options -> corresponding cipher
- Device Drivers -> Multi-device support (RAID and LVM) -> Device mapper support -> Crypt target support
- Make sure you have the device-mapper package installed
- Unmount the device to be converted: umount /dev/hda3
- Reduce the size of the partition (e.g. resize2fs /dev/hda3 8GB), to leave some free space (at least a few MBs) near the end.
- Optional: fsck the device (to be sure there are no errors to start with): fsck /dev/hda3
- Setup the new dm-crypt device: cryptsetup -y -c aes -s 256 create hda3-aes /dev/hda3 (enter the passphrase twice)
- Start up the convertion process: dd if=/dev/hda3 of=/dev/mapper/hda3-aes bs=4k
- Check the command twice as this will overwrite the contents of devices involved
__Warning: Interrupting this process will leave your device in an unusuable state.
Large devices should only be encrypted on systems equipped with a UPS. Additionally the process should be executed in a detached terminal via GNU Screen (eg. screen -L -d -m dd if=/dev/hda3 of=/dev/mapper/hda3-aes bs=4k). Further, some mechanism for logging should be used to monitor the last block written to the device.
iostat is an excellent utility for this. The following script can be used:
#crypt_logger
#!/bin/sh
iostat dm-0 > encryption_log
cat encryption_log
- Change the permissions on the script: chmod u+x crypt_logger
- Start the logging process: screen -d -m watch -n 1 ./crypt_logger
- If the process is aborted it is important to know the last block that was well written essay writing, in order to continue/reverse the process. In the event of a power failure the log file can be several seconds behind the actual encryption process. The process should be restarted at the next block, however it should be understood that several blocks will be encrypted twice, making them unusable. This method at least limits the damage of a power failure to a few seconds of encryption, as oppose to a catastrophic failure of the entire drive.
- This could take some time. My test conversions (2Gb) took about 10 minutes on a dual P3 1Ghz. On a 2.6.24-3 kernel and a 1GHz Athlon processor, my system converted a 2TB RAID-5 array at a rate of 50GB/hour (lasting nearly 2 days).
- Once the conversion has finished fsck the new device again: fsck /dev/mapper/hda3-aes
- Mount /dev/mapper/hda3-aes where /dev/hda3 would normally have been mounted: mount /dev/mapper/hda3-aes /mnt/hda3
This can be used in reverse to move a device from being encrypted to be plain.
In addition you can use this with 2 different mappings to re-encrypt the device with either a new passphrase or with different options including cipher and key size, for detailed instructions see
ChangePasswordtexttext
Help = Ajuda