Hello,
Oracle actively supports two VirtualBox release lines: 5.0 and 5.1. In my experience, 5.1.x releases are a little faster in some operations, but have some annoying bugs that 5.0.x don't. Oracle prominently features 5.1 as the default download, and it is also the version in the repos of most Linux distros (Debian Jessie backports[1], Testing and Unstable, Arch, OpenSUSE, OpenMandriva, Ubuntu 16.10 - only Ubuntu 16.04 LTS has 5.0).
The CI test for our Vagrant images already tested with libvirt-kvm and VirtualBox 5.0; I extended it for testing with VirtualBox 5.1 as well, in a branch, but the test fails because sclo-vagrant1, based on upstream Vagrant 1.8.1, only supports VirtualBox up to version 5.0 (support for 5.1 first came in Vagrant 1.8.5). Are there any plans to upgrade sclo-vagrant1 to a more recent upstream version, or perhaps backport the support for 5.1 to the current sclo-vagrant1? [2]
If you'd rather update to a newer version, Vagrant 1.9.1 broke at least private networking (eth0 is preconfigured by our image, but the additional network interfaces that Vagrant 1.9.1 configures don't get an IP address - I assume public networking is broken as well, but I only tried private networking). I also saw some entries concerning NFS in the upstream issue tracker, not sure if it's caused by the same bug. Versions 1.9.0 and 1.8.6 work for me.
Best regards, Laurențiu
[1] https://www.debian.org/security/2016/dsa-3699 [2] https://github.com/mitchellh/vagrant/commit/b57b0e0d48fe8b4196ca6b7e01bb6c1e...
On Fri, Jan 20, 2017 at 3:20 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:
If you'd rather update to a newer version, Vagrant 1.9.1 broke at least private networking (eth0 is preconfigured by our image, but the additional network interfaces that Vagrant 1.9.1 configures don't get an IP address - I assume public networking is broken as well, but I only tried private networking). I also saw some entries concerning NFS in the upstream issue tracker, not sure if it's caused by the same bug. Versions 1.9.0 and 1.8.6 work for me.
I believe you're referring to this bug in Vagrant 1.9.1 ( https://github.com/mitchellh/vagrant/issues/8166) which also links out to some other related/duplicate issues. FWIW, it appears a manual 'service network restart' will load the network interfaces that get disabled by Vagrant. At least that worked for me, obviously not ideal though. Sadly there seem to be quite a few "breaking" issues in recent Vagrant releases, seemingly due to lack of testing upstream :( They do get fixed, but it can take weeks for new releases to be pushed including the fix.
-Jeff
Hello,
Yes, I have the sclo-vagrant1 collection mostly updated offline. There are few bugs to solve, but then I will build it in for CentOS. Foremost change is, that it's going to be based on Ruby 2.3 collection.
----- Original Message -----
From: "Jeff Sheltren" jeff@tag1consulting.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Friday, January 20, 2017 3:28:15 PM Subject: Re: [CentOS-devel] Any plans to update sclo-vagrant1?
On Fri, Jan 20, 2017 at 3:20 AM, Laurentiu Pancescu < lpancescu@gmail.com > wrote:
If you'd rather update to a newer version, Vagrant 1.9.1 broke at least private networking (eth0 is preconfigured by our image, but the additional network interfaces that Vagrant 1.9.1 configures don't get an IP address - I assume public networking is broken as well, but I only tried private networking). I also saw some entries concerning NFS in the upstream issue tracker, not sure if it's caused by the same bug. Versions 1.9.0 and 1.8.6 work for me.
I will stick with(or move to) patched and working version in Fedora[1]. As of now, it is Vagrant 1.8.7.
[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=19808
I believe you're referring to this bug in Vagrant 1.9.1 ( https://github.com/mitchellh/vagrant/issues/8166 ) which also links out to some other related/duplicate issues. FWIW, it appears a manual 'service network restart' will load the network interfaces that get disabled by Vagrant. At least that worked for me, obviously not ideal though. Sadly there seem to be quite a few "breaking" issues in recent Vagrant releases, seemingly due to lack of testing upstream :( They do get fixed, but it can take weeks for new releases to be pushed including the fix.
-Jeff
I will keep you posted, so we can test and fix in advance any issues to come.
Regards,
Pavel Valena Associate Software Engineer Brno, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED. All of the airlines in the Fortune Global 500 rely on Red Hat. Find out why at Trusted | Red Hat
On 20/01/17 16:04, Pavel Valena wrote:
Yes, I have the sclo-vagrant1 collection mostly updated offline. There are few bugs to solve, but then I will build it in for CentOS. Foremost change is, that it's going to be based on Ruby 2.3 collection.
That would be great, thanks!
I will stick with(or move to) patched and working version in Fedora[1]. As of now, it is Vagrant 1.8.7.
[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=19808
From a quick look at the Fedora source, curl is an external dependency instead of being embedded like upstream does (at least on Mac), so upstream 1.8.7 bug #7969 shouldn't affect us.
https://src.fedoraproject.org/cgit/rpms/vagrant.git/tree/vagrant.spec https://github.com/mitchellh/vagrant/issues/7969
Best regards, Laurențiu
On 20/01/17 15:28, Jeff Sheltren wrote:
On Fri, Jan 20, 2017 at 3:20 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:
I believe you're referring to this bug in Vagrant 1.9.1 ( https://github.com/mitchellh/vagrant/issues/8166) which also links out to some other related/duplicate issues. FWIW, it appears a manual 'service network restart' will load the network interfaces that get disabled by Vagrant. At least that worked for me, obviously not ideal though. Sadly there seem to be quite a few "breaking" issues in recent Vagrant releases, seemingly due to lack of testing upstream :( They do get fixed, but it can take weeks for new releases to be pushed including the fix.
We offered help with testing and CI, but they didn't seem interested.
I noticed that the ownership, permissions and SELinux context on ifcfg-eth1 (created by Vagrant) look very different than ifcfg-eth0. That doesn't prevent version 1.9.0 from working, so maybe it doesn't really matter. I just went back to 1.9.0, which seems to be working for what I need.
Regards, Laurențiu
-
Jeff Sheltren -
Laurentiu Pancescu -
Pavel Valena