Virtual Box Shared Folder Drives Don't Automount in 16.04 to 18.04 upgraded Ubuntu MATE

Bug #1769453 reported by Hank Grabowski on 2018-05-06
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu MATE
Undecided
Unassigned

Bug Description

I first ran across this in one of my main VMs when I tried the update. Everything went great, I re-applied the guest additions and voilà my shared folder drives mounted and I was in business. The next day when I fired up the VM they were missing. It was a hectic day, so I thought perhaps I had remembered it working so I applied the guest additions again. The drives reappeared. This time I rebooted to confirm it stuck but sadly they did not. I’ve continued to do some experimenting and have come to discover that while they are there the systemd process doesn’t seem to want to start on reboot even though it is set to. So to fix it I just need to do the following command to get them to show up:

sudo systemctl restart vboxadd-service.service

I wasn’t having this problem on Ubuntu 18.04 or Ubuntu MATE 18.04 virgin machines so this was either a problem with the general Ubuntu 16.04 to 18.04 upgrade process or specific to Ubuntu MATE 16.04 to 18.04 upgrade. I therefore went about creating two brand new VMs, one each for mainline Ubuntu 16.04 and one for Ubuntu MATE 16.04 and then went through the upgrade process directly. Those steps are:

    Fresh install OS with 3rd party and upgrades turned on
    Follow https://virtualboxes.org/doc/installing-guest-additions-on-ubuntu/ for installing guest additions
    Shutdown/Power on
    Add user to the vboxsf group (sudo usermod -a -G vboxsf <username>)
    Restart
    Confirm Read/write access to shared folder drive
    Bring up System graphical updater, do any additional updates
    Invoke Upgrade to 18.04 through graphical system:
       sudo apt update && sudo apt dist-upgrade
       update-manager -d
    Perform upgrade and reboot
    See if shared folder drive there
    After Update re-apply kernel extensions
    Restart
    Confirm shared drive read/write access

I can repeatably show that mainline Ubuntu 16.04 goes through these updates without this artifact but the MATE version does not. Again, a fresh Ubuntu MATE 18.04 install doesn’t have this behavior at all.

Download full text (5.4 KiB)

> On May 6, 2018 at 7:52 AM Hank Grabowski <email address hidden> wrote:
>
>
> Public bug reported:
>
> I first ran across this in one of my main VMs when I tried the update.
> Everything went great, I re-applied the guest additions and voilà my
> shared folder drives mounted and I was in business. The next day when I
> fired up the VM they were missing. It was a hectic day, so I thought
> perhaps I had remembered it working so I applied the guest additions
> again. The drives reappeared. This time I rebooted to confirm it stuck
> but sadly they did not. I’ve continued to do some experimenting and
> have come to discover that while they are there the systemd process
> doesn’t seem to want to start on reboot even though it is set to. So to
> fix it I just need to do the following command to get them to show up:
>
> sudo systemctl restart vboxadd-service.service
>
> I wasn’t having this problem on Ubuntu 18.04 or Ubuntu MATE 18.04 virgin
> machines so this was either a problem with the general Ubuntu 16.04 to
> 18.04 upgrade process or specific to Ubuntu MATE 16.04 to 18.04 upgrade.
> I therefore went about creating two brand new VMs, one each for mainline
> Ubuntu 16.04 and one for Ubuntu MATE 16.04 and then went through the
> upgrade process directly. Those steps are:
>
> Fresh install OS with 3rd party and upgrades turned on
> Follow https://virtualboxes.org/doc/installing-guest-additions-on-ubuntu/ for installing guest additions
> Shutdown/Power on
> Add user to the vboxsf group (sudo usermod -a -G vboxsf <username>)
> Restart
> Confirm Read/write access to shared folder drive
> Bring up System graphical updater, do any additional updates
> Invoke Upgrade to 18.04 through graphical system:
> sudo apt update && sudo apt dist-upgrade
> update-manager -d
> Perform upgrade and reboot
> See if shared folder drive there
> After Update re-apply kernel extensions
> Restart
> Confirm shared drive read/write access
>
> I can repeatably show that mainline Ubuntu 16.04 goes through these
> updates without this artifact but the MATE version does not. Again, a
> fresh Ubuntu MATE 18.04 install doesn’t have this behavior at all.
>
> ** Affects: ubuntu-mate
> Importance: Undecided
> Status: New
>
>
> ** Tags: additions box guest ugrade virtual
>
> --
> You received this bug notification because you are subscribed to ubuntu-
> mate.
> Matching subscriptions: oldrocker99
> https://bugs.launchpad.net/bugs/1769453
>
> Title:
> Virtual Box Shared Folder Drives Don't Automount in 16.04 to 18.04
> upgraded Ubuntu MATE
>
> Status in ubuntu-mate:
> New
>
> Bug description:
> I first ran across this in one of my main VMs when I tried the update.
> Everything went great, I re-applied the guest additions and voilà my
> shared folder drives mounted and I was in business. The next day when
> I fired up the VM they were missing. It was a hectic day, so I
> thought perhaps I had remembered it working so I applied the guest
> additions again. The drives reappeared. This time I rebooted to
> confirm it stuck but sadly they did not. I’ve conti...

Read more...

Hank Grabowski (hgrabows) wrote :

Thank's for the suggestion. I use the default partitioning scheme with my installs but I understand your suggestion for making recovery easier. Since these are VMs I snapshot them before doing any update/upgrade. That way if the thing gets borked I can always roll back to the snapshot. However I am curious what is causing the problem. I was thinking of mounting both drives in another place and diffing them to see what the file system differences are between a Virgin 16.04 converted to 18.04 and a virgin 18.04 installation would be.

Alexandr O (final12345) wrote :

Should to check systemd unit dependencies.
See this answer
https://superuser.com/a/1349958/934811

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers