I've cloned a VM and now while booting it I see a message:

Trying manual resume from /dev/sda1
Invoking userspace resume from /dev/sda1
resume: libgcrypt version: 1.5.0
Trying manual resume from /dev/sda1
invoking in-kernel resume from /dev/sda1
Waiting for device /dev/disk/by-id/ata-VBOX_HARDDISK_.....-part2 to appear: ...
Could not find /dev/disk/...-part2
Want me to fall back to /dev/disk/...-part2 (Y/n)

If I press 'Y' it tries to boot again with failure, then exits to /bin/sh. If I press 'n' it exits to /bin/sh immediately.

I've read a solution here: http://diggerpage.blogspot.com/2011/11/cannot-boot-opensuse-12-after-cloning.html but I don't understand how to access files on disk to edit /etc/fstab and /boot/grub/menu.lst?

5 Answers 5


I was able to make my system boot by doing the following:

1) Take note of the device(s) the system cannot find.

2) Answer "n" to that question. It should take you to a command prompt.

3) Run this command: cd /dev/disk/by-id

4) Run this command: ls

5) Rename all files in this folder replacing there current name with the name of the device you took note of in step 1. Ex. mv ata-VBOX_OLDNAME....-part2 ata-VBOX_HARDDISK....-part2

6) Once you have completed this type this command: exit

7) The system should boot normally.

I am still working through how this happens with OpenSUSE 11.4.

  • 1
    Now I'm not facing with this problem and can not check your solution. I accept your answer, hope these steps can help in the case I described. Thank you.
    – ivkremer
    Oct 26, 2012 at 13:53

This problem is caused because SUSE by default configures Grub to find disks by name rather than by label or by path. When creating a VM from an appliance, VirtualBox creates a new disk with a new name and then Grub can't find the boot disk. I was able to fix this permanently by:

  1. Add the disk as a secondary drive to another machine that can mount the filesystem. I mounted mine to /media/hd2.

  2. Edit /media/hd2/boot/grub/device.map and replace the by-name path to the hard drive /dev/disk/by-name/ata-VBOX.... with the by-path path /dev/disk/by-path/pci-0000:00:0d.0-scsi-0:0:0:0.

  3. Edit /media/hd2/boot/grub/menu.lst and replace the by-name paths with the by-path paths. For mine, I ended up replacing all of the part-1 paths with /dev/disk/by-path/pci-0000:00:0d.0-scsi-0:0:0:0-part1 and the part-2 paths with /dev/disk/by-path/pci-0000:00:0d.0-scsi-0:0:0:0-part2.

The paths that I used specify the first hard disk. If you want to boot off a different hard disk (or a different disk type), you will need to figure out how SUSE maps the path. I found that SUSE will mount a second hard drive as pci-0000:00:0d.0-scsi-1:0:0:0.

Specifying the hard drive by-path might not be ideal in some cases, but it worked perfectly for the quick fix I was going for.


I got this error and solved by replacing the old id for the disk with the new one on etc/fstab and on boot/grub/menu.lst

  1. Hit 'n' upon fall back question.
  2. Get new id by running hdparm -i /dev/sda
  3. Rename all disks as expressed on the solution accepted and boot your guest.
  4. Open terminal as root and vi etc/fstab and replace the old ID with the new one wherever it shows. Save and close.
  5. vi boot/grub/menu.lst and replace the old ID with the new one wherever it shows. Save and close.
  6. Reboot.

The accepted solution works only on a one time basis while this is a permanent fix. Hope it helps!

  • How could you use hdparm in this terminal? If I browse to /sbin I can't see it...
    – bluish
    Sep 29, 2016 at 13:10

Had the same problem, when moving from vshpere 5.1 to a ssd.

The problem occurs because the virtual machine uses Pata driver and the initrd does not have the driver to mount the physical drive. Novel FAQ had the answer you need to mount the drive using a recover disk, mount the device under /mnt then mount the sys proc and dev directories.

Chroot into mnt then you can recreate initrd this will rebuild the initrd system and include the drivers required to mount the physical drive, rather than the virtual drive in the virtual install. See the link below for details. In my case I had installed an image from suse studio then transferred it to a real drive. Once you get it working remember to remove the vmware tools to stop the boot time error. ( yast - software - search vm.



I solved this problem with a mixture of the other solutions.

Just for booting the system I did this:

  • when you get the boot error message reported, take note of the partition id requested by the boot procedure (say ID1) and type n
  • cd /dev/disks
  • ls -l to see which are the current id in the link names to the disks and partitions (say ID2)
  • create a copy of each link here renaming the copy with the id required above:

    mv ID2 ID1
    mv ID2-part1 ID1-part1


    mv scsi-12345676890abcdefgh0987654321 scsi-0987654321hgfedcba1234567890
    mv scsi-12345676890abcdefgh0987654321-part1 scsi-0987654321hgfedcba1234567890-part1
  • exit

System will boot.

Now you can change the setting to be sure won't encounter this problem again:

  • open a terminal and enter a root session with sudo su
  • vi /etc/fstab
  • replace every reference to disks and partitions by id (/dev/disks/by-id/...) with a reference to /dev/... (e.g. /dev/sda, /dev/sda1...)
  • vi /boot/grub/menu.lst
  • do the same in this file

You must log in to answer this question.

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