Using dd to restore root installation to encrypted partition

ArchieGolightly · 2013-10-22 14:17:47

I was having problems installing Arch on a netbook with encryption, thus I had the bright idea to create a copy of my entire disk using dd and then creating an encrypted partition using luks to which I would restore the previous successful installation and modified grub.

Will this actually work, or will dd overwrite the encrypted bits? Is there a better way that anyone can suggest?

On OS X I know you can encrypt your system after it's been installed using filevault 2. Is there a similar program on Linux that I might be able to use in case this fails?

Thanks for any help

tomk · 2013-10-22 14:20:38

The better way is to use cp or rsync, not dd.

ArchieGolightly · 2013-10-22 14:26:45

Would cp copy hidden files and folders also? That's the main reason I went with dd and I wasn't aware of the existence of rsync.

alphaniner · 2013-10-22 14:33:07

I *think* dd'ing an image of an unencrypted partition to a LUKS device could work. But I have no idea if this is good practice from a cryptography perspective. Anyway, in most cases using dd like this is silly: unless your fs is [nearly] full you will be reading and writing a whole lot of nothing. I'd recommend a fs level utility. Fsarchiver is a good "imaging" utility, or you could just use tar/rsycn/etc.

Also, keep in mind that the restored installation will not be immediately bootable unless you plan ahead. At the very least you'll need an initramfs configured for encryption.

Last edited by alphaniner (2013-10-22 14:44:36)

WonderWoofy · 2013-10-22 14:36:44

cp -a would proabbly do what you want, but I think that it doesn't copy some of the extended attributes. When I want to back up my system I use "rsync -aAXv" to do it. That will copy everything over while preserving all the things.

The problem with dd and an encrypted system is that dd is a tool that works on the layer below the encryption itself. So think of the disk setup as being in three layers, with the disk/bits being the bottom, the encryption being the middle, and the actual files being the top. If you use cp, rsync, tar, etc. you will be working on the top layer. That is, the files will seem to the OS as unencrypted normal files. So copying them from one place to another will yeild the same result. If you use dd, it works directly with the disk and copies things over exactly as it is written. So you are copying over already encrypted (seemingly) junk.

If you are trying to make a new disk with encryption and everything, you could dd over the old disk. But then you would result in the same partitioning layout, encryption key, etc, etc. and I think that at least part of the idea of moving things from disk to disk would be to possibly change some things.

A more sane route would be to boot into an archiso or other live media. Set up your encryption, partitions, lvm2, or whatever it is you are going to do. Mount the new, decrypted rootfs and create the other mount points, and of course mount the rest of your partitions (if any). Then attach and decrypt the old system and mount it somehwhere else. So for example, if you were to mount the old disk at /old and the new disk at /new, you would do:

# rsync -aAXv /old/* /new

ArchieGolightly · 2013-10-23 14:50:34

WonderWoofy wrote:

The problem with dd and an encrypted system is that dd is a tool that works on the layer below the encryption itself. So think of the disk setup as being in three layers, with the disk/bits being the bottom, the encryption being the middle, and the actual files being the top. If you use cp, rsync, tar, etc. you will be working on the top layer. That is, the files will seem to the OS as unencrypted normal files. So copying them from one place to another will yeild the same result. If you use dd, it works directly with the disk and copies things over exactly as it is written. So you are copying over already encrypted (seemingly) junk.
A more sane route would be to boot into an archiso or other live media. Set up your encryption, partitions, lvm2, or whatever it is you are going to do. Mount the new, decrypted rootfs and create the other mount points, and of course mount the rest of your partitions (if any). Then attach and decrypt the old system and mount it somehwhere else. So for example, if you were to mount the old disk at /old and the new disk at /new, you would do:
# rsync -aAXv /old/* /new

Thanks, that's what I wanted to know (about dd copying the bits below the files as you put it). Unfortunately, after using rsync and successfully copying everything onto an external HDD and creating a new encrypted partition at /dev/mapped/root I was unable to "copy and paste" a working install into an encrypted disk.

The first error I encountered, when I tried chroot, was that resolv.conf was missing, and it pretty much went downhill from there. Whilst I was able to get everything back to where it belonged, I seemed to have overwritten the configuration files for openbox but I got arch to boot just fine with GRUB from the encrypted folder.

Maybe I'll try it again with cp -a instead, or perhaps some other flags. I think getting the permissions correct and copying hidden files and directories is crucial tho. I'm unsure why resolv.conf wasn't copied over with rsync tho.

Thanks again for all of your replies.

greenfish · 2013-10-23 16:02:23

ArchieGolightly wrote:

WonderWoofy wrote:
The problem with dd and an encrypted system is that dd is a tool that works on the layer below the encryption itself. So think of the disk setup as being in three layers, with the disk/bits being the bottom, the encryption being the middle, and the actual files being the top. If you use cp, rsync, tar, etc. you will be working on the top layer. That is, the files will seem to the OS as unencrypted normal files. So copying them from one place to another will yeild the same result. If you use dd, it works directly with the disk and copies things over exactly as it is written. So you are copying over already encrypted (seemingly) junk.
A more sane route would be to boot into an archiso or other live media. Set up your encryption, partitions, lvm2, or whatever it is you are going to do. Mount the new, decrypted rootfs and create the other mount points, and of course mount the rest of your partitions (if any). Then attach and decrypt the old system and mount it somehwhere else. So for example, if you were to mount the old disk at /old and the new disk at /new, you would do:
# rsync -aAXv /old/* /new
Thanks, that's what I wanted to know (about dd copying the bits below the files as you put it). Unfortunately, after using rsync and successfully copying everything onto an external HDD and creating a new encrypted partition at /dev/mapped/root I was unable to "copy and paste" a working install into an encrypted disk.
The first error I encountered, when I tried chroot, was that resolv.conf was missing, and it pretty much went downhill from there. Whilst I was able to get everything back to where it belonged, I seemed to have overwritten the configuration files for openbox but I got arch to boot just fine with GRUB from the encrypted folder.
Maybe I'll try it again with cp -a instead, or perhaps some other flags. I think getting the permissions correct and copying hidden files and directories is crucial tho. I'm unsure why resolv.conf wasn't copied over with rsync tho.
Thanks again for all of your replies.

After using cp, dd and other routes, I find rsync to be the best option.

If you check the log after the transfer rsync should state the reason why resolv wasn't copied?

I noticed you used the archive flag, but no -p "preserve"?

WonderWoofy · 2013-10-23 17:03:08

greenfish wrote:

I noticed you used the archive flag, but no -p "preserve"?

I don't know if this was directed at me or the OP, but...

rsync --help wrote:

-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)

and

cp --help wrote:

-a, --archive same as -dR --preserve=all

Arch Linux

#1 2013-10-22 14:17:47

Using dd to restore root installation to encrypted partition

#2 2013-10-22 14:20:38

Re: Using dd to restore root installation to encrypted partition

#3 2013-10-22 14:26:45

Re: Using dd to restore root installation to encrypted partition

#4 2013-10-22 14:33:07

Re: Using dd to restore root installation to encrypted partition

#5 2013-10-22 14:36:44

Re: Using dd to restore root installation to encrypted partition

#6 2013-10-23 14:50:34

Re: Using dd to restore root installation to encrypted partition

#7 2013-10-23 16:02:23

Re: Using dd to restore root installation to encrypted partition

#8 2013-10-23 17:03:08

Re: Using dd to restore root installation to encrypted partition

Board footer