VMware Cloud Community
Daisychick
Contributor
Contributor
Jump to solution

ubuntu p2v - converter fails generic error

Hello,

I'm new to vmware and I'm trying to teach myself. I have ubuntu 11.10 running on a spare laptop with linux converter server 4.0.1. I have the Converter Standalone Client 4.0.1 installed on a windows 7 machine. I have an ESXi server cluster running 4.1.0 that I'm a superadmin on. I'm trying to use the windows machine to convert the ubuntu machine from physical to virtual. I go the through the wizard and everything looks fine. I click start, it starts, and then stops and disconnects with a very generic error "Error: Unable to create the virtual machine 'ubuntu-test-machine'." no other reason given.

Can someone point me in the right direction? Either documentation is limited or my googling needs work because I'm having a hard time finding info on this. It's either outdated or a little to vague for a beginner. Point me in the right direction and I'm sure I can figure it out.

I appreciate any help. Screenshots attached.

65 Replies
wthrower
Contributor
Contributor
Jump to solution

Clever workaround. Thanks.

Reply
0 Kudos
McServer
Contributor
Contributor
Jump to solution

any way of determining what the string would be for ubuntu 10.10 or is there by chance a fix/update in the works or anything?

Reply
0 Kudos
ivivanov
VMware Employee
VMware Employee
Jump to solution

If you paste this string - it will work (it is detected as GRUB2 - confirmed). Otherwise grub-install -v is showing the version, however it must be in the "supported" format or Converter falls back to GRUB1 as default.

__________
It is worse!
Reply
0 Kudos
McServer
Contributor
Contributor
Jump to solution

This fix worked perfectly for me. I just had to put the listed code above into the correct location in the grub-install script file and things were just great past that. Thank you!

Reply
0 Kudos
wthrower
Contributor
Contributor
Jump to solution

I didn't actually try this workaround until today, and it's not working for me. I'm still getting the following error

[2012-02-01 09:17:03.104 06388 info 'App'] [task,373] [task-9] -- ERROR -- Convert: converter.fault.CloneFault
(converter.fault.CloneFault) {
   dynamicType = <unset>,
   faultCause = (vmodl.MethodFault) null,
   description = "GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 127, and message:
/vmware-updateGrub.sh: 38: grub: not found

If I run

grub-install -v

on the machine I am trying to clone, I do indeed get

grub-install (GNU GRUB 1.99-12ubuntu5)

I tried pulling off "ubuntu5" and "-12ubuntu5", and changing "GNU GRUB" to just "GRUB" with no luck.
Reply
0 Kudos
ivivanov
VMware Employee
VMware Employee
Jump to solution

You are using Converter 5.0, aren't you?!

Converter 4.x does not support GRUB2 at all...

__________
It is worse!
Reply
0 Kudos
wthrower
Contributor
Contributor
Jump to solution

Wow. Embarassing. I did download and install 5.0 before I began, but unfortunately not on THIS computer. I'll also make sure the computer is powered on before I proceed. Thank you.

Reply
0 Kudos
wthrower
Contributor
Contributor
Jump to solution

In an attempt to redeem myself, here's what I wish I had known before I started trying to convert an Ubuntu 11.10 system to a VM using VMware vCenter Converter Standalone on Windows.

  1. Edit converter-agent.xml and converter-worker.xml (located in "%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone") and change <useSudo>false</useSudo> to <useSudo>true</useSudo> in both files.
  2. After saving the changes to those XML files, restart the Converter agent and worker services--you can use the Services applet, or from an administrator command prompt, run: for %a in ("VMware vCenter Converter Standalone Agent" "VMware vCenter Converter Standalone Worker") do ( net stop %a && net start %a )
  3. Log in to the Ubuntu box and run: sudo sed -i -e 's/^PACKAGE_NAME=GRUB$/PACKAGE_NAME="GNU GRUB"/' -e 's/)\( ${PACKAGE_VERSION}\)"$/ \1)"/' `which grub-install`
  4. While still on the Ubuntu box, create the file /etc/sudoers.d/nopasswd with the following contents: %admin ALL = NOPASSWD: ALL
  5. Run sudo chmod 440 /etc/sudoers.d/nopasswd
  6. Run the VMware vCenter Converter Standalone application as administrator (in Vista, Win7, Server 2008, and Server 2008 R2, right-click the icon and choose "Run as administrator") and do the conversion.
  7. After converting, log in to the original and converted systems and remove /etc/sudoers.d/nopasswd

Items 1, 2, 4, 5, and 7 address the fact that Ubuntu disables the root account by default and requires authorized users (those in the admin or root groups) to run sudo and enter their own passwords to become root. Items 1 and 2 make Converter use sudo, and item 4 eliminates the password protection. Item 7 restores the password protection of sudo. As an alternative to those steps, you could set a root password. This eliminates the following error.
The user '<user>' does not have root privileges on the source machine.
Item 3 changes the format of the grub-install -v command to match the expectations of VMware Converter so that it will execute the commands for GRUB2 rather than GRUB1. This eliminates the error being discussed in this thread.
Item 6 (running as administrator) eliminates the following error.
A general system error occurred: Crypto Exception: error:02001005:system library:fopen:Input/output error:unable to load C:\ProgramData\VMware\VMware vCenter Converter Standalone\ssl\rui.crt
I hope that helps someone else.
Oh... and be sure to use Converter 5.x! Smiley Happy
Reply
0 Kudos
ivivanov
VMware Employee
VMware Employee
Jump to solution

Interesting reading :-). Thanks for summarizing all this information.

