CentOS7 Fails to Boot After Successful Restore

[notthedude]

First, thank you so much for making this product. Between this and the Windows version, you've made me a huge vocal Veeam supporter.

Full logs here: https://drive.google.com/open?id=0Byq81 ... Fc3RFRmZUE
CentOS Version: centos-release-7-2.1511.el7.centos.2.10.x86_64
Kernel: Linux 3.10.0-327.18.2.el7.x86_64

Environment Details:
CentOS7 is a guest VM called CentOS7-WS running on Windows 2012 R2 Hyper-V.

Scenario:
I successfully installed veeamsnap-1.0.0.499-1.noarch.rpm and veeam-1.0.0.499-1.el6.x86_64.rpm on CentOS7-WS. The only hiccup was regarding kernel-headers. Running "yum install kernel-headers kerenel-devel" indicated that they were already installed, but the veeamsnap installer didn't recognize them. I was able to get the veeamsnap installer to recognize the kernel-header package(s) by running the following yum command to ensure the header package for the exact kernel version was installed:
yum install "kernel-devel-uname-r == $(uname -r)"

I performed an "Entire Machine" backup to my CIFS share. That was successful.

Next, I turned off the VM, and swapped the original 64GB .vhdx with brand new blank 64GB .vhdx. I booted to the Veeam Recovery Media supplied with the Linux Beta software and manually recreated the partition table as it appeared in the backup file. See screenshot below:

(NOTE: It says "CURRENT SYSTEM" on the left-hand pane because I had to grab this screenshot after a rebooted post-restore. But the tree looked exactly the same after I manually recreated the partitions using the Veeam Recovery Media.)



Then, I began the restore operation. During restore, Veeam very clearly worked on restoring sda1, sda2, and sda3's root, swap, and home volumes. Afterwords it said that the restore was successful.

But then...the VM wouldn't boot (sat on flashing cursor). I swapped the original .vhdx back in just to rule out Hyper-V weirdness, and the VM booted without a problem.

This is a tough one because everything said it was successful, but then the CentOS7 VM didn't boot.

Thanks so much for your time on helping to diagnose! And thanks for making great products!

[notthedude]

So it seems that the boot partitions didn't restore properly, I think. I'm not sure why though. I PXE-booted to CoreOS to check it out further. Screenshot below. Hopefully this helps somewhat...

[PTide]

Hi,

Could you please create another brand new .vhdx and perform the following steps:

1. Choose sda and pick "restore whole disk from..." and pick sda from the backup.
2. Choose sda3 and pick "create LVM physical volume" and enter exactly the same VG name that you used in your system
3. Choose free space in the newly created VG and pick "restore volume from ..." and choose swap. Do the same for all other logical volumes that reside in the VG. Start restoration process.

That sequence of steps has been proved working, so please share the results with us.

Thank you!

[notthedude]

Unfortunately, I followed the steps above, with the same result (unable to boot). However, I think you might be onto something with the entering "exactly the same VG name" that I used on my original system.

On my original system. lsblk shows the VG name as:
centos_centos7--18583

...and the Veeam Backup shows it as centos_centos7—18583 (NOTE: I'm not sure if I was looking at an en-dash or an em-dash while looking at the backup in the Veeam Recovery Media, but here, I just typed an em-dash)

So, I tried restoring 2 different ways (each time with a new blank .vhdx).
For the first restore, I used a hyphen (i.e. single press the key to the right of "0" on keyboard). This failed to boot after a successful restore.
For the second restore, I used two hyphens (i.e. pressing the key to the right of "0" on keyboard twice). This failed to boot after a successful restore.

I tried keyboard shortcuts for en-dash and em-dash, but they didn't work, so I couldn't test restores using those characters.

That being said, while I agree not having the exact same VG name would cause a problem, I should still see *something* during boot (as opposed to just flashing cursor) when the VM looks at the boot manager on the EFI partition, right?

Thanks again for your help on this.

[PTide]

You're right - it's not because of a typo in VG name. Apparently a bootloader has something to do with the problem. I've just noticed that you have a /boot/efi partition. Your VM is GEN1, is that correct? Also what's partition scheme did you use on the original drive - GPT or MBR? Could you please post the output of fdisk /dev/sda when booted in CoreOS?

Thanks

[notthedude]

I apologize...I left out some details that are pretty relevant.

So, the original VM was GEN2. Since the Veeam Recovery Media won't boot on a GEN2 VM, I created a GEN1 VM and all of the restore operations tool place there. Then I swapped the the .vhdx from the GEN1 machine in for the .vhdx on the GEN2 machine...the assumption being that a hard drive is a hard drive.

I'm sure that this procedure is not and would never be officially supported. So I guess I'd have a feature request to build the Veeam Recovery Media to work with EFI booting?

Thanks for sticking with me on this.

*Edit: Give me a little bit and I'll get the output of "fdisk /dev/sda". Also, to answer your other question, partition table GPT.

[PTide]

So I guess I'd have a feature request to build the Veeam Recovery Media to work with EFI booting?

That's a known bug, but thanks for noticing that!

So, the original VM was GEN2. Since the Veeam Recovery Media won't boot on a GEN2 VM, I created a GEN1 VM and all of the restore operations took place there. Then I swapped the the .vhdx from the GEN1 machine in for the .vhdx on the GEN2 machine...the assumption being that a hard drive is a hard drive is a hard drive.

It seems that your original disk is labeled as GPT and you restored it to another disk and tried to boot that new GPT disks on a BIOS-based system which might require some voodoo. Could you please provide the info I've requested in my previous post so I can confirm/refute my guess?

Thanks!

[notthedude]

So...fdisk/gdisk actually raised more questions that it answered...

Below is a screenshot of fdisk AND gdisk on the original machine (i.e. GEN2 VM running CentOS7)


Here is a screenshot of PXE-booted CoreOS on a GEN1 VM looking at the restored .vhdx using fdisk


Here is a screenshot of PXE-booted CoreOS on a GEN1 VM looking at the restored .vhdx using gdisk

[PTide]

Correct, the restored .vhdx is in GPT fromat thus it won't boot on BIOS (GEN1). Please first try to attach the restored .vhdx to GEN2 VM and see if it will start.

[notthedude]

Sorry if I wasn't clear. That's what I did:

Then I swapped the [restored] .vhdx from the GEN1 machine in for the .vhdx on the GEN2 machine...the assumption being that a hard drive is a hard drive is a hard drive.

The screenshots above were just so that you could compare fdisk/gdisk output from the original .vhdx and the restored .vhdx