Closed jsnshrmn closed 7 years ago
@lo5an I managed to encounter broken vboxsf even when vbox guest additions seemed correctly compiled for the current kernel upon logging into the vm. vagrant reported no guest additions installed, but things looked correct. I manually ran vboxadd setup and restarted the vm. It was happy afterwards.
VBOXGUESTDIR=$(find /opt/ -type d -name "VBoxGuestAdditions-*" | sort | tail -1); sudo $VBOXGUESTDIR/init/vboxadd setup
Should always install the most recent local version of guest additions. That's not the end of the story, though.
On a whim, I also tested the following:
vagrant up $vmname
resulting up vm has no working additions
vagrant reload $vmname
resulting up vm has working additions. I suspect that my DKMS guest addtions config is working, but too late in the up process for vagrant to be happy.
@lo5an Can you test and see if a round of vagrant reloads makes your guest additions worky in cases where it's broken? It's possible that a vagrant provision might rebreak things afterwards, but I'd like you and or @groundedgopher to check since it should require minimal time investment on your part.
If that doesn't fix it, try running the aformentioned shell command and restarting the guest. That should fix it even if DKMS isn't doing what I think it is.
I'll take a look over the weekend.
assuming vboxadd setup, fixes things, I'll sub in that for the existing dkms autoinstall, and we'll see if our problems go away.
so, based on backchannel report from @lo5an, it sounds like vboxadd setup fixed it 2/3 of the time. That's enough of an improvement to warrant updating the playbook. thinking of versionlocking everything in yum instead of just the kernel.
We now conditionally re-install guest additions and mount /vagrant if it's not properly mounted at boot time. There's still a couple of minutes of compiling delay after vagrant up, but after the wait you can use /vagrant stuff as expected without a reboot. see /etc/rc.local for the fix. Closed by commit 4881de0
even when there isn't a kernel-devel package that matches the kernel version.
two possible paths on failure for exact match kernel devel:
install the next most recent kernel-devel package. Maybe centos only updates it when there is a change that requires it? So possibly older kernel-devel packages would work? Requires investigation on how releases are managed for kernel-devel
Install a full kernel source package as described in this centos wiki article. This will probable lengthen our "vagrant up" time.