0

Plan:

  1. Use dd to clone running system onto spare hard disc.
  2. Put spare hard disc in spare machine.
  3. Switch to using spare machine
  4. Rebuild system and migrate serivces back.

So I cloned the disc with

# dd if=/dev/sda of=dev/sdc status=progress

However, my spare machine will not boot from the disc complaining that

error : directory is encrypted

There is absolutely no reason to encrypt anything; how can be disabled so that it works?

Welcome to GRUB! error : directory is encrypted.

Richard Barraclough
  • 493
  • 2
    Cloning a running system with dd does not create a valid, consistent backup. You should instead boot a live system and create the image from there. – Panki May 05 '23 at 11:23
  • When you boot your rescue/"live" environment to clone the disk don't use dd. Instead use pv - for example instead of dd if=/dev/sda of=/dev/sdc use pv /dev/sda >/dev/sdc. Replace pv with cat if you don't have pv installed – Chris Davies May 05 '23 at 11:55

1 Answers1

4

What went wrong

Use dd to clone running system onto spare hard disc.

As has been mentioned in comments, you can't use dd or anything similar to clone a running system! The contents of the disk are changing while the system is running, so the copy gets inconsistent content and is corrupted. Your copy is unusable, you need to make a correct one.

By the way, this is not the fault of dd. dd has many faults but here cat or pv or any would not have worked any better. The problem is that the source that the tools copy from is not in a consistent state.

It seems the corruption affected an area that Grub looks at, and the developers of Grub thought that if the software saw unrecognizable data at this point, the most likely explanation was that someone was trying to use an encrypted disk without proper support or without having the correct decryption key available. But that's not the explanation in your case.

How to do the copy

You can use cat (or pv if you want a progress display) to copy partitions or a whole disk as long as they're only mounted read-only, or not mounted at all.

If your system is on LVM, you can leverage LVM to clone it onto another drive, even from a live system. The general process is:

  1. Take a snapshot of your current LVM logical volume(s) using lvcreate --snapshot. This requires spare capacity on the disk; you may want to temporarily create a physical volume on the new disk for that purpose and add it to your current volume group.
  2. Set up LVM physical volume(s), a volume group and logical volume(s) on the new drive, with logical volume(s) that are the same size(s) as what you currently have.
  3. Use cat (or pv or whatever) to copy the snapshot to the new logical volume. Repeat for each logical volume. Once you've copied a logical volume, you can remove its snapshot to save space.
  4. Mount the new system and update /etc/fstab to the UUIDs on the new disk, if applicable.
  5. This process only the contents of LVM partitions, so you need to copy the rest. Install the bootloader on the new drive (the details depend on exactly how Grub is set up). Also copy /boot separately if it's on a non-LVM partition.

There might well be tools that automate this process, but I don't know of one offhand.

See also Moving Linux install to a new computer and https://askubuntu.com/questions/25633/how-to-migrate-user-settings-and-data-to-new-machine/5025#5025 (but beware that they might be a bit dated).

Gilles 'SO- stop being evil'
  • 829,060
  • I wasn't suggesting cat or pv could have copied a live system any better than dd - as you say in this good answer none of them can do the impossible – Chris Davies May 05 '23 at 12:59