Failed Disk Cloning - Linux LVM won't boot

I’m trying to clone my old 500GB hdd to replace it with a new 2TB one. My system is dual-booting Windows 10 and openSUSE 42.1 and has a GPT partition-table. The openSUSE is inside an encrypted LVM partition.

I have tried two methods to clone my entire hard-disk from inside a live-cd:

dd

and

clonezilla

. Using both methods, I’ve been able to successfully boot into Windows, but openSUSE won’t boot, complaining that

/dev/mapper/system-swap

,

/dev/sda/root

and

/dev/sda/swap

do not exist.

Is this problem resolvable or should I consider a fresh install of openSUSE?

Thank you.

It should be resolvable. First thing that comes to my mind is to chroot into the copy and re-install the bootloader and recreate the initrd.

For further discussion, do you use btrfs as root filesystem?

Greetings,
Bequimão

I use ext4 both for root and home.

I would appreciate it if you could expand on the process of chrooting, re-installing bootloader and recreating initrd.

Thank you.

I have to correct the paths mentioned in the openSUSE boot error. It actually says the following paths do not exist:

/dev/mapper/system-swap
/dev/system/root
/dev/system/swap

Start by checking if you can access the LVM.

Boot to rescue media. Then use something like:

# cryptsetup luksOpen /dev/sdaN cr_lvm

(replace “/dev/sdaN” for the appropriate device for your LVM partition).
You should be prompted for the encryption key.

Assuming that works, then:

# vgchange -a y

That should make your LVM volumes accessible. Then check that with:

ls /dev/mapper

Maybe report about how that goes, and then we can suggest the next step.

Done.
Just in case, I got the following warning after running vgachange -a y:

WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

And running ls /dev/mapper resulted in:

control cr_lvm system-home system-root system-swap

Okay. Then you are in pretty good shape. At least the LVM looks to be intact.

Now repeat those steps. But first make sure that your rescue media is the correct architecture - this typically means 32-bit or 64-bit. In order to rescue, you have to boot from rescue media of the same architecture.

Unlock the LVM as before.

Then mount the root volume. That should be:

# mount /dev/mapper/system-root /mnt

Hmm. I hope you are not using “btrfs”. Because, if you are, you then need to mount the various subvolumes.

If you have a separate “/boot” partition, mount that at “/mnt/boot”.

You should probably also mount “/dev/mapper/system-home” at “/mnt/home”.

If this is a UEFI box, then mount your EFI partition at “/mnt/boot/efi”.

Next step: Look at “/mnt/etc/crypttab”. It might have the wrong device-id for your encrypted partition. You will need to fix that.

Hmm, you unlocked the encryted partition using the symbolic name “cr_lvm” (if you followed my suggestions). Maybe it’s a good idea for consistency, to use that in “/mnt/etc/crypttab”. That’s the first item on that line.

When you think you have all of that setup, then use the following:


# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys
# mount --bind /proc /mnt/proc

Next, do:

# chroot /mnt

That puts you logically inside your mounted system.

Then do:


# mkinitrd   ### remake the initrd
# grub2-mkconfig -o /boot/grub2/grub.cfg

It is possible that you might need to reinstall grub while in that chroot shell. But try it without. So just exit from the chroot environment, then reboot and see if your system now boots properly.

Thanks a great deal. It went smoothly until the very last steps.

While executing mkinitrd, there were some errors mostly about dracut module ‘fcoe-uefi’ and ‘multipath’ could not be installed because some commands could not be found.

More importantly, generating the grub file was a failure. It just repeated a warning again and again:

/run/lvm/lvmetad.socket: connect failed: no such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
/usr/bin/grub2-editenv: error: can't mount encrypted volume `/dev/sda2`: Cipher aes isn't available.
Generating grub configuration file ...
\code]
And then similar warnings repeat until the end. 

I have to add that I'm using ext4 (not btrf) inside the lvm. Also, secure boot is enabled on my system. My setup is like this:

/dev/sda1   EFI boot
/dev/sda2   Linux LVM (openSUSE)
/dev/sda3   Microsoft Reserved
/dev/sda4   NTFS (Windows 10)

I’m pretty sure that you can ignore those.

More importantly, generating the grub file was a failure. It just repeated a warning again and again:

/run/lvm/lvmetad.socket: connect failed: no such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

It should be okay to ignore those, too.

/usr/bin/grub2-editenv: error: can't mount encrypted volume `/dev/sda2`: Cipher aes isn't available.
Generating grub configuration file ...

And then similar warnings repeat until the end.

I’m not sure about that.

I guess you are not using a separate unencrypted “/boot”.

Check “/etc/default/grub” (that will be “/mnt/etc/default/grub” for the rescue system, with the indicated mounts).

It should contain the line:

GRUB_ENABLE_CRYPTODISK=n

If that’s there, you might need to reinstall grub. I think the cloning reinstalls grub, but it might not have reinstalled properly for the way that you are using it.

In the “chroot” mode shell, try:


# grub2-install --target=x86_64-efi
# shim-install

and then repeat the “grub2-mkconfig” command as previously indicated.

I think you’re right; I’m not using a separate unencrypted /boot. Also GRUB_ENABLE_CRYPTODISK is set to yes. So, what should I do now? Should I proceed with reinstalling grub?

No, it should contain GRUB_ENABLE_CRYPTODISK=y in this case. This is required if /boot/grub2 is on encrypted disk.

Oops. You’re right. I copied that, and forgot to change the “n” to “y” before posting.

There is one place where grub2-mkconfig calls grub2-editenv. I do not see how this error can repeat until the end. Please copy and paste exact messages from the beginning till end, including command invocation itself.

That setting is correct. So try reinstalling grub.

The same mounts as before, the same chroot. And then try the indicated “grub2-install” and “shim-install” from the chroot environment. After that, rerun the “grub2-mkconfig” command previously indicated.

Could you show /etc/default/grub from your root?

The problem is resolved! Great thanks to all those who helped me solve the issue, especially nrickert. You people are very kind.

In addition to nrickert instructions, I also had to correct the second item on the /mnt/etc/crypttab, which was the path to the encrypted partition. Also regarding the grub errors, they were all disapeared after I ran “lvmetad” following chrooting and prior to updating the grub.

Now a new question is regarding the new space available due to the hdd upgrade: Is it better (or even possible) to resize the current encrypted lvm or should I create a new encrypted partition and mount it inside the current lvm?

Another thing is, this cloning was done using clonezilla. Now I’m going to wipe my drive and use dd to see whether that will also work (considering the rather strange config: GPT partition-table, dual booting, encrypted lvm, …). I will update the thread for future reference.

Yes, you can resize encrypted container using “cryptsetup resize”. You need to enlarge underlying physical partition before doing it. Then just enlarge PV and LV. Searching for “resize luks” brings up quite a lot of hits.

It is even possible to shrink it …

Okay, I can confirm that cloning using dd works just as well. The only thing is, after cloning using dd, there will be some issues related to GPT table not being placed at the end of the disk (or something like that) and the extra space is not initially available. For that, I just opened gparted and it automatically fixed the problems. I’m pretty sure there must be a simple command-line alternative to fix the partition-table issue.

Again, I would like to thank everyone who kindly helped my solve the problem.