I think it is a good idea to add 1, 2, 4, 5 and 7 in the documentation in some form, but not just in the config file. As for 3 - we should really fix the code to be more flexible and recognize properly all version strings and remove step 3 completely :-). One clarification though - there is no need to edit converter-agent.xml file, converter-worker.xml should be enough (I guess we should update the default agent configuration file as well).

__________
It is worse!
Reply
0 Kudos
rcastlegdi
Contributor
Contributor
Jump to solution

Sorry to add to this post but I'm having similar problems trying to P2V Ubuntu 12.04LTS. I got through all the other stumbling blocks but am now getting this error

FAILED: An error occurred during the conversion: 'GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 1, and message: FATAL: kernel too old Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root '

at 99%

Any help would be appreciated.

Reply
0 Kudos
lomax1
Contributor
Contributor
Jump to solution

When you say "put the listed code above into the correct location in the grub-install script file"

where EXACTLY did you put it?

According to ivivanov, you just put it at the top...is there a better place because the error occurred for me on EVERY Ubuntu (10.10 1nd 11.04) server we have been virttualizing and cant get past them...only gotten a 10.04 successfully, but it was already on an esxi 4 server so that was a gimme.

We're about to just start building new machines in the cluster and try to migrate what we can cause we are beating our heads against this like crazy.

Thanks

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

The problem is that when Converter parses GRUB version it expects a string starting with "grub-install (GNU GRUB " and then the version number. This is what is received by "grub-install -v" prior to Ubuntu 10.10 (I think) and has been changed in newer versions to "grub-install (GRUB) " followed by the version number. So the fix is to have grub-install return a parseable string. Ivan suggests to put this piece of code at the top after the comments, I prefer to edit the part that returns the version, it's a matter of personal choice.

You may create a script that changes grub-install accordingly and just run it on all your machines.

HTH

Plamen

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

sed -i -e "/s/\$self (\${PACKAGE_NAME}) \${PACKAGE_VERSION}/\$self (GNU \${PACKAGE_NAME} \${PACKAGE_VERSION})/" /usr/sbin/grub-install

This should do, although I give no guarantee :slightly_smiling_face:

Reply
0 Kudos
tvleavitt
Contributor
Contributor
Jump to solution

It is August. This problem, and the solution, was clearly identified in January. Why has it not been fixed in Converter 5.0? I just downloaded my copy a few days ago. I mean, seriously, how much complexity are we talking about here - change the way the string is parsed, and we'll live with the need to set a password for root. That's all. Having it run as root, and parse every possible grub-install return string is a "would be nice".

Everyone who tries to run p2v on a relatively current Ubuntu or Debian machine is screwed... after spending an hour watching everything progress. How lame is that? All the resources VMware has, and they can't fix a relatively simple problem?

