Sure!
I’m really stumped and can’t really figure out what’s happening, so any new approaches/tests/insights are welcome!
I realise this isn’t all that “minimal” of a Vagrantfile (or comment), but I wanted to disclose that it’s the contents of the Vagrantfile created by this tutorial, Initialize a Project Directory | Vagrant | HashiCorp Developer, which is a mostly commented out Vagrantfile referencing hashicorp/bionic64 as the VM to use.
Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
# The most common configuration options are documented and commented below.
# For a complete reference, please see the online documentation at
# https://docs.vagrantup.com.
# Every Vagrant development environment requires a box. You can search for
# boxes at https://vagrantcloud.com/search.
config.vm.box = "hashicorp/bionic64"
# Disable automatic box update checking. If you disable this, then
# boxes will only be checked for updates when the user runs
# `vagrant box outdated`. This is not recommended.
# config.vm.box_check_update = false
# Create a forwarded port mapping which allows access to a specific port
# within the machine from a port on the host machine. In the example below,
# accessing "localhost:8080" will access port 80 on the guest machine.
# NOTE: This will enable public access to the opened port
# config.vm.network "forwarded_port", guest: 80, host: 8080
# Create a forwarded port mapping which allows access to a specific port
# within the machine from a port on the host machine and only allow access
# via 127.0.0.1 to disable public access
# config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1"
# Create a private network, which allows host-only access to the machine
# using a specific IP.
# config.vm.network "private_network", ip: "192.168.33.10"
# Create a public network, which generally matched to bridged network.
# Bridged networks make the machine appear as another physical device on
# your network.
# config.vm.network "public_network"
# Share an additional folder to the guest VM. The first argument is
# the path on the host to the actual folder. The second argument is
# the path on the guest to mount the folder. And the optional third
# argument is a set of non-required options.
# config.vm.synced_folder "../data", "/vagrant_data"
# Provider-specific configuration so you can fine-tune various
# backing providers for Vagrant. These expose provider-specific options.
# Example for VirtualBox:
#
# config.vm.provider "virtualbox" do |vb|
# # Display the VirtualBox GUI when booting the machine
# vb.gui = true
#
# # Customize the amount of memory on the VM:
# vb.memory = "1024"
# end
#
# View the documentation for the provider you are using for more
# information on available options.
# Enable provisioning with a shell script. Additional provisioners such as
# Ansible, Chef, Docker, Puppet and Salt are also available. Please see the
# documentation for more information about their specific syntax and use.
# config.vm.provision "shell", inline: <<-SHELL
# apt-get update
# apt-get install -y apache2
# SHELL
end
Procedure
-
vagrant up && vagrant ssh, wait for box to start and connect to the guest -
sudo journalctl, search for “mount” and notice no issues are reported -
ls /vagrant, notice that files are accessible without issues - Disconnect from the guest
-
vagrant halt && vagrant up && vagrant ssh, wait for box to restart and connect to the guest -
sudo journalctl, search for “mount” and notice that there are now issues with the/vagrantmount, see below-
Mar 14 09:30:19 vagrant systemd[1]: Started Wait for Network to be Configured. Mar 14 09:30:19 vagrant systemd[1]: Reached target Network is Online. Mar 14 09:30:19 vagrant systemd[1]: Reached target Remote File Systems (Pre). Mar 14 09:30:19 vagrant systemd[1]: Starting Availability of block devices... Mar 14 09:30:19 vagrant systemd[1]: Mounting /vagrant... Mar 14 09:30:19 vagrant systemd[1]: Starting OpenBSD Secure Shell server... Mar 14 09:30:19 vagrant systemd[1]: Started Availability of block devices. Mar 14 09:30:19 vagrant mount[917]: /sbin/mount.vboxsf: shared folder '/vagrant' was not found (check VM settings / spelling) Mar 14 09:30:19 vagrant kernel: vboxsf: g_fHostFeatures=0x8000000f g_fSfFeatures=0x1 g_uSfLastFunction=29 Mar 14 09:30:19 vagrant kernel: vboxsf: Successfully loaded version 7.0.6 r155176 Mar 14 09:30:19 vagrant kernel: vboxsf: Successfully loaded version 7.0.6 r155176 on 4.15.0-58-generic SMP mod_unload (LINUX_VERSION_CODE=0x40f12) Mar 14 09:30:19 vagrant kernel: vboxsf: SHFL_FN_MAP_FOLDER failed for '/vagrant': share not found Mar 14 09:30:19 vagrant kernel: vbsf_read_super_aux err=-6 Mar 14 09:30:19 vagrant systemd[1]: vagrant.mount: Mount process exited, code=exited status=1 Mar 14 09:30:19 vagrant systemd[1]: vagrant.mount: Failed with result 'exit-code'. Mar 14 09:30:19 vagrant systemd[1]: Failed to mount /vagrant. Mar 14 09:30:19 vagrant systemd[1]: Dependency failed for Remote File Systems. Mar 14 09:30:19 vagrant systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.
-
-
ls /vagrant, notice that files are accessible without issues
Problems that are caused by /vagrant not mounting correctly
The problem with the mounting issue presented in journalctl at step 6 means that services installed that rely on local-fs.target remote-fs.target to succeed, automatically fail to run/start. Percona is one such service that I experience this specific issue with.
System information
Host
- Ubuntu 20.04.5
$ VBoxManage --version
7.0.6r155176
Guest
- Ubuntu 18.04.3
$ VBoxClient --version
7.0.6r155176
(getting VBoxClient to work in this case required installing sudo apt install libxt6 libxmu6), but there was no change regarding the /vagrant-mounting failure presented in sudo journalctl after libx* installation and restarting the box again.
Additional observations
During the first vagrant up run (step 1 above), there are a few errors and warnings such as
...
Removing installed version 6.0.10 of VirtualBox Guest Additions...
update-initramfs: Generating /boot/initrd.img-4.15.0-58-generic
/opt/VBoxGuestAdditions-7.0.6/bin/VBoxClient: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
/opt/VBoxGuestAdditions-7.0.6/bin/VBoxClient: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
...
and
...
VirtualBox Guest Additions: Running kernel modules will not be replaced until
the system is restarted
An error occurred during installation of VirtualBox Guest Additions 7.0.6. Some functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
Unmounting Virtualbox Guest Additions ISO from: /mnt
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 6.0.10
VBoxService inside the vm claims: 7.0.6
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 6.0.10
VBoxService inside the vm claims: 7.0.6
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 6.0.10
VBoxService inside the vm claims: 7.0.6
Going on, assuming VBoxService is correct...
Restarting VM to apply changes...
...
But, what’s also notable is that during the first vagrant up run (step 1 above), there is no mention of the /vagrant-mount causing any problems. It’s the subsequent runs (step 5 above) that presents those. And the /vagrant-mount consistently work, as in, I can access the files from within the guest no matter step 1 or 5.