Shared folders cannot be mounted in ubuntu/cosmic64 due to missing vbox modules

Just tried latest version and still has same error;
ubuntu/cosmic64 (virtualbox, 20181008.0.0)

Same error seen as;
ubuntu/cosmic64 (virtualbox, 20181006.0.0)

Hi John,

Thanks for using Ubuntu, and thanks for filing this bug. I can reproduce this locally, and I'm now digging in to what the root cause might be.

Thanks!

Dan

It looks like the appropriate modules are no longer shipped in the linux-modules-...-generic package (which is where they were in bionic); I'm following up with the kernel team to check if there's an existing bug to track this or if I need to file a new one (or repurpose this one).

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1796647

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

ProblemType: Bug
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Oct 9 16:18 seq
 crw-rw---- 1 root audio 116, 33 Oct 9 16:18 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: N/A
DistroRelease: Ubuntu 18.10
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: innotek GmbH VirtualBox
Package: linux (not installed)
ProcEnviron:
 LC_CTYPE=C.UTF-8
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
 SHELL=/bin/bash
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-8-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
ProcVersionSignature: Ubuntu 4.18.0-8.9-generic 4.18.7
RelatedPackageVersions:
 linux-restricted-modules-4.18.0-8-generic N/A
 linux-backports-modules-4.18.0-8-generic N/A
 linux-firmware N/A
RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
Tags: cosmic uec-images
Uname: Linux 4.18.0-8-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.board.name: VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
dmi.product.family: Virtual Machine
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

My understanding of the issue after an IRC conversation with sforshee is that the modules were intentionally dropped from the kernel packages, but the corresponding Provides of virtualbox-guest-modules was _not_ dropped from the kernel packaging. This means that when we install virtualbox-guest-utils during image build, it sees the modules as already available so does nothing. (Instead, it should have to fulfil the dependency some other way, probably by installing the DKMS packages which build the drivers).

So I just go "vagrant init ubuntu/cosmic64 && vagrant up"... which works for all other vagrant I'm wanting to use.

Does this mean the cosmic64 box needs to be fixed, or are you suggesting everyone needs to do custom config in their Vagrantfile to get it working?

The box certainly needs to be fixed.

(In the meantime, a workaround if you _really_ need a cosmic box is probably to manually install the virtualbox-guest-dkms package; I haven't tested this locally though.)

As I saw cosmic64 box available so I thought test it out. Using my standard vagrant examples to see if they all still work or no on cosmic. I'm in the process of setting up jenkins instance to check for available box updates for the examples I've setup, then rebuild and see if the examples still work.

Hi John,

I've just tested with the latest Vagrant box, and this looks good to me now:

$ vagrant box update
==> default: Checking for updates to 'ubuntu/cosmic64'
    default: Latest installed version: 20181008.0.0
    default: Version constraints:
    default: Provider: virtualbox
==> default: Updating 'ubuntu/cosmic64' with provider 'virtualbox' from version
==> default: '20181008.0.0' to '20181014.0.0'...
==> default: Loading metadata for box 'https://vagrantcloud.com/ubuntu/cosmic64'
==> default: Adding box 'ubuntu/cosmic64' (v20181014.0.0) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/ubuntu/boxes/cosmic64/versions/20181014.0.0/providers/virtualbox.box
==> default: Successfully added box 'ubuntu/cosmic64' (v20181014.0.0) for 'virtualbox'!

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/cosmic64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/cosmic64' is up to date...
==> default: Setting the name of the VM: vagrant_default_1539625374537_90792
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => /home/daniel/scratch/vagrant

$ vagrant ssh -- ls /vagrant
Vagrantfile
ubuntu-cosmic-18.10-cloudimg-console.log

$ ls -1
ubuntu-cosmic-18.10-cloudimg-console.log
Vagrantfile

I'm going to mark this bug as Fix Released; if you continue to see this issue (after updating to the latest box!), please move it back to Confirmed. For any other issues, please file a new bug.

Thanks again for the report!

Cheers all,
Just updated myself and picked up '20181015.0.0' and vagrant up works cleanly.
John

On Tue, Oct 16, 2018 at 12:20:21PM -0000, John Patrick wrote:
> Cheers all,
> Just updated myself and picked up '20181015.0.0' and vagrant up works cleanly.
> John

Great, thanks for the confirmation!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug was erroneously marked for verification in bionic; verification is not required and verification-needed-bionic is being removed.