cloned SUSE guest fails to boot

[strauss]

My host is Fedora 12 running VirtualBox 3.2.6 on a HP nc6320 laptop.
I have created the following guests:
Fedora 13, Windows XP and SUSE Enterprise Desktop 11.0.
All work as expected.

I cloned Fedora 13 and Windows XP.
Both these clones work as expected.

I then cloned SUSE Desktop but it fails to boot.
The sequence of actions was:
(1) Clone the image
$ VBoxManage clonehdd SLED11.vdi sled_copy.vdi
(where SLED11.vdi is my working SUSE Desktop image).

(2) In Virtual Media Manager -> Add sled_copy.vdi

(3) In VirtualBox->New create a guest called sled_copy, using the existing disk sled_copy.vdi

(4) Start to boot sled_copy

Symptoms are as follows:
(1) final console message is:
...Could not find /dev/disk/by-id/ata-VBOX_HARDDISK_VBe8460a6a-11422662-part2

(2) /boot does _not_ contain any GRUB information. It contains only a series of scripts (01-devfunctions.sh ...)

(3) Under VirtualBox->Settings->Storage I see
IDE Controller
`-- Empty (DVD/CD drive)
SATA Controller
`-- sled_copy.vdi

This looks wrong.
For the original SLED11.vdi (and also Fedora13 and Windows XP VDIs), the Storage settings show
IDE Controller
`-- SLED11.vdi
`-- Host Drive HL-DT-ST...
and no SATA controller

Summary
The problem seems unique to SUSE (clones of Fedora and XP work)
The symptoms do not exactly match anything I can find in this Forum or in Google

Thanks in advance for any advice or insights on how to fix this.
Thank you for reading this.
leon

[strauss]

OK I found a workaround for the problem (not a clean solution, but see below).
But I am still curious to know why this SUSE clone failed when other clones worked correctly.
Btw the problem is 100% reproducible, i.e. I deleted the SUSE clone and VDI and re-created them.
The same symptoms appeared.
Thanks again

leon

To workaround the problem:
(1) Release the VDI from the registry.
Virtual Media Manager->Release sled_copy.vdi

(2) Reattach sled_copy.vdi as an IDE drive
$ VBox Manage storageattach sled_copy --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /home/strauss/.VirtualBox/HardDisks/sled_copy.vdi

(3) Reboot sled_copy
The failure still occurs but now /dev contains sda1 and sda2 (which did not exist before)

(4) Reboot sled_copy
In the initial bootloader screen, hit [ESC] to enter text mode

(5) Edit the kernel line to change
root=/dev/disk/by-id/...
to
root=/dev/sda2

(6) Enter "b" to continue booting
The SUSE clone booted successfully

(7) Edit /boot/grub/menu.lst
Change the kernel line as in (5) above to make the change permanent.

(8) Reboot to test.
All OK

[claus]

Hi and THANKS for posting!

I ran into a similar problem and noticed that the devices that couldn't be found were similar to what I could find in /dev/disk/by-id/ in another guest. The difference was the "number part" of *VBOX_HARDDISK_VBe8460a6a-11422662-part*. I noticed that they were all links to either /dev/sda1,sda2, or sda3.

My workaround is the same as yours but I think the way I did it is a little simpler . I created a mountpoint and mounted /dev/sda2 (/) there. Then I could edit /mnt/boot/grub/menu.lst and fstab (substituting *part1 with sda1, *part2 with sda2, and *part3 with sda3) using my favorite editor located on /mnt. umount /mnt, stop, start, and everything is fine.

/Claus

[networker1]

hi

I've done what strauss said on my cloned suse 10 on VB 4.0.2 and worked for me.

many thanks.

[Sasquatch]

The cause of this is that when you clone a VDI, it gets a new UUID. This UUID is also reflected on the Guest file system, a new identification is generated because of that. Since some distro's use UUID based mounting instead of device based mounting (it's more secure when device mappings start walking across when more than one HD is used), this will cause the mount to fail. First the UUID is 789 for example. After the clone, it's 897. The bootloader and fstab are looking for a drive/partition with UUID 789 and fail to find it, because it's now 897.

To avoid this, change fstab first to use the device based mounting instead of UUID based detection. Then the bootloader might need a fix. Depending on the version of grub, you can do this in /boot/grub/menu.lst and change the default options where it points to the root file system (or /boot file system). Then update-grup and the rest of the entries are fixed. This will also help with future kernel updates, as grub will be updated as well and if this isn't changed, you're back to the UUID based boot.
Grub2 needs a different fix, but is roughly the same. Check /etc/default/grub for "#GRUB_DISABLE_LINUX_UUID=true" and remove the '#' sign. Then run update-grub.
Reboot the VM and get into the grub menu. Check the boot lines, there should now be device based names, instead of UUIDs there.