Cloned VM fails to boot

English Virtualization
#1

Hi all,

Host Ubuntu 12.043
Guest OpenSUSE 13.1
Oracle VirtualBox

All cloned guests can’t boot

Warning:
Timed out waiting for device dev-disk-by\x2did-ata\x…2dpart1.device.
Dependency failed for /boot
Dependency failed for Local File Systems

Found following 2 threads:
Unable to use cloned VM, OpenSUSE, VirtualBox
linux - Unable to use cloned VM, OpenSUSE, VirtualBox - Super User

Cannot boot OpenSuse 12 after cloning disk due to by-id access to the disk
Digger’s Blog: Cannot boot OpenSuse 12 after cloning disk due to by-id access to the disk

but couldn’t resolve how to fix the problem. Please help

TIA

Rgds
satimis

#2

Your cloned system has different disk configuration. You need to boot from rescue DVD or any live media and fix /etc/fstab to match your actual device paths.

#3

Hi,

Thanks for your advice.

The cloned VM identifies the boot drive with UUID, which changed when the drive was cloned, resulting in unable to boot. I’m now downloading a live KDE image to fix this problem. I’ll change it to boot device instead of UUID. I found similar threads on Internet.

Rgds
satimis

#4

Interesting.
What version of Virtualbox are you running?
(I’ve been running 4.3.4, then updated to 4.3.6)

I haven’t yet run into any issue launching a clone.
The error you’re displaying seems to be a path <within> the Guest, so I doubt that if the clone was created properly (how <are> you creating clones?) the device path should not be an issue.

IMO if you’re using Virtualbox’ own clone utility you shouldn’t be experiencing problems… If you’re doing it some home-grown way, YMMV.
In other words, IMO it’s unlikely for a clone utility to change the device path because there is no reason for a cloning utility to change it… The two major areas of concern typically are the system identifiers and networking.

TSU

#5

Hi,

Thanks for your reply.

VirtualBox version - 4.3.6 download on Oracle VirtualBox website

I have cloned several VMs on OpenSUSE 13.1 including export/import. All VMs thus created failed to boot.

Right click on VM -> clone
creating new MAC address.

Same steps applied on other Linux VM (Debian 7.3/Fedora/Ubuntu12.04/LinuxMint16 etc.) working w/o problem. All cloned VMs are able to boot without any problem.

I also tried on another PC
Host Debian7.3
VBox version 4.3.6

All cloned VMs created on OpenSUSE 13.1 were unable to boot

Edit

For your info, I also subscribe VirtualBox forum. Please refer to following thread;
https://forums.virtualbox.org/viewtopic.php?f=7&t=59371

satimis

#6

Hi all,

Problem solved as follow;

Start the VM with live-kde-opensuse13.1 ISO

Start Terminal

linux@linux:~> su

fdisk -l


Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0002efa7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      819199      408576   83  Linux
/dev/sda2          819200    83886079    41533440   8e  Linux LVM

Mount LVM

pvs


  PV         VG     Fmt  Attr PSize  PFree
  /dev/sda2  system lvm2 a--  39.61g 8.00m

lvdisplay /dev/system


....   
  --- Logical volume ---
  LV Path                /dev/system/root
  LV Name                root
  VG Name                system

mount /dev/system/root /mnt

ls /mnt/


bin   dev  home  lib64       media  opt   root  sbin     srv  tmp  var
boot  etc  lib   lost+found  mnt    proc  run   selinux  sys  usr

cp /mnt/etc/fstab /mnt/etc/fstab.ORIG_20140103

nano /mnt/etc/fstab

change the line;


/dev/disk/by-id/ata-VBOX_HARDDISK_VBef165ce6-8bf1a0de-part1 /boot  ext4  acl,user_xattr 1 2

as;


/dev/sda1 /boot  ext4  acl,user_xattr 1 2

Shutdown the VM and remote the live-kde-opensuse13.1 ISO

Start VM. Now it can boot without problem.

Thanks

Rgds
satimis

#7

Hi all,

