The LIS team managed to reproduce the issue on an updated vanilla RHEL / CentOS 7.3 and confirmed that it's a bug with the latest RHEL / CentOS kernel update that just rolled out (see issue: https://github.com/LIS/lis-next/issue...).
While this is being taken care of on the LIS side, the fastest workaround is to revert to the previous kernel at the end of "install-rdo.sh", before v-magine installs LIS. Updates will follow as soon as we finish testing the workaround.
Updated LIS (Linux Integration Services) components are needed as the ones that come with the RHEL / CentOS kernel don't fully support Windows Server 2016 / Windows 10.
Update:
Reverting to the previous kernel solves the issue. This can be done by adding the following at the end of resources/install-rdo.sh :
# This is needed due to a bug in LIS with kernel-3.10.0-514.10.2.el7
exec_with_retry 5 0 /usr/bin/yum install -y kernel-3.10.0-514.6.2.el7
An updated v-magine.zip package with this workaround will be released as soon as tests are done.
The updated kernel that broke LIS was released yesterday (March 6th 2017) on CentOS: https://lists.centos.org/pipermail/ce...
Update 2
https://cloudbase.it/downloads/v-magi... now includes the workaround. We'll remove it as soon as the issue is fixed in LIS.
Hi, this looks like a CentOS bug. The only related info I could find is: https://bugzilla.redhat.com/show_bug.cgi?id=979695 Does it have the same issue after rebooting the controller VM? Do you have the same issue by repeating the setup?
Hi, I've just started using v-magine today and I'm getting the same error. My environment is Server 2016 with Gui + Hyper-V installed. I applied the extra command to install tinyrpc into install-rdo.sh I even tried to delete everything and restart v-magine and it reproduced the error.
Hi, after the error occurs, what is the state of the VM? Does is it boot eventually? What about if you reboot it? Thanks.
If this issue happens regularly, it's probably due to some CentOS updates. We're deploying a few test environments now to see if we can reproduce the issue.
The VM never finishes booting, this is after 1 hour of waiting. Rebooting the VM just repeats the same boot sequence, where it is basically hung waiting for the start job to finish.