unable to query the live linux source machine

[brikla]

I am trying to use VMWare convertor to convert Ubuntu 18.04.6 LTS from physical to virtual. I have used the convertor several times previous with no issues. I am getting an error 'vmware converter unable to query the live linux source machine'.

I am able to ssh into the physical machine using the root credentials, which are the credentials I am using with the convertor.

Convertor-worker log contains error "Command '/usr/sbin/grub2-install --version' failed with exit code 32512".

Diagnostics attached. How to proceed?

 

 

Attachment(s)

ConverterDiagnostics20220117131945.zip   104 KB 1 version

[cjrw]

I have the same issue here

We have dozens of Linux machines here  - various distros as both VMs and physical machines.  

Root ssh with a cert (no passphrase) works to all of them for console, backups and visual studio but fails in new VMware converter.

ssh as root with no password example:

 

However when we use the converter we see the popup for the first connection asking if we trust the thumbprint, so can see the running instance of the server fine, click yes...   wait a few seconds and then get the yellow top banner with the error message.

 

Looking at the server side logs it doesnt look as if the converter is actually trying to assert the ssh key at all and drops the connection with no form of negotiation

extract from /var/log/auth.log when the converter attempts to connect (Ip addrs removed):

Sep 30 10:01:54 smtpgate sshd[464823]: Connection reset by xxx.xxx.xxx.xxx port 55083 [preauth]
Sep 30 10:01:55 smtpgate sshd[464825]: Connection reset by xxx.xxx.xxx.xxx port 55085 [preauth]

 

 

extract from /var/log/auth.log when I ssh from a WSL terminal  using samessh key (Ip addrs removed):

Sep 30 10:04:19 smtpgate sshd[464836]: Accepted publickey for root from xxx.xxx.xxx.xxx port 55191 ssh2: RSA SHA256
Sep 30 10:04:19 smtpgate sshd[464836]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Sep 30 10:04:19 smtpgate systemd-logind[520]: New session 1758 of user root.


This particular target box is an ubuntu 20.04 system, but results are the same on Debian, aplpine, centos etc

Converter is locally installed on windows 10 desktop

I have admin on local machine

I will spin up a spare box and see if ssh as root using password  !!!   works and report further....

EDIT::   Yup... ssh as root using password works as expected - suggesting this is an SSH key based issue

[Ivan Ivanov]

I looked at the log bundle and the "grub-install" error is not the issue. Converter tries to detect the grub version, so it runs multiple commands, trying to get successful execution. Since this machine seems to have a GRUB1 bootloader, it is expected that grub2-related commands fail.

IMO the reason for the failure is at the volume layout:

--> <volume mountPoint="/" blockSizeInBytes="4096" capacityInBlocks="36915830" blocksFree="29946550" blocksUsed="6969280" devicePath="/dev/wally/root" fileSystemType="ext3" isBootVolume="false" label="">
--> <extfsFeatures dirIndex="true" filetype="true" hasJournal="true" journalDev="false" resizeInode="true" sparseSuper="true" extent="false" flexBg="false" uninitBg="false" inodesCount="9388032"/>
--> </volume>
--> <volume mountPoint="/var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/engines" blockSizeInBytes="4096" capacityInBlocks="36915830" blocksFree="29946549" blocksUsed="6969281" devicePath="/dev/wally/root" fileSystemType="ext3" isBootVolume="false" label="">
--> <extfsFeatures dirIndex="true" filetype="true" hasJournal="true" journalDev="false" resizeInode="true" sparseSuper="true" extent="false" flexBg="false" uninitBg="false" inodesCount="9388032"/>
--> </volume>

 We can see that "/dev/wally/root" is mounted at two locations - at "/" (root filesystem) and also at "/var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/engines". Converter has issues with this type of layout. The solution would be to unmount the device temporarily from "/var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/engines" until the conversion completes.

However given that Ubuntu-18 has kernel 4.15 and Converter is using 2.6.XX, I think it is quite likely for the conversion to fail after the data is copied while trying to reconfigure the guest OS in the destination VM and make it bootable in virtual environment.