Ubuntu Desktop Artful 17.10 needs reboot to validate open-vm-tools usage

[[e-mail]]

When install open-vm-tools in Ubuntu Desktop 17.10 VM, there are 2 problems.
1) Could not get lock /var/lib/dpkg/lock
------Actual Result------
# apt update
# apt install open-vm-tools
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
# rm /var/lib/dpkg/lock

After delete, the installation can be continued.

------Expected Result------
Have no this prompt.

2) Need to reboot after install open-vm-tools
------Actual Result------
# vmtoolsd -v
VMware Tools daemon, version 10.2.0.1608 (build-7253323)
# ps ax | grep vm
  608 ? Ss 0:00 avahi-daemon: running [vmware-virtual-machine-3.local]
 3723 pts/1 S+ 0:00 grep --color=auto vm

# reboot
......
# ps ax | grep vm
  358 ? Ssl 0:00 /usr/bin/vmtoolsd ---------------------> vmtoolsd is running.
  484 ? Ss 0:00 avahi-daemon: running [vmware-virtual-machine-3.local]
 1836 pts/1 S+ 0:00 grep --color=auto vm

# ps ax | grep -i vg
  476 ? Ss 0:00 /usr/bin/VGAuthService ---------------------> vgauth is running.
 1838 pts/1 S+ 0:00 grep --color=auto -i vg

------Expected Result------
It doesn't need to reboot to validate the open-vm-tools usage.

The other Ubuntu VMs are also tested, but they have no these 2 problems, such as:
* Ubuntu Server 17.10
* Ubuntu Desktop 16.04.4
* Ubuntu Server 16.04.4
* Ubuntu Desktop 18.04
* Ubuntu Server 18.04

It is also stated in https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1741390/comments/75.

# lsb_release -rd
Description: Ubuntu 17.10
Release: 17.10
# apt-cache policy open-vm-tools
open-vm-tools:
  Installed: 2:10.2.0-3~ubuntu0.17.10.1
  Candidate: 2:10.2.0-3~ubuntu0.17.10.1
  Version table:
 *** 2:10.2.0-3~ubuntu0.17.10.1 500
        500 http://cn.archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2:10.1.10-3 500
        500 http://cn.archive.ubuntu.com/ubuntu artful/main amd64 Packages

If need any other information, please kindly tell me.

Thanks!
Yanhui

[Christian Ehrhardt  (paelzer)]

#1 is due to the system updating right after being spawned
   You could just wait and it would resolve, not an issue

Looking at #2 now ...

[Christian Ehrhardt  (paelzer)]

For #2, do I understand you correctly that this really is good on all releases/editions except 17.10-Desktop ?

AFAIK the package should be pre-installed on that image.
Oh I see, it is part of the ubuntu-server task, so it is pre-installed on server, but might not be on -desktop.

To reproduce what you see, how exactly do you drive the 17.10-Desktop Image test?
I assume you do:
1. start VMware
2. create new guest based on the 17.10-Dekstop ISO
3. vmware guest auto-config installs 17.10 onto the virtual disk
4. the system reboots after install
5. then you install open-vm-tools and see vmtoolsd not running

Is the above correct?

[[e-mail] (yanhuih)]

Hi Christian,

> For #2, do I understand you correctly that this really is good on all releases/editions except 17.10-Desktop ?
Yes, in testing in Ubunutu 16.04, 17.10 and 18.04, there is only 17.10 Desktop needs reboot.

> Is the above correct?
Yes, I did the steps as you said.

If need any other information, please kindly tell me!

Thanks!
Yanhui

[Christian Ehrhardt  (paelzer)]

With the confirmation above I installed 18.04 Desktop and 17.10 Desktop to check the situation on my own.
My current assumption that this would only apply to -Desktop installations because it is not on the seed would be the same for both, so it will be interesting what I find.

I had to do that on a remote server, that plus the graphical UI usually used by VMware slows this task down a bit :-/

[Christian Ehrhardt  (paelzer)]

Hi,
even with 17.10-Desktop image.
Installing open-vm-tools works fine and starts right after it installs.

I attached a screnshot of it.

[Christian Ehrhardt  (paelzer)]

Hi Yanhuih,
So this was either a one-off case or a broken setup.

You mentioned that you had to delete /var/lib/dpkg/lock.
That usually just means there is an apt process running, probably updates in the background right after install.
Maybe (but even that is unlikely) this affected your case (you should never need to delete that file).

For a normal case installing vm tools it seems to work just fine.
Setting incomplete unless we find a reproducible way that proves this is a real issue and not just an accident or misconfiguration.

Does this happen every time to you?
If it does, is this driven by a script and might just check too fast after install while it is still starting up?
Anything else that might help to understand why you see this?

[[e-mail] (yanhuih)]

Hi Christian,

I have tested more than 5 times today and everything is OK.:p

But I encountered it all 3 times last week.

The only difference I know is the ESXi Host Server version, because we updated it every week.

Since it's OK, please kindly close this bug.

Thanks!
Yanhui

[Christian Ehrhardt  (paelzer)]

Thanks for the feedback, closing.