[dm-crypt] filesystem conversion guidance needed
lxnf98mm at gmail.com
lxnf98mm at gmail.com
Thu Feb 28 17:12:08 CET 2013
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
> 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
> 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.
More information about the dm-crypt