To avoid the step mounting the LVM, do as follow;

After booting the Live-CD

Kmenu -> Applications -> System -> File Manager -> File Manager-Super User Mode

Then it can directly edit the “fstab” file there.

Rgds
satimis

#8

You should probably check to see if this entry exists.
Can’t remember for sure but it seems to me that openSUSE boot has been identifying disks “by id” for quite a long time now without a problem.

But of course if the entry is just wrong, then it won’t work.

TSU

#9

On the cloned VM the by-id changed. Therefore it can’t boot.

satimis

#10

On 2014-01-09 23:46, tsu2 wrote:
>
> satimis;2613282 Wrote:
>>
>> /dev/disk/by-id/ata-VBOX_HARDDISK_VBef165ce6-8bf1a0de-part1
>>
>
> You should probably check to see if this entry exists.
> Can’t remember for sure but it seems to me that openSUSE boot has been
> identifying disks “by id” for quite a long time now without a problem.
>
> But of course if the entry is just wrong, then it won’t work.

The problem is that the “by-id” entries depend on the hardware, and the
hardware depends on the host virtualization system, not on the virtual
machine itself. It is like placing a hard disk on a different (same
brand, different model) computer.

Using “by-uuid” or “by-label” would work always.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#11

I’ve checked several cloned openSUSE Guest VMs running on my Virtualbox

As expected (at least to me), the fstab in every clone is an identical replica of the machine it was cloned from. And of course, since the boot method <within> the Guest is completely isolated from the Host Virtualization environment this is completely expected.

So,
I don’t know exactly what happened in the cloning process but if the new clone’s fstab isn’t <exactly> the same as the parent, that’s a real mystery. And, it should work.

The bottom line is disk “by-id” should work just fine. If it worked in the parent, then it should work in the child.

TSU

#12

On 2014-01-13 18:56, tsu2 wrote:
>
> I’ve checked several cloned openSUSE Guest VMs running on my Virtualbox
>
> As expected (at least to me), the fstab in every clone is an identical
> replica of the machine it was cloned from. And of course, since the boot
> method <within> the Guest is completely isolated from the Host
> Virtualization environment this is completely expected.

Right.

> So,
> I don’t know exactly what happened in the cloning process but if the new
> clone’s fstab isn’t <exactly> the same as the parent, that’s a real
> mystery. And, it should work.

Right, the fstab should not change at all.

> The bottom line is disk “by-id” should work just fine. If it worked in
> the parent, then it should work in the child.

Right… but. At least in vmware, the virtual “hardware” can change,
there are versions. The “id” depends directly on the hardware; not the
host hardware, but what the guest sees as hardware.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#13

Interesting if true.
But, I can’t think of a single reason why <anything> in the cloned disk should change, <especially> referencing the disk and partitions. In the first place, AFAIK the seen virtual “hardware” disk shouldn’t change unless you modify the disk controller… then YMMV. But, if the new cloned Guest is using the same disk controller as the Parent I really don’t see the disk id changing.

By the end of today I might find enough time to experiment a little in VMware to verify.

TSU

#14

Curiously, when I inspected my VBox and VMware Guests (both originals and clones), I found
VBox - identified the disks with “by-id” and as expected both parents and clones.
VMware - identified the disks “by-path” as expected both parents and clones.

The same source Install media was used to create the Guests in both virt technologies.
This was true for both installations using default and custom disk/partition layouts.
Although I have found other substantial differences between the “Minimal Server” and Desktop configurations, the choice of disk path or id was not one of them.
The method of disk identification has no effect on running within a technology. So, for instance I can take a Guest built on a vmdk (created in VMware) and run it in VBox without any problem.

So, it does appear at this point that the type of disk identified determines on whether the “hardware” is identifiable, so for instance it seems that a QCOW (my choice in VBox so I can move it to a QEMU or KVM system without conversion) is recognizable as VBox while a vmdk may not be vendor identifiable (although I can’t imagine why).

I’d expect that this should also verify that cloning should <not> ordinarily modify the way a disk/partition is identified in /etc/fstab in a Guest VM and any method described in /dev/disk should probably work.

