I’ve looked around the internet and it suggests that it could be a problem with LVM, but I do not think that this machine is using LVM at all. I’ve also seen suggestions that I might need to create a new initrd image. The instructions are for RedHat and I don’t know how to do this for OpenSUSE. I can’t find any “alias scsi_hostadapter” lines in my /etc/modprobe.conf file.
IMO you’ll need to find out what happened before your screenshot.
Indeed, if /dev/sda2 was not created, then your conversion fails since that is your main root file system.
If you want to implement a workaround, you should be able to do what was always done before running a P2V utility…
Simply do a full system backup (preferably image based) and restore to your VM disk. This is no different than doing a full backup and restoring to bare metal.
I haven’t tried it, but you might even be able to dd everything.
You might also ask in the VMware forums, the type of error you have looks to be very generic and not likely distro-specific.
Alternative to using a P2V converter is to just do a standard backup/restore using any normal tool. 11.1 is a very old machine (and unsupported) but I think hotplug was advanced enough to recognize and install the new virtualized hardware.
The VM now boots but X11 is not starting. I suspect it’s because the video drivers aren’t correct: the physical machine uses an old Intel video chip and I’ve no idea what VirtualBox uses.
I’ve tried fixing up the graphics settings from the command line using the instructions outlined at http://en.opensuse.org/SDB:Configuring_graphics_cards. Specifically, I’ve tried nomodeset, failsafe, using the installation config and that has not worked.
Any help in fixing this would be much appreciated.
> It looks like I’m unable to locate /dev/sda2 and I get dumped into a
> console. When I list the contents of /dev, I see that there is no
> /dev/sda2.
Meaning you did not create it.
In fact, there is no hard disk at all in that listing.
Did you, perchance, install into an usb external disk?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Agree with Carlso that there probably is a custom layout issue, but I suspect the source.
From your original (physical) machine, pls post the resulsts of the following which describes your source partitions and disks.
df -h
I assume(?) that you are migrating to target disk(s) which are equal or greater in size, and the same number of disks as the source… And, that the target virtual disk is unpartitioned and unformatted.
Once you migrate, openSUSE should recognize the new hardware (including the virtual GPU) install and run new drivers to support automatically. Since 11.1 is very old, many architectural changes have happened which <might> require some manual investigation. So, if you need assistance, will need your source GPU.
For example, I’d have to look it up, somewhere approx. 12.2 a system I was supporting specified an “nVidia monitor” somewhere under /etc/ which was blocking changes to a different GPU. Once that was disabled/removed, the system could change GPUs.
openSUSE 11.1 is so old that back then there was no autoconfig that handled Xorg like there is now (at least as good).
You can re-create the entire xorg.conf by running (as root); init 3 to drop to initlevel 3, then running; sax****2 -r -m 0=vesa, after this step you can run init 5 to switch to GUI runlevel.
This should get you up with the basic no acceleration, no fancy things VESA driver.
As for the ESX failure that is most likely due to the initrd not containing the suitable SCSI driver hence it’s not seeing the drives at all (usually vSphere/ESX/VMware defaults to LSI LogicParallel adapter).
Although you can try this, I doubt it would solve anything… but there is a chance in a different way.
When you deploy a Guest, the display driver for the virtualization technology (in this case VBox) is used, it’s one of the features of virtualization in general… Guests are portable from one hardware host to another because Guests see only the virtualized hardware, not the real hardware.
But, I do remember that unlike nowadays an xorg.conf is created, used and perhaps required, but the problem is that once created it typically cannot be updated or modified automatically. So, removing the existing xorg.conf and re-creating might be necessary (Does the machine boot successfully into Recovery Mode?).
Keep in mind though…
Any display issues have nothing to do with a missing sda2, and that has to be resolved before you can investigate this display issue.