New answers tagged fstab
The mount point target: /vagrant and /vagrant/Downloads is itself not available at booting time. /vagrant is a mount point itself, which is introduced by vagrant tool right after the virtual machine boot finished. Changing fstab to: //192.168.0.99/download /mnt/Downloads cifs credentials=/root/.smbcredentials,auto,_netdev 0 0 did the trick of ...
The network might not yet be initialized at this point. You can add _netdev to the mount options. This will delay the mount until the network is connected. //192.168.0.99/download /vagrant/Downloads cifs credentials=/root/.smbcredentials,_netdev,auto 0 0
I replaced nobootwait with nofail. It is not a great solution but it is the only one presently available to us.
It looks like that option isn't supported. I would just remove it and see what happens, then look at the fstab(5) documentation for the cloudstack derivative.
No, it's not a common practice at all. Ask yourself this: "How do I know all the required filesystems are mounted?" Or better yet, ask yourself: "How would somebody else know all the required filesystems are mounted?" For example, it's not inconceivable there's a /var, /home, and so on that should be mounted, but isn't and you're writing directly to the ...
The problem was that the second cloud-init configuration (used to start the production instance on step 3 of the OP) contained a small mounts section to mount an additional instance specific volume. When cloud-init encounters a mounts section, it does not append any found configuration to the current fstab, instead it overrides whatever cloud-init setup an ...
Top 50 recent answers are included