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/convertin...cal-machine-p2

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

What I've tried:
1. I checked /etc/fstab and the proper UUIDs are there, including the one above.
2. Tried booting via USB stick installer into rescue mode, chroot /mnt/sysimage , and:

and then
...but I get this:

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". Finally, the rescue shell says it is mounting my disk in /mnt/sysimage and all my files are where they should be, so it appears it is seeing and mounting the HD.

Any suggestions? I am a n00b, so going off a lot of google and not a lot of understanding here.

The problem is in the fstab file in the initrd (yeah, stupid to be there).

I had the same problem - but fixed it by using the rescue boot and adding the real root.

Once the system was up I could make any fixes needed to the fstab in the real root, then rebuild the initrd for boot. Personally, I prefer the complete system rather than what Fedora thinks of as a "custom" build. The complete initrd is larger, but it is also portable to any system with the standard drivers, which the custom initrd is not.

I used "dracut -N" which will overwrite the default initrd. In my slightly more cautious momements i added a special version name for testing. Then check that the grub configuration file contains the proper references... (I'm still using grub legacy simply because it is simpler... and happens to date back to Fedora 14)

1 members found this post helpful.

jpollard- I'm afraid your post in just beyond my comprehension level (again, I'm somewhat of a n00b).

My interpretation of your recommendation is to:
- Modify fstab in the initrd
- dracut -N /boot/initramfs-$(uname -r).img $(uname -r)
- Check /etc/grub.conf

Some questions:
1. How do I find the path to the fstab in the initrd?
2. What do I do to the fstab in the initrd? Just make sure the correct UUIDs are present?
3. You say you "fixed it by using the rescue boot and adding the real root". What does this mean?
4. What am I checking in grub.conf?

Thanks for your help!

Update:
> sudo dracut -N /boot/initramfs-$(uname -r).img $(uname -r)
cat: write error: Broken pipe

not in the initrd - using the following should replace the initrd.
Some background on how the system actually boots:

1. the kernel and the initrd file are copied into memory.
2. when the kernel starts executing it transfers the initrd to a ramdisk in memory, and uses it as root
3. The real root is mounted on /mnt (as defined by the ramdisk) - then uses a kernel call to switch mountpoints - the ramdisk mount is exchanged for the real root
4. the /mnt mount (now the ramdisk) is dismounted, releasing the memory allocated
5. and the system continues the boot.
Dracut is supposed to copy the relevant mounts (usually the swap, but even the root could be copied)
during the creation of the initrd.
The rescue boot has an initrd that contains a more generic set of drivers, and a generic fstab that is focused on system initialization. Using this with the "root=" option usually works to recover a system into an operational state.
Since you are using 6.5, the /boot/grub/grub.conf contains an entry for each available kernel+initrd that can be used for booting the system. All you are doing is verifying that the new entry (if you did create a new entry) is present. If you replaced an initrd, then there is really nothing to do. (oops sorry, Centos 7, but the new entry should be in the configuration files in /etc/grub2.cfg)
No problem. I just moved a VM image of fedora 21 that I had checked out - and had the graphics quit. It turns out that during installation, dracut created a "host only" initrd, so the resulting boot on real hardware didn't work (the video driver wasn't included). I used the recovery boot (though I did have to manually enter it, as the newer systems use grub2) which did work, and specified the root= option to run the system on new hardware.

Since I prefer migratable boots (including the possibility of replacing video cards...) I used the -N option (same as --nohost-only) to build an initrd with all the drivers.

1 members found this post helpful.

I think you tickled a bug in dracut for 6.5 - it is supposed to be fixed in an update to 6.5 so you might try doing an update first.

I think you tickled a bug in dracut for 6.5 - it is supposed to be fixed in an update to 6.5 so you might try doing an update first. (I also see it reported for CentOS 7, so it may exist for both).

http://bugs.centos.org/view.php?id=7443

sorry for the double post.

jpollard- thank you for the detailed response- it definitely gives me a better understanding of the boot process. Greatly appreciated!

I do have a few more questions:

1. I'm not familiar with the "root=" option. Are you suggesting that I modify /etc/fstab on the rescue USB by adding the line:
"root=/dev/sdb1"
(this is the boot partition of my physical HD)?

2. Are you referring to a new grub entry on the USB rescue, or on the physical HD in question? How is this new entry created, and what exactly should it contain (if I have to type it in manually)?

3. How do I update dracut on my USB rescue device?

Sorry for the n00b questions, just need to clarify some things before I get started.

The way I would try is to select the rescue entry and edit the boot line by adding "root=UUID=<uid of root disk>" or "root=LABEL=<name>".

Once the system is booted you should be able to use "yum update".

Alternatively, once the rescue system is booted, you can then mount the real root on /mnt, then use "chroot /mnt" as root.

The network should be up and usable at that point, and you ought to be able to use "yum update".

jpollard- Is this on the USB rescue drive or my physical HD? Am I editing my grub2.cfg or my fstab?
I tried adding this to the fstab on my rescue USB, but it doesn't appear to do anything, and this modification is deleted upon reboot.

So the system will be booting from the USB rescue initially, and then I when select "rescue a Centos install", it will boot from my HD because of the modifications above?

I can do this, but dracut is not working.

After I've booted in rescue mode and chroot /mnt , the network is not useable.

Sorry for all the confusion.

I was expecting the rescue mode to have the net - if not, you have to initialize it so that you can download the update. It is possible I'm overlooking something.

jpollard- gotchya. Would you mind clarifying the following...

Is this on the USB rescue drive or my physical HD? Am I editing my grub2.cfg or my fstab?
I tried adding this to the fstab on my rescue USB, but it doesn't appear to do anything, and this modification is deleted upon reboot.

So the system will be booting from the USB rescue initially, and then I when select "rescue a Centos install", it will boot from my HD because of the modifications above?

This would be when grub presents a selection menu at boot time. There is no need to change any of the menu entries permanently.
The kernel and initrd will come from the USB - but once they are loaded it is being directed to use the root specified by "root=..." to finish the boot. By default what the rescue boot uses would be the root specified for the USB based root. But this is being overridden by what is actually on the boot command line (which you edited at the menu prompt - I think it still uses "e" to invoke a simple editor for that purpose). This is to modify the kernel parameters for this one boot only. No changes are saved.

The complete grub2 boot manual:
http://www.gnu.org/software/grub/manual/grub.html

Check the section "12.3 Editing a menu entry" for doing so when grub2 is started.

1 members found this post helpful.

jpollard- I must be missing something very basic here. When I boot from the USB, my options are:

- Install Centos7
- Troubleshooting:
- Rescue a Centos7 Install
- Boot from local disk

I do not see the grub menu anywhere in the installer/rescue USB boot process, nor when I select "Rescue a Centos Install" or "Boot from local disk".

I do get the grub menu when I boot from my physical HD (the one that's the source of all my problems), so I will try your advice from there. Please advise on what I'm missing here, though.

When you select "Rescue a Centos7 Install" you can then use the built in grub editor (I believe it is invoked with an escape character) to modify kernel parameters, and direct it to use your real root rather than the rescue root on the USB drive.