5

So I just cloned a Centos7 "everything install" VM to a physical disk using VMWare Workstation and Clonezilla using the instructions here:
https://www.howtoforge.com/converting-a-vmware-image-to-a-physical-machine-p2

Now, when the clone (physical disk) boots up, it drops into the command line with this:

dracut-initqueue[417]: Warning: Could not boot. dracut-initqueue[417]:
Warning: /dev/disk/by-uuid/4b8b5627-9027-46f7-b722-61d3ddd28e74 does
not exist Starting dracut emergency shell...

What I've tried:

  • I checked /etc/fstab and the proper UUIDs are there, including the one above.
  • Tried booting into USB rescue mode, chroot /mnt/sysimage , and:

    mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-oh_crud.img 
    

    and then

    dracut /boot/initramfs-$(uname -r).img $(uname -r) 
    

    ...but I get this:

    cat: write error: Broken pipe

Additional notes:

  • When I enter:

    blkid
    

    I see the HD in question showing up as both /dev/block and /dev/sdb`

  • I tried:

    lshw -class disk
    

    but it says "command not found".

  • The rescue shell is mounting my disk in /mnt/sysimage and all my files are there, so it appears it is seeing and mounting the HD.

9
  • mikeserv- I don't understand. The UUID for the disk shown by "blkid" matches what is in /etc/fstab. What do you suggest I change the UUID to? – Are Vee Feb 9 '15 at 16:41
  • mikeserv- the source disk (the disk that was cloned) is a VM and does not exist on this machine, so why would there be a UUID conflict? – Are Vee Feb 9 '15 at 16:46
  • mikeserv- gotchya. BIOS on both. – Are Vee Feb 9 '15 at 17:15
  • Well, I'm out of ideas. Sorry. The best suggesttion I can make is rebuilding initramfs on the baremetal clone with dracut. – mikeserv Feb 9 '15 at 17:21
  • 2
    I would guess you actually are missing a kernel module, so the hardware isn't showing. Do you have any disks showing up in your rescue shell? Are there any other error messages, further up? – derobert Feb 9 '15 at 17:54
1

I had a similar issue and found that running uname -r didn't return the correct kernel version under rescue mode that I was using normally.

I had to check what initramfs file grub was trying to boot from by pressing e at the grub boot screen and then once in rescue mode do something like this -

cd /boot
initramfs -f initramfs-3.10.0-327.4.4.el7.x86_64.img 3.10.0-327.4.4.el7.x86_64

uname -r in my case was just returning "3.10.0-327.el7.x86_64" which wasn't the kernel version I was trying to load from grub (3.10.0-327.4.4).

I wonder if your lack of the -f switch or a mismatch of the kernel versions used by rescue mode and normal mode may be your issue here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.