Hi,
Now that CentOS 7.3 has been released, vagrant boxes have become broken when the vagrant-vbguest plugin is used to build guest additions at creation time due to the "kernel-devel" package matching the running kernel not being available in the default repos anymore (since the base repo is not cumulative with older point releases).
Of course, once there's an official CentOS 7.3 base box available, the problem should fix itself, but a somewhat important usecase remains broken and it's why I'm posting this:
Using vagrant is especially useful when you want reproducible environments, and this includes pinning the base box to a particular version. As it stands, new CentOS point releases permanently break this usecase and I believe it would be important to have a solution for this.
Best regards,
-- Carlos Rodrigues
Hi,
I'm a member of the Cloud Instance SIG, involved in the development of the Vagrant images (I'm a CentOS contributor, not part of the Core Team). [1]
On 13/12/16 18:16, Carlos Rodrigues wrote:
Now that CentOS 7.3 has been released, vagrant boxes have become broken when the vagrant-vbguest plugin is used to build guest additions at creation time due to the "kernel-devel" package matching the running kernel not being available in the default repos anymore (since the base repo is not cumulative with older point releases).
I know. I planned to have new Vagrant images, based on CentOS Linux 7.1611, available simultaneously with the main release. In the past weeks, I had already tested updating the v1610 centos/7 image with the packages from the CR repository, without seeing any problems. I started test builds on Monday morning, as soon as the repos were switched, but they failed: our image builders, running CentOS 6.8, were unable to parse the XFS filesystem generated by a fresh 7.1611 installation (this worked without issues upto 7.1511, the previous version). We hope to solve this in the following days - many thanks to Fabian and Thomas for their help.
Part of the problem is caused by the fact that vbguest tries to install the VirtualBox Guest Additions *before* performing a system update. As you pointed out, this doesn't work over point releases such as this one due to kernel-devel and kernel-headers being unavailable; it also has the disadvantage of wasting time by having the box compile the Guest Additions twice - once during the initial "vagrant up", and then during the kernel upgrade. My own starter kit avoids this problem by updating the system first and then installing the VirtualBox Guest Additions, leaving you with a ready-to-use 7.1611 system after "vagrant up", even when starting with a 7.1511-based v1610 box. [2] It requires Ansible on the host, and you might have to try "IDE" or "IDE controller" in the Vagrantfile when attaching the ISO, if VirtualBox complains about not finding it.
Using vagrant is especially useful when you want reproducible environments, and this includes pinning the base box to a particular version. As it stands, new CentOS point releases permanently break this usecase and I believe it would be important to have a solution for this.
As far as I understand, we can only support the current version of CentOS Linux (right now, 7.1611) - not any previous releases. The only solution I can think of would be to provide the packages required to build the VirtualBox Guest Additions as part of the image, so that it becomes self-sufficient.
However, this would increase the size of the box by around 180MB just for console support (to support X11, we'd need even more space for the X11 development packages, Mesa and some others). Considering that networking works fine without the Guest Additions, and the availability of SMB, NFS and sshfs for shared folders, not to mention that VirtualBox shared folders are slow, prone to data corruption in combination with sendfile and occasionally 'forgetting' to update some files between the host and the guest, I feel inclined to keep the package selection as it is now.
Best regards, Laurențiu
[1] https://wiki.centos.org/SpecialInterestGroup/CloudInstance [2] https://github.com/lpancescu/cloud-instance-starter-kit
On Tue, Dec 13, 2016 at 12:16 PM, Carlos Rodrigues cefrodrigues@gmail.com wrote:
Hi,
Now that CentOS 7.3 has been released, vagrant boxes have become broken when the vagrant-vbguest plugin is used to build guest additions at creation time due to the "kernel-devel" package matching the running kernel not being available in the default repos anymore (since the base repo is not cumulative with older point releases).
They're available. You have to enable the "vault" repositories, which are fortunately listed in the /etc/yum.repos.d/Centos-Vault.repo.
Of course, once there's an official CentOS 7.3 base box available, the problem should fix itself, but a somewhat important usecase remains broken and it's why I'm posting this:
Using vagrant is especially useful when you want reproducible environments, and this includes pinning the base box to a particular version. As it stands, new CentOS point releases permanently break this usecase and I believe it would be important to have a solution for this.
Best regards,
-- Carlos Rodrigues _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 14/12/16 04:04, Nico Kadel-Garcia wrote:
They're available. You have to enable the "vault" repositories, which are fortunately listed in the /etc/yum.repos.d/Centos-Vault.repo.
Good point. I see that Carlos has already found a solution by customizing the vbguest installer in the Vagrantfile:
https://github.com/dotless-de/vagrant-vbguest/issues/240#issuecomment-266741...
On Wed, Dec 14, 2016 at 9:53 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:
They're available. You have to enable the "vault" repositories, which are fortunately listed in the /etc/yum.repos.d/Centos-Vault.repo.
Enabling the vault repository isn't an option since any given release doesn't have a vault configured for its own version, only for previous ones.
On 14/12/16 04:04, Nico Kadel-Garcia wrote:
Good point. I see that Carlos has already found a solution by customizing the vbguest installer in the Vagrantfile:
https://github.com/dotless-de/vagrant-vbguest/issues/240#issuecomment-266741...
Unfortunately that "solution" breaks when there isn't a "kernel-devel" package in "updates" yet. It also breaks when a particular release is dropped out of "mirror.centos.org"(*).
The first bit is fixable one way or the other. The second bit is fixable by using "vault.centos.org", but that would require a release to be vaulted _before_ the new release becomes available. Right now "vault.centos.org" doesn't contain binary packages for 7.2.1511, so that isn't happening.
(*) The point here is to be able to destroy a vagrant instance and safely recreate it sometime in the future (maybe the far future). This also means no mandatory system updates inside the VM to be able to build the guest additions.
Best regards,
On Wed, Dec 14, 2016 at 4:57 PM, Carlos Rodrigues cefrodrigues@gmail.com wrote:
On Wed, Dec 14, 2016 at 9:53 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:
They're available. You have to enable the "vault" repositories, which are fortunately listed in the /etc/yum.repos.d/Centos-Vault.repo.
Enabling the vault repository isn't an option since any given release doesn't have a vault configured for its own version, only for previous ones.
On 14/12/16 04:04, Nico Kadel-Garcia wrote:
Good point. I see that Carlos has already found a solution by customizing the vbguest installer in the Vagrantfile:
issuecomment-266741691
Unfortunately that "solution" breaks when there isn't a "kernel-devel" package in "updates" yet. It also breaks when a particular release is dropped out of "mirror.centos.org"(*).
The first bit is fixable one way or the other. The second bit is fixable by using "vault.centos.org", but that would require a release to be vaulted _before_ the new release becomes available. Right now "vault.centos.org" doesn't contain binary packages for 7.2.1511, so that isn't happening.
https://bugs.centos.org/view.php?id=8424
(*) The point here is to be able to destroy a vagrant instance and safely recreate it sometime in the future (maybe the far future). This also means no mandatory system updates inside the VM to be able to build the guest additions.
Best regards,
-- Carlos Rodrigues _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 14/12/16 16:57, Carlos Rodrigues wrote:
(*) The point here is to be able to destroy a vagrant instance and safely recreate it sometime in the future (maybe the far future). This also means no mandatory system updates inside the VM to be able to build the guest additions.
You are already able to recreate any older instance of a box and it will work perfectly, including networking and shared folders via NFS - just not with the VirtualBox Guest Additions or if you have the vbguest plugin installed.
Perhaps I should mention I don't use the GA myself - I never saw them being worth the trouble, except for improved video performance on desktop installations. Maybe it just doesn't fit my use case, as they seem to be quite popular with other users.
Best regards, Laurențiu
On 14/12/16 18:17, Laurentiu Pancescu wrote:
On 14/12/16 16:57, Carlos Rodrigues wrote:
(*) The point here is to be able to destroy a vagrant instance and safely recreate it sometime in the future (maybe the far future). This also means no mandatory system updates inside the VM to be able to build the guest additions.
You are already able to recreate any older instance of a box and it will work perfectly, including networking and shared folders via NFS - just not with the VirtualBox Guest Additions or if you have the vbguest plugin installed.
Perhaps I should mention I don't use the GA myself - I never saw them being worth the trouble, except for improved video performance on desktop installations. Maybe it just doesn't fit my use case, as they seem to be quite popular with other users.
Best regards, Laurențiu
Just as a follow up on that issue (at the builder side) : as we saw that we needed another builder/hypervisor for that kojid image builder instance, I deployed today a centos 7.3.1611 node and added it to CBS : https://cbs.centos.org/koji/hostinfo?hostID=9
It's not the first centos 7 builder (as we have already ppc64/ppc64le and aarch64 centos 7 builders) but it was the first one on which we tried the imagefactory image builder task.
Our first test wasn't working, but after some troubleshooting with Laurentiu in #centos-devel (and analysis from python tracebacks) we found the issue . It seems there is a mismatch between koji version installed on the builders and pykickstart from 7.3.1611 :
koji-builder-1.10.1-1.el7.centos.noarch pykickstart-1.99.66.10-1.el7.noarch
We'll investigate the koji upgrade later with Thomas, but the priority was to build those Vagrant images, and so have a builder up and running. The following "hot patch" seems to have solved the initial issues :
--- /usr/sbin/kojid.orig 2016-12-14 16:16:45.461903827 +0000 +++ /usr/sbin/kojid 2016-12-14 16:23:49.356851809 +0000 @@ -2446,7 +2446,7 @@ # may not be a problem if the included kickstarts are present # in the repository we checked out. if opts.get('ksversion'): - version = ksparser.version.makeVersion(ksparser.stringToVersion(opts['ksversion'])) + version = ksparser.version.makeVersion(ksparser.version.stringToVersion(opts['ksversion'])) else: version = ksparser.version.makeVersion() self.ks = ksparser.KickstartParser(version) @@ -2828,7 +2828,7 @@ # We require users to flatten their kickstart file. if self.opts.get('ksversion'): version = ksparser.version.makeVersion( - ksparser.stringToVersion(self.opts['ksversion'])) + ksparser.version.stringToVersion(self.opts['ksversion'])) else: version = ksparser.version.makeVersion() ks = ksparser.KickstartParser(version)
After that, the tasks that were failing were able to run and produce artifacts (vagrant boxes) : https://cbs.centos.org/koji/taskinfo?taskID=148368
Hope that it can unblock the situation and we'll discuss the potential upgrade of the remaining builders to CentOS 7 too (and koji upgrade too, after other tests)