Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vboxsf doesn't work for Vagrant shared folders on Fedora 28 workstation #37

Open
olberger opened this issue Jun 29, 2018 · 9 comments
Open

Comments

@olberger
Copy link
Contributor

As mentioned in #35 I think the rebuild of the VirtualBox Guest extensions modules doesn't work, which leads to vboxsf not operational when doing a vagrant up.

I haven't tested after the merge from today, but that's what I get with the fedora28-ws variant on the patrickmslatteryvt origin's tree.

There are quite a number of posts out there mentioning issues with vbox guest extensions recompilation on Fedora28, but I haven't found a definitive reference.

Hth

@olberger
Copy link
Contributor Author

It seems that the extensions may be already included in Fedora 28 workstation : https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration of course that means that trying to recompile them may be useless / counterproductive.

I keep testing that way.

@olberger
Copy link
Contributor Author

AFAIU, there's no need to rebuild the VirtualBox Guest extensions on F28 workstation, since some modules are alreay in the distribution's kernel... Indeed, the F28-ws VMs have resizable windows when the graphics display appears...

Buuuuut, vboxsf didn't make it in time, as explained in https://fedoraproject.org/wiki/Common_F28_bugs#VBox_Guest_Additions (if this is to be trusted).

One of the main features of vagrant for me is sharing the local folder with the guest. Without this, there's less interest in using it :-/
What a mess.

@olberger
Copy link
Contributor Author

I've changed teh virtualbox.sh provisionning script to not attempt to install the Guest extensions when on Fedora 28 (well, not 26 or 27) and just add the vboxsf that's missing.

See my hack in olberger@f213402

This seems to allow the resulting base box to work well for Vagrant shared folders.

The dirty hack could be improved to only do what's necessary for the specific case of Fedora 28 workstation... Btw, I haven't checked the situation for F28 server.

Hth

@olberger
Copy link
Contributor Author

As for F28 server, it seems compiling the Guest extensions from the development release works, provided some changes to the virtualbox.sh script.

See my proposal in olberger@1e3cdaf

I guess both branches should now be merged, but maybe my contribution is enough for today.

More testing probably needed by others.

@patrickmslatteryvt
Copy link
Collaborator

Good catch, I'm starting a test of that now...

@olberger
Copy link
Contributor Author

olberger commented Jul 4, 2018

Btw, there seem to be issues with the mouse cursor with kernel 4.17 before 4.17.4 in X. See https://www.virtualbox.org/ticket/17827
At the moment, Fedora 28 exibits the issue, and needs to be addressed. If a 4.17.4 kernel gets into the updates in between, then thos will no longer be needed...

Hth,

@olberger
Copy link
Contributor Author

olberger commented Jul 4, 2018

Apparently solved with latest (not yet released in the updates for Fedora 28) 4.17.4 kernel : https://koji.fedoraproject.org/koji/buildinfo?buildID=1102770

@olberger
Copy link
Contributor Author

olberger commented Jul 5, 2018

I've updated my fedora-28 branch, and up to olberger@505064c everything seems to be working now (not tested extensively).

I guess the latest commit for installation of kernel 4.17.4 should probably be temporary, until an updated kernel is in the regular updates, and doesn't deserve going to main.

Also, the version of the VirtualBox Guest extensions forced to 5.12.4 should probably be reverted some day, but maybe a minimal version check should occur, in case the packer build runs on a machine equipped with a too old VirtualBox installation.

In my case, on Debian testing I had 5.2.10 which was too old...

More opinions probably needed. Maybe a compatibility table between distros, kernel versions and virtualbox versions ?

@b00ga
Copy link

b00ga commented Oct 3, 2018

I ran into this issue today. In debugging, I drilled down and eventually found that KERN_DIR really wanted to be set to /lib/modules/$(uname -r)/build, but even with that, I found that when the VBox additions install would run, it'd end up bombing out build the vboxsf module giving me cc1: some warnings being treated as errors

What I ended up eventually discovering is that the VBox guest additions are apparently getting incorporated into the mainline linux kernel. Fedora 27 & 28 include the vbox-guest-additions RPM for this. However apparently, the vboxsf bits haven't been rolled into the kernel yet. RPMFusion builds an akmod package for this.

In my testing, I've essentially replaced the entire script/virtualbox.sh with:

dnf install -y https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-28.noarch.rpm
dnf install -y virtualbox-guest-additions akmod-VirtualBox

Another strange gotcha I saw, was that apparently if you have a some of the bits installed from the Oracle VBox guest additions, you'll have /usr/sbin/mount.vboxsf. If you have this installed and try to use the RPMs above, you'll get errors about the mount command getting an invalid argument and journalctl -xe showing reports of vboxsf: Old binary mount data not supported, remove obsolete mount.vboxsf and/or update your VBoxService. (thanks to this Manjaro forum post for pointing me there).

References:
Fedora bugzilla - Bug 1576832 - virtualbox-guest-additions does not mount shared folder
CentOS forum discussion re: KERN_DIR/lib/modules - [SOLVED] Guest Additions Installation (KERN_DIR problem)
Fedora packages listing showing F28 being first release with virtualbox-guest-additions package - virtualbox-guest-additions
If RPM is installed, guest additions are supposed to warn you if you want to continue Guest Additions won't build in Fedora 28 (Kernel 4.16.1) -> fixed in 5.2.12

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants