Closed kbpease closed 7 years ago
The current boxes are built for Parallels 13, not Parallels 12
On Sep 8, 2017, at 4:38 PM, Kevin Pease notifications@github.com wrote:
Assuming:
vagrant (version 2.0.0, 1.9.4, and 1.8.6 all exhibit the same behavior) parallels 12.2.1 boxcutter/centos7 box 17.0904.1 Attempting to run 'vagrant up' on a minimal vagrant box as defined in the attached Vagrantfile.txt https://github.com/boxcutter/centos/files/1289323/Vagrantfile.txt fails in the following manner:
$ vagrant --version Vagrant 2.0.0
$ prlctl --version prlctl version 12.2.1 (41615)
$ vagrant box list boxcutter/centos7 (parallels, 17.0904.1)
$ vagrant --provider=parallels up Bringing machine 'centos7' up with 'parallels' provider... ==> centos7: Registering VM image from the base box 'boxcutter/centos7'... ==> centos7: Cloning new virtual machine... ==> centos7: Unregistering the box VM image... ==> centos7: Setting the default configuration for VM... ==> centos7: Checking if box 'boxcutter/centos7' is up to date... ==> centos7: Setting the name of the VM: tmp_centos7_1504912986672_60599 ==> centos7: Preparing network interfaces based on configuration... centos7: Adapter 0: shared ==> centos7: Clearing any previously set network interfaces... ==> centos7: Booting VM... ==> centos7: Waiting for machine to boot. This may take a few minutes... centos7: SSH address: 10.211.55.12:22 centos7: SSH username: vagrant centos7: SSH auth method: private key centos7: Warning: Connection refused. Retrying... centos7: centos7: Vagrant insecure key detected. Vagrant will automatically replace centos7: this with a newly generated keypair for better security. centos7: centos7: Inserting generated public key within guest... centos7: Removing insecure key from the guest if it's present... centos7: Key inserted! Disconnecting and reconnecting using new SSH key... ==> centos7: Machine booted and ready! ==> centos7: Checking for Parallels Tools installed on the VM... ==> centos7: Parallels Tools installed on this VM are outdated! In most cases ==> centos7: this is fine but in rare cases it can cause things such as shared ==> centos7: folders to not work properly. If you see shared folder errors, ==> centos7: please update Parallels Tools within the virtual machine and ==> centos7: reload your VM. ==> centos7: Setting hostname... The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed!
Update sysconfig
sed -i 's/(HOSTNAME=).*/\1centos7.vagrant.local/' /etc/sysconfig/network
Update DNS
sed -i 's/(DHCP_HOSTNAME=)./\1"centos7"/' /etc/sysconfig/network-scripts/ifcfg-
Set the hostname - use hostnamectl if available
echo 'centos7.vagrant.local' > /etc/hostname if command -v hostnamectl; then hostnamectl set-hostname --static 'centos7.vagrant.local' hostnamectl set-hostname --transient 'centos7.vagrant.local' else hostname -F /etc/hostname fi
Prepend ourselves to /etc/hosts
grep -w 'centos7.vagrant.local' /etc/hosts || { sed -i'' '1i 127.0.0.1\tcentos7.vagrant.local\tcentos7' /etc/hosts }
Restart network
service network restart
Stdout from the command:
/bin/hostnamectl Restarting network (via systemctl): [FAILED]
Stderr from the command:
Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details. This same Vagrantfile works as expected with the pre-migration boxcutter/centos73 version 2.0.21 box.
Output of 'systemctl status network.service' and 'journalctl --all' on the failing box are attached: journalctl-output.txt https://github.com/boxcutter/centos/files/1289349/journalctl-output.txt systemctl-output.txt https://github.com/boxcutter/centos/files/1289348/systemctl-output.txt Any idea what might be going on here? I tried with multiple versions of vagrant, and a coworker was also able to reproduce my results, so I believe it's an issue with this version of the centos7 box.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/boxcutter/centos/issues/74, or mute the thread https://github.com/notifications/unsubscribe-auth/AKSr5NsaeSrJMQg8Tl1_5M-VE_1fPuidks5sgc_9gaJpZM4PRzLh.
@annawake - DOH, sorry about that - I overlooked the Parallel Tools version number.
I performed an upgrade to Parallels 13, and it seems that vagrant 2.0 (at least - have not tried with 1.8.x or 1.9.x) still exhibits this behavior with the same Vagrantfile as previously attached.
If I back-rev to the centos73 (v2.0.21) box with the upgraded parallels (or with parallels 12), it works okay. If I try other centos 7.3 boxes (e.g. bento/centos-7.3), it also works.
I notice that the recent commit with id 14205a0 appears to replace the eth[0123...n] naming convention, however when I connect to the box after this failure occurs, the network interfaces show as eth0 and lo -- is this expected? My understanding was that that commit should have resulted in the interface names moving to the systemd or biosdevname standards by default.
That helpful input as we’re not seeing this on the other platforms. Vagrant has had numerous issues with consistent device naming, and there’s no real benefit to using it in a VM. I can believe that perhaps the parallels driver hasn’t caught up to the reset of vagrant. I was just wanted to see if I could stop having to resort using legacy bios naming just for vagrant. I’ll flip it back soon and do another build.
On Sep 8, 2017, at 6:58 PM, Kevin Pease notifications@github.com wrote:
@annawake https://github.com/annawake - DOH, sorry about that - I overlooked the Parallel Tools version number.
I performed an upgrade to Parallels 13, and it seems that vagrant 2.0 (at least - have not tried with 1.8.x or 1.9.x) still exhibits this behavior with the same Vagrantfile as previously attached.
If I back-rev to the centos73 (v2.0.21) box with the upgraded parallels (or with parallels 12), it works okay. If I try other centos 7.3 boxes (e.g. bento/centos-7.3), it also works.
I notice that the recent commit with id 14205a0 https://github.com/boxcutter/centos/commit/14205a09ad91654e3ddca024c36ccb3b81e0a036 appears to replace the eth[0123...n] naming convention, however when I connect to the box after this failure occurs, the network interfaces show as eth0 and lo -- is this expected? My understanding was that that commit should have resulted in the interface names moving to the systemd or biosdevname standards by default.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/boxcutter/centos/issues/74#issuecomment-328247398, or mute the thread https://github.com/notifications/unsubscribe-auth/AKSr5ELOmDkbBitefXMNZXjgxAr9yYtvks5sgfDUgaJpZM4PRzLh.
@annawake - Thanks! Please let me know if there's any additional information I can supply to help with troubleshooting, or if I can help verifying a fix.
The new rev of the centos boxes are deployed to boxcutter on Vagrant Cloud give it a go.
On Sep 11, 2017, at 11:02 AM, Kevin Pease notifications@github.com wrote:
@annawake https://github.com/annawake - thanks! Please let me know if I can supply any more information that would be helpful in troubleshooting.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/boxcutter/centos/issues/74#issuecomment-328609580, or mute the thread https://github.com/notifications/unsubscribe-auth/AKSr5EYmen_mFBoBqfUyMbTXdWQ7NwwGks5shXWmgaJpZM4PRzLh.
@annawake - Just gave it a throw, and successfully brought up a 17.0909.1 box - the issue appears to be resolved in this latest spin.
Assuming:
Attempting to run 'vagrant up' on a minimal vagrant box as defined in the attached Vagrantfile.txt fails in the following manner:
This same Vagrantfile works as expected with the pre-migration boxcutter/centos73 version 2.0.21 box.
Output of 'systemctl status network.service' and 'journalctl --all' on the failing box are attached: journalctl-output.txt systemctl-output.txt
Any idea what might be going on here? I tried with multiple versions of vagrant, and a coworker was also able to reproduce my results, so I believe it's an issue with this version of the centos7 box.