[dm-crypt] filesystem conversion guidance needed

lxnf98mm at gmail.com lxnf98mm at gmail.com
Wed Mar 6 15:25:02 CET 2013

Dr. Wagner,

I received a new drive yesterday and followed your prescription
The patient survived and I am the proud owner of a new encrypted raid
This should go into the FAQ or at least a HowTo for Dummies


On Thu, 28 Feb 2013, Arno Wagner wrote:

> On Thu, Feb 28, 2013 at 09:01:29AM -0600, lxnf98mm at gmail.com wrote:
>> I have successfully used the procedure you describe several times to
>> convert to raid but never an encrypted partition
>> When you say "2. Copy the data over." what am I copying
> I realize my explanation was a bit low on detailand ambiguous.
> You still copy the files, not the encrypted device or the
> filesystem. Copying anything binarily could cause numerous
> problems that can be avoided by copying data on file-level.
> The layering is like this
> Filesystem
> |
> Encryption
> |
> RAID          <-- This layer gets inserted in the stack
> |
> Raw partitions
> |
> Raw disks
> Hence the RAID does see the raw encrypted partitions
> and mirrors them.
>> Normally I would
>> cd old_filesystem; tar cf - . |(cd new_filesystem; tar xf -)
>> But that would just copy unencrypted data
>> Would you explain a bit more
> Say you have / on /dev/mapper/root_part decrypted from
> /dev/sda3 and your new disk is /dev/sdb. Yiour target md device is
> /dev/md3 (avoid name collisions, you specify the number of the md
> device and it is persistent). Then you would
> do somethign like below. You can do this from the running old
> system with a few extra things, see below:
> 1. Make a partition of smaller or exactly size in /dev/ sdb,
>   e.g. /dev/sdb3, give it type fb if you want kernel-level
>   auto-detection. I highly recommend doing this.
> 2. Make a new RAID1 on top of /dev/sdb3, using something
>   like this
>     mdadm --create -n 2 -l 1 --superblock0.90 /dev/md3 /dev/sdb3 missing
> 3. Make a new LUKS filesystem in top of md3 and map it to,
>   say /dev/mapper/new_root
> 4. Create filesystem on new_root and mount it.
> 5. Copy root over with tar, just as you describe.
>   If this is from the live installation, do not forget
>   --one-file-system or you will get a full system copy
>   including a memory image from /proc on the new raid partition.
> 6. If this is with udev and you copy using the installed system,
>   make sure to manually create console and null in /dev/ on
>   new_root, as it will otherwise not boot:
>      cd /dev/mapper/new_root/dev
>      mknod -m 660 console c 5 1
>      mknod -m 660 null c 1 3
> Now you have a copy of your system. Try to boot it by
> your usual mechanism, just with /dev/md3 instead of /dev/sda3
> as root and with the new LUKS passphrase, unless you use the same
> as before (not a security risk increase in this situation).
> So far, you have niot changed anything on the old drive.
> If you still do not have a full backuck, at the very least
> make one now.
> 7. From the new running system, change the type of the old
>   partitions to fb for auto-detection.
> 8. Sync them into the new md partitons like this:
>      mdadm --add /dev/md3 /dev/sda3
>   Here, all your old data will be overwritten. If the new
>   partition is smaller, you may also want to zero the old
>   one before this step, though killing the LUKS header
>   makes that redundant.
> 9. boot again and make sure the raid device comes up in a non-degraded
>   state.
> Done. Repeat for data partition at your laisure.
> Note that the scripts handling the encryption on boot
> see as only difference that it is now /dev/md<x> instead
> of /dev/sda<y>, that represents the encrypted partitions.
> Also note that you can check the state of a raid device and
> sync progress with a simple "cat /proc/mdstat". Before
> step 8, /dev/md3 will just lost one disk as present,
> after step 8, it should list both.
> Arno


More information about the dm-crypt mailing list