weixin_39746652
weixin_39746652
2020-12-27 02:04

'Vagrant up' fails while restarting network service under parallels with boxcutter/centos7, version 17.0904.1

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 - all running under macOS 10.12.6 (Sierra)

Attempting to run 'vagrant up' on a minimal vagrant box as defined in the attached 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 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.

该提问来源于开源项目:boxcutter/centos

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

6条回答

  • weixin_39746652 weixin_39746652 4月前
    • 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.
    点赞 评论 复制链接分享
  • weixin_39605706 weixin_39605706 4月前

    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 wrote:

    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.

    点赞 评论 复制链接分享
  • weixin_39746652 weixin_39746652 4月前
    • Just gave it a throw, and successfully brought up a 17.0909.1 box - the issue appears to be resolved in this latest spin.
    点赞 评论 复制链接分享
  • weixin_39605706 weixin_39605706 4月前

    The current boxes are built for Parallels 13, not Parallels 12

    On Sep 8, 2017, at 4:38 PM, Kevin Pease 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.

    点赞 评论 复制链接分享
  • weixin_39746652 weixin_39746652 4月前
    • 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.

    点赞 评论 复制链接分享
  • weixin_39605706 weixin_39605706 4月前

    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 wrote:

    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.

    点赞 评论 复制链接分享

相关推荐