TSU

TSU

#15

On 2014-01-15 16:16, tsu2 wrote:
> I’d expect that this should also verify that cloning should <not>
> ordinarily modify the way a disk/partition is identified in /etc/fstab
> in a Guest VM and any method described in /dev/disk should probably
> work.

Should not, right.

But in vmware you can change a certain number in the config files (maybe
there is a menu for it in the purchased version) that changes the
hardware of the machine. The virtual chipsets change. If this changes,
then by-paths can change, too. Depends.

If you do that to a Windows guest, you get into the typical nightmare of
unloading some drivers and loading others instead, while versions such
as 7 may say that the license is invalid because you copied the
installation to another computer.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#16

I’ve been working through this issue too, let me summarize what worked for me.

I use VirtualBox to run openSuSE 13.1 and I needed to clone the machine. I wanted its folder self contained and as small as possible for backup purposes. When I used the standard procedure to clone, the resulting machine could not use its hard drives. It turns out there are some changes to make to openSuSE BEFORE cloning that will allow subsequently-generated clones to work.

It was difficult to find all the correct information in one place. Kudos to Ben for having it right and being articulate too. I highly recommend reading his brief piece if you want to understand what’s going on. http://www.gridshore.nl/2013/08/19/cloning-an-opensuse-12-3-virtual-machine-using-grub2-virtualbox-and-cryptfs/

Here’s the recipe.
I have a working VirtualBox with openSuSE 13.1 KDE. I make a snapshot, then do the following editing as root in the live VM. When the changes are made and confirmed I will clone the VM.

To start, run the VirtualBox openSuSE VM you will clone.
Create a snapshot.
Open a terminal as root and issue this command:# ls -l /root/dev/disk/by-id

The results included (for me) these lines with ata-VBOX_HARDDISK in them.lrwxrwxrwx 1 root root 9 Apr 1 18:33 ata-VBOX_HARDDISK_VBad0d9a6d-2d9f483f → …/…/sda
lrwxrwxrwx 1 root root 10 Apr 1 18:33 ata-VBOX_HARDDISK_VBad0d9a6d-2d9f483f-part1 → …/…/sda1

You will know they are the right entries when you edit the text files below and find the same long names there to be replaced.

Based on the above info I will replace long names with short, wherever they occur in several files./dev/disk/by-id/ata-…83f becomes /dev/sda
/dev/disk/by-id/ata-…83f-part1 becomes /dev/sda1

Modify these files using a text editor:/etc/fstab
/boot/grub2/device.map
/boot/grub2/grub.cfg

Make the changes, save the files, and reboot. If it reboots ok then you probably did it right.
Now this VM and its descendents may be cloned and their hard drives will work; this business only has to be done once.

There are two choices you should make when starting the cloning process:Check the option to “Reinitialize the MAC address of all network cards.”
You probably want to end up with one clean folder, so choose a Full clone.

The clone VMs you make after this process “just work”, disks and network and all, just like the clonee. HTH

#17

On 2014-04-02 21:56, kelanger wrote:

> Based on the above info I will replace long names with short, wherever
> they occur in several files.
> /dev/disk/by-id/ata-…83f
> becomes /dev/sda
> /dev/disk/by-id/ata-…83f-part1 becomes /dev/sda1

Please don’t do that.

Those “short names” are not guaranteed persistent.

Instead, use UUID, ID, or LABEL identifiers.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#18

|0:(down votefavorite
|

|Im trying to connect my VM on OpenSuse, but i cant reach it.
My server is ok, it can ping my personal machine just to see if it’s ok, now I mounted my vm’s but i cant ping them neither make a telnet, i dont know why.
Can someone help me with that please? I need to put these machines to run soon urgent.
Firewall is disabled.
please have a look in the image next into this link
http://postimg.org/image/5v0po8l75/

|

#19

Recommend you start a new thread.
This thread is extremely old, and it’s likely that technology changes are so significant nothing that has been said in this thread is likely relevant.

TSU