Closed troyjfarrell closed 2 years ago
Thanks. This sounds good though I feel out of my depth here. I'll test it as soon as I can. And also cc: @zenhack
Do you know which sorts of flavors of development VMs are and aren't affected by this?
This bug affects two of three diy
VMs that I tested. (I only have diy
VMs.) One of the two encounters the problem 50% of the time. The second encounters the problem 90% of the time.
I don't understand why I need it for /host-dot-sandstorm
but not for /opt/app
. I think the most likely explanation is a race condition, but I have no evidence for that.
I sent the PR because it solved a long-standing problem for me and I hoped that it would help others. But if it's only happening on my system, you can close and ignore it.
Are you using a different base box by chance?
Fwiw, I've sometimes seen mount problems trying to boot up a pre-existing vm, which I've solved by just blowing away the vm, starting from scratch, and making a mental note to investigate someday. This is probably the cause.
I think this could use a comment explaining what all this is about, but otherwise LGTM.
Did a bit of testing with a project I am working on from a Windows machine, and this didn't throw any issues my way.
Adding the automount option fixes a dependency cycle that can cause Sandstorm to fail to start on boot for some development VMs.
The
host\x2ddot\x2dsandstorm.mount
is wanted by theremote-fs.target
, however it needs thevirtualbox-guest-utils.service
to mount successfully. Thevirtualbox-guest-utils.service
can be made to run beforeremote-fs.target
, but I have never managed to make it be ready for mounting Virtualbox Synced Folders at boot time. It complains of shared memory errors. All of this causes theremote-fs.target
to fail, which causessandstorm.service
to fail to start at boot time.This solution enables the automount option.
/host-dot-sandstorm
is instead no longer required for completion of theremote-fs.target
and is mounted on demand forvagrant-spk
. Everyone is happy.