Reply
0 Kudos
ivivanov
VMware Employee
VMware Employee
Jump to solution

Why has it not been fixed in Converter 5.0?

Because it was reported for Converter 5.0 and because of that obviously it happened after Converter 5.0 was released.

__________
It is worse!
Reply
0 Kudos
tvleavitt
Contributor
Contributor
Jump to solution

And VMware can't release a patched or slightly updated version? A known bug like this takes over 6 months to be resolved? Seriously? I've done software development (and supported it from an IT perspective), this is a trivial delta from the frozen release code, and even if they'd done significant forward development on 6, they can't seriously argue that even if they have to integrate the changes into a revised version, that this amounts to a substantial level of work. Meanwhile, again, everyone trying to do a P2V from recent Ubuntu versions or Debian 6 is hosed. We can't be talking about more than an hour or two of coding, and even being generous, a week's worth of testing and Q/A. How many patches to vSphere, a much bigger, more critical beastie, have they released in the interim?

Reply
0 Kudos
ivivanov
VMware Employee
VMware Employee
Jump to solution

How many patches to vSphere, a much bigger, more critical beastie, have they released in the interim?

Here is the actual answer to your question - much bigger and more critical. Since you have been in software development you know it is all a matter of priorities and resources...

__________
It is worse!
Reply
0 Kudos
videntity
Contributor
Contributor
Jump to solution

it is all a matter of priorities and resources...

Oh that is so helpful. I've been trying to get Ubuntu 12.04 LTS migrated from Workstation 8 to ESXi 5.0 and even after following the suggestions upthread here it always fails with "FAILED: An error occurred during the conversion: 'GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 1, and message: FATAL: kernel too old Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root '" no matter what I do with the grub-install version string. I even tried going back to grub 1 and that failed the same way. Fortunately I have access to the server so here's how I got it working.

1. On the Ubuntu system give root a password.  It can removed later with "passwd -l root"

2. Use VMware vCenter Converter Standalone to do the migration. It will fail with the above error.

3. On the ESXi server put in the Ubuntu 12.04 install CD. I'm using the server version of Ubuntu.

4. In the vSphere Client, set the new VM to use the host CDROM, and set it to go into the BIOS on the next boot.

5. Power on the VM, and in the BIOS change the boot order so that the CDROM is above the hard drive. Reboot.

6. The VM will come up on the Ubuntu install CD. Go into rescue mode, then reinstall grub.

7. Before rebooting go into a shell on the Ubuntu system, it's a menu item in rescue mode. In the shell use blkid to see what the correct UUID is for the boot drive and then fix up /etc/fstab to show the correct UUID. blkid didn't show me anything for the swap partition so in /etc/fstab I removed the UUID for swap and just used the device name, /dev/sda5 in my case.

8. Reboot. The CD will boot again, just have it boot the hard disk. The Ubuntu VM should boot up OK at this point. Shut it down.

9. Set the VM to go into the BIOS again on the next boot, boot it, and change the boot order so that the CDROM is below the hard drive. Reboot.

10. The Ubuntu VM should come up OK now. All done.

I wish I could have found and edited vmware-updateGrub.sh in order to avoid all of this pain but I couldn't find it.

Reply
0 Kudos
ivivanov
VMware Employee
VMware Employee
Jump to solution

I am not saying whether it is good or bad, just this is the current situation. I know it is not helpful, but the best we can do given the current state is to offer a manual workaround of the issue.

BTW your error "kernel too old" is NOT the same issue and it would not be fixed with the proposed solution, no matter whether the manual workaround or implemented in the product.

__________
It is worse!
Reply
0 Kudos
videntity
Contributor
Contributor
Jump to solution

I understand the unfortunate situation. But I only see workarounds offered by other users, not anyone from VMware.

The "kernel too old" message is bogus, and is an example of poor script writing. The kernel in my situation is Ubuntu's linux-image-3.2.0-29-virtual, which is 3.2.24 plus Ubuntu patches. The script is checking for "X" and finding "Y", but instead of logging "X" and "Y" someone decided that anything other than "X" MUST be "kernel too old". That's not the problem.

Reply
0 Kudos