6

I am migrating a CentOS 7 system from VMware Server 2 to XenServer 6.5. The CentOS system was installed using the minimal installation. I used ovftool to convert the .vmdk file to a .img using the instructions here

https://www.mylesgray.com/virtualisation/using-vmwares-ovftool-convert-vmx-ova/

and imported this into XenServer using XenCenter. Upon booting I get the following errors:

dracut-initqueue[286]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[286]: Warning: /dev/centos/root does not exist
dracut-initqueue[286]: Warning: /dev/centos/swap does not exist
dracut-initqueue[286]: Warning: /dev/mapper/centos-root does not exist

It goes on to start the emergency shell.

I think the problem is down to the device name of the disk. On the original system the disk is on /dev/sda. On the new system it is /dev/xvda. Using the installation disk I can boot into the rescue mode and it mounts /mnt/sysimage. I don't know how to fix the problem though. The only file I can find related to the device name is in /mnt/sysimage/boot/grub2/device.map. I tried changing this to

(hd0)    /dev/xvda

but it made no difference. I presume the logical disk manager configuration needs changing somewhere.

How can I fix this? I need simple(ish) instructions as I'm not a Linux expert, especially in relation to the boot process.

Improve this question

5 Answers 5

Reset to default
4

There was the same question on Reddit.

The main idea — you need to regenerate initrd.

  1. Boot into linux rescue
  2. Call dracut -f according to this article.
Improve this answer
3
  • 1
    Thanks. I will try this next time. I have found reinstalling the kernel using yum fixes the problem but I guess that is just doing what you mention as part of the process.
    – Goose
    Dec 1, 2016 at 23:11
  • That worked great with a little change. As I booted from a rescue disk uname -r returned a different version as to what I had available on the disk to rebuild it. I just had to specify the exact version instead.
    – Goose
    Dec 19, 2016 at 14:50
  • 1
    On CentOS 7 I was able to select CentOS Linux 7 (Core), with Linux 0-rescue-... to boot successfully - then yum update provided me with a newer, working kernel/initrd, presumably accomplishing roughly what dracut -f would have done.
    – mwfearnley
    Jan 4, 2019 at 16:12
6

I've been using Starwinds V2V converter https://www.starwindsoftware.com/converter for a similar task a while ago. It supports multiple virtual machine disks formats and does internal hardware patching during conversion. There is an option to enable Rescue Mode during conversion too and it supports batch processing of multiple VMs. And it's free.

Saved me a lot of time literally. Give it a try.

Improve this answer
2
  • 4
    I tried this software and although it is much more user friendly than the other tools I have tried for conversion, it still results in the same errors on CentOS 7.
    – Goose
    Dec 19, 2016 at 14:45
  • 1
    Tried the latest version of Starwinds V2V, converting Cenos7 from VB vmdk to Hyper-V windows 10, still get some errors.
    – zhihong
    Jun 19, 2020 at 10:40
2

I know that this answer comes in late, but I thought I would share how I got around this. I was also searching for an answer migrating CentOS7 VM's from XenServer 6.5 to Hyper-V 2016. I tried everything from Starwind, to exporting as XVA appliance and converting it using XenConvert 2.3.1, with no avail.

The solution is actually very simple, and worked the first time: Download this ISO - https://sourceforge.net/projects/boot-repair-cd/

High-level steps that I took:
1.) Export XEN VM to OVA (or convert .xva XEN appliance using any tool, like Starwind)
2.) Create NEW VM in Hyper-V and attach previously exported VHD
3.) Mount the ISO from above link in new Hyper-V VM's DVD/CDROM drive, and boot from it.
4.) Follow the prompts (NB!!! Make sure that the VM has a NIC attached that connects to an external network that hands out DHCP and internet access)
5.) Select auto repair (NB!! on the step where it reinstalls GRUB, you might need to modify the yum command, in my case I had to use - "yum erase grub*" instead of "yum erase grub*-common"
6.) Reboot and enjoy your Linux VM running on Hyper-V :)

Improve this answer
1

The reason why you’re seeing this is due of initramfs kernel image being build for the specific system it's running on, so migrating to a new hardware will cause it to fail to boot.

Rebuilding initramfs in emergency mode(or go to the Rescue Mode ):

Then

  1. List the initramfs images you have:

ls -ltrh /boot/initramfs-*

  1. Locate the kernel version you’re using and create a backup of it:

cp -iv /boot/initramfs-3.10.0-1062.el7.x86_64.img /boot/initramfs-3.10.0-1062.el7.x86_64.img.back

  1. Rebuild the kernel image for that specific kernel

dracut -f

  1. Select the new kernel image

ls -ltrh /boot/initramfs-*

  1. Specify the new kernel version (For Example):

dracut -f /boot/initramfs-3.10.0-1062.el7.x86_64.img 3.10.0-1062.el7.x86_64

  1. Go to the Grub config

vim /boot/grub2/grub.cfg

or if it's an UEFI system

vim /boot/efi/EFI/centos/grub.cfg

  1. Delete the old menuentry and make sure that the new menuentry is top of all

  2. Generate a GRUB configuration file

grub-mkconfig

  1. Reboot

  2. Done.

Improve this answer
2
  • dracut initramfs-3.10.0-693.17.1.el7.x86_64.img initramfs-3.10.0-693.17.1.el7.x86_64 Kernel version initramfs-3.10.0-693.17.1.el7.x86_64 has no module directory /lib/modules/initramfs-3.10.0-693.17.1.el7.x86_64 Will not override existing initramfs (/boot/initramfs-3.10.0-693.17.1.el7.x86_64.img) without --force
    – junior ruby developer
    Dec 9, 2020 at 6:17
  • This solution helped in my case. For some reason the grub file was missing. So I skipped steps 6, 7 and 8. I rebooted and it took me to the correct boot screen where I was able to log in. Thank you.
    – Don
    Jan 14, 2022 at 18:48
0

I had lost my boot partition, so no help doing the dracut -f command.

I could, however, boot to rescue kernel, and ran a yum update, which installed a new kernel and fixed whatever it was that caused this.

There is something to be said for not running systems on the bleeding edge!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .