Hmm, it’s not a good solution to disable synced folders, as you do need that functionality sometimes; especially with the /vagrant folder that gets shared in the guest.
Maybe one time we could chat on Discord or something to try and resolve it. In the mean time, it seems like it’s causing you a lot of hassle and maybe you should revert back to Virtualbox. Better in the long term though to get libvirt and qemu working.
Oh, so this is a consequence of disabling nfs?
Sorry, I think the issue with the USB device not being accessible in the VM is a separate issue from shared folders.
When I spoke about disabling synced folders, I was referring to this:
That’s disabling the synced folder regardless of whether it’s done using rsync or NFS.
It would be better in general if you could get synced folders working with libvirt. It wasn’t an issue that came up for me.
Edit: you could actually try this:
config.vm.synced_folder '.', '/vagrant', type: rsync
Just to see if that forces Vagrant to use rsync. Normally I think rsync would be used by default and you would need to explicitly tell it to use NFS.
I’ve got this
config.vm.synced_folder '.', '/vagrant', type: 'rsync',
rsync__exclude: '.git/'
But the error remains the same.
Switched SD card reader, bought new SD card, still the same.
Sorry, I wasn’t expecting that specifying the type as rsync would solve the problem with the USB device. I was just curious if it would solve the problem with the shared folders.
If it’s USB device issue is not caused by rsync/nfs, then what is?
The Guest OS? The Guest OS Linux kernel?
[update]
Tried generic/arch box, no USB problem whatsoever.
So it seems to be related to the box.
Looks like I will have to learn how to create Vagrant boxes.
Just an update to vagrant boxes. I’m unable to build a working box as I’m currently waiting for this issue to resolve:
In the meantime, could you use an existing base box? Constructing your own boxes is useful as a learning exercise, and also when the vagrant up takes too long to run each time, but for most situations it’s ok to use an existing base box and bootstrap with that.
For this situation I would say there is no existing base box good enough, making ‘constructing my own box’ much more than just a learning exercise.
If Zelec/Manjarobox would actually not have NFS and especially USB device issues, I would have accepted it. But it does have these issues and thus we’re stuck until the qemu plugin bug is fixed.
If all this is true, why bother with Manjaro at all?
Or am I missing something?
I have been very distracted and have not moved on much with Ubuntu/Vagrant. But it does look more promising.
Fair enough 
Though there may be similar Debian/Ubuntu tools to do the same, I just havent looked hard yet
I had a look at your guide again. Just wanted to mention a few things.
It should be possible to use the Vagrantfile to define the USB device to be added, rather than having to use the virt-manager GUI. Anything that’s exposed in the GUI should have an equivalent command in the virsh CLI. In fact, I can see an attach-device command in virsh. In turn, you can then generally define that in the Vagrantfile.
The vagrant-libvirt plugin has some documentation on using USB devices.
If it wasn’t possible to do it with Vagrant, you could do it as a post vagrant up step using virsh.
I had a look at that manjaro-arm-installer. It’s actually just a Bash script and is available in their Gitlab repo. They are just using the GUI to collect some user input, but that wouldn’t be necessary. If I had time, I would look at the script and extract the stuff that builds the install, then just provide all the necessary information via arguments to the script, rather than collecting it from a GUI. That would mean you could do an unattended installation.
I’m also fairly sure you could build the install with a container too, if you removed the GUI from the script.
Latest update here.
There were still some errors in my vagrant box script that I fixed and it builds, but does not produce a box.
I’m not sure what the cause is, but running the build makes me run too low on RAM and so I suspect that I need to replace my motherboard in order for it to work. My current one can only support 8GB of RAM max, which is very very low.
I ordered a new motherboard, but it turns out the store is out of stock for the particular one I bought and so I will have to wait for a week until it arrives.
Yes, I know. It’s the most complete one that I know of though. It probably can be adjusted to install Manjaro OS with safenet-node installed.
What about systemd-nspawn?
I’m also expecting the safe network to become popular and for sure there will be multiple people accidentally choosing /dev/sda on docker by mistake. When it happens on a virtual machine, especially on QEMU with a /dev/vda to make the distinction clear, that is not going to be an issue.
The important thing would be removing the user input for the installation. It’s pretty trivial to install sn_node, so I wouldn’t worry about putting that in the VM image. It would also go out of date quite quickly as new versions of sn_node are released.
I think it would be good also if you offered users of this guide an alternative to Manjaro, that wouldn’t involve using a VM to flash the SD card for the Pi. For example, it’s really easy to just flash Ubuntu onto the SD card, from either a Windows or Linux host.
The sn node docker container I made already automatically downloads the latest version of sn_node by looking up github json files.
I’ll look into that once I finish this guide.
The issue with that is that sn_node and sn_cli latest versions are not always playing nice together
Ideally we want a script which asks which versions you want. – Accompanied of course by a regular post saying which versions have been proven to play nice together…
I solved the nfs issue.
It seems this issue only happens on Manjaro.
In /etc/nfs.conf uncomment the line:
[nfsd]
udp=y
and then restart nfs:
sudo systemctl restart nfs-server.service