dangling symlink /usr/bin/vmware-user

Bug #1807441 reported by Scott Moser
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
open-vm-tools (Ubuntu)
Fix Released
Low
Unassigned
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Undecided
Unassigned

Bug Description

[Impact]

 * An explanation of the effects of the bug on users and

 * justification for backporting the fix to the stable release.

 * In addition, it is helpful, but not required, to include an
   explanation of how the upload fixes this bug.

[Test Case]

 * Install open-vm-tools but not open-vm-tools-desktop
 * $ dpkg-query --show open-vm-tools
     open-vm-tools 2:10.3.0-0ubuntu1~18.04.3
   $ dpkg -S /usr/bin/vmware-user
     open-vm-tools: /usr/bin/vmware-user
   $ ls -l /usr/bin/vmware-user
     lrwxrwxrwx 1 root root 24 Oct 10 11:25 /usr/bin/vmware-user
       -> vmware-user-suid-wrapper
   $ ls -l /usr/bin/vmware-user-suid-wrapper
     ls: cannot access '/usr/bin/vmware-user-suid-wrapper':
     No such file or directory
 * That above is the dangling symlink which would be resolved manually by
   an install of open-vm-tools-desktop (but we don't want)
 * After the upgrade the source AND target of the symlink should be part
   of open-vm-tools-desktop so without it being installed it should not
   exists and with it installed it should exist and point to an existing
   file

[Regression Potential]

 * THe regression I could think of is if people manually fixed up the
   symlink and the update changing that, but this isn't meant to be a
   conffile or conf-symlink in that sense - so I'd not expect that case to
   be real and valid in the field.

[Other Info]

 * n/a

---
Original report

$ dpkg-query --show open-vmware-tools
dpkg-query: no packages found matching open-vmware-tools
$ dpkg-query --show open-vm-tools
open-vm-tools 2:10.3.0-0ubuntu1~18.04.3
$ dpkg -S /usr/bin/vmware-user
open-vm-tools: /usr/bin/vmware-user
$ ls -l /usr/bin/vmware-user
lrwxrwxrwx 1 root root 24 Oct 10 11:25 /usr/bin/vmware-user -> vmware-user-suid-wrapper
$ ls -l /usr/bin/vmware-user-suid-wrapper
ls: cannot access '/usr/bin/vmware-user-suid-wrapper': No such file or directory

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-vm-tools 2:10.3.0-0ubuntu1~18.04.3
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Fri Dec 7 19:17:38 2018
ProcEnviron:
 TERM=screen-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
SourcePackage: open-vm-tools
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Scott Moser (smoser) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks Scott,
the target of the link is actually content of open-vm-tools-desktop.
Once that is installed the symlink is ok.

We don't want a dependency from open.-vm-tools to open-vm-tools-desktop.
Instead the right solution is to move the symlink to open-vm-desktop as well.

This is old - way back in 2014 2:9.4.6-1770165-2 moved the man page for example.
It always works vice versa as the -desktop package depends on the base.

Changed in open-vm-tools (Ubuntu):
status: New → Triaged
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

patch is trivial and build worked, I'll be posting it to Debian ...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Changed in open-vm-tools (Ubuntu):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package open-vm-tools - 2:10.3.5-2

---------------
open-vm-tools (2:10.3.5-2) unstable; urgency=medium

  [ Raphaël Hertzog ]
  * [db2a364] Ensure vmwgfx module is loaded before start of vmtoolsd.
    This avoids a failure to start the resolutionKMS plugin and it's
    achieved through a drop-in snippet extending open-vm-tools.service
    adding an ExecStartPre directive loading the module prior to
    the start of the service. (Closes: #915031)

  [ Christian Ehrhardt ]
  * [e6e0ab8] d/rules: fix dangling symlink of vmware-user.
    Back in 2:9.4.0-1280544-6 vmware-user* was moved to the
    open-vm-tools-desktop package and some follow on fixes moved bits that
    were forgotten like the man page.
    (LP: #1807441)
    There still is a symlink in /usr/bin/vmware-user that is forgotten in
    the base package and broken unless open-vm-tools-desktop is installed.
    Change d/rules to move the symlink as well.
    Signed-off-by: Christian Ehrhardt <email address hidden>
  * [13d22e5] Breaks and Replaces for moving vmware-user.
    Signed-off-by: Christian Ehrhardt <email address hidden>
  * [d56826a] Bump breaks and replaces to next version to be released.
    Signed-off-by: Christian Ehrhardt <email address hidden>

  [ Bernd Zeimetz ]
  * [e4697c7] Fix race condition between open-vm-tools and systemd-tmpfiles-setup.
    Thanks to Jean-Louis Dupond (Closes: #914910)

 -- Bernd Zeimetz <email address hidden> Tue, 11 Dec 2018 20:40:48 +0100

Changed in open-vm-tools (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote : Proposed package upload rejected

An upload of open-vm-tools to cosmic-proposed has been rejected from the upload queue for the following reason: "needs a separate SRU bug for the debian/desktop.conf addition. Also, upload fails to comply with https://wiki.ubuntu.com/DebianMaintainerField".

Revision history for this message
Steve Langasek (vorlon) wrote :

An upload of open-vm-tools to bionic-proposed has been rejected from the upload queue for the following reason: "needs a separate SRU bug for the debian/desktop.conf addition. Also, upload fails to comply with https://wiki.ubuntu.com/DebianMaintainerField".

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

This issue was part of the regular backport of stable releases but I missed to put the full SRU prep and Templates to the bug, doing so now ...

Changed in open-vm-tools (Ubuntu Bionic):
status: New → Confirmed
Changed in open-vm-tools (Ubuntu Cosmic):
status: New → Confirmed
description: updated
Changed in open-vm-tools (Ubuntu Bionic):
status: Confirmed → Triaged
Changed in open-vm-tools (Ubuntu Cosmic):
status: Confirmed → Triaged
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Added an SRU Template here as well, while we did drive this more as an MRE in the past while I was cleaning up on Steve's request lets make all related bugs proper SRUs to be sure on the next round.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

After improving on what we have found triggered by the first SRU review this is ready again.
Changes:
- Despite being an MRE in general all associated individual bugs have full SRU templates now.
- maintainers correctly updated
- The change to the vgauth Dependencies is now safer

That said, this is uploaded to Bionic/Cosmic unapproved again and waiting for SRU Team re-review.

Revision history for this message
Steve Langasek (vorlon) wrote : Please test proposed package

Hello Scott, or anyone else affected,

Accepted open-vm-tools into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-vm-tools/2:10.3.5-7~ubuntu0.18.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in open-vm-tools (Ubuntu Cosmic):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Revision history for this message
Steve Langasek (vorlon) wrote :

Hello Scott, or anyone else affected,

Accepted open-vm-tools into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-vm-tools/2:10.3.5-7~ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in open-vm-tools (Ubuntu Bionic):
status: Triaged → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Pre update - the link can be broken by belonging to different packages with no hard dep.

ubuntu@node-2:~$ ls -l /usr/bin/vmware-user
lrwxrwxrwx 1 root root 24 Oct 10 11:25 /usr/bin/vmware-user -> vmware-user-suid-wrapper
ubuntu@node-2:~$ dpkg -S /usr/bin/vmware-user-suid-wrapper /usr/bin/vmware-user
open-vm-tools-desktop: /usr/bin/vmware-user-suid-wrapper
open-vm-tools: /usr/bin/vmware-user

After the update the link is always good by belonging to the same package:
$ dpkg -S /usr/bin/vmware-user-suid-wrapper /usr/bin/vmware-user
open-vm-tools-desktop: /usr/bin/vmware-user-suid-wrapper
open-vm-tools-desktop: /usr/bin/vmware-user

Setting verified

tags: added: verification-done-bionic
removed: verification-needed-bionic
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Ran the same on cosmic, which other than dates in the log does not differ at all.
Setting verified as well.

tags: added: verification-done verification-done-cosmic
removed: verification-needed verification-needed-cosmic
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.1 KiB)

This bug was fixed in the package open-vm-tools - 2:10.3.5-7~ubuntu0.18.10.1

---------------
open-vm-tools (2:10.3.5-7~ubuntu0.18.10.1) cosmic; urgency=medium

  * Backport recent open-vm-tools (LP: #1813944)
    - also adresses handling of quiesced snapshot failures (LP: #1814832)
    - also adresses issues with resolutionKMS plugins sometimes fails to
      load at boot (LP: #1818473)

open-vm-tools (2:10.3.5-7) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [71b468f] make vgauth service execution more reliable.
    Since d3d47039 "Start vgauth before vmtoolsd" there is a potential race
    of starting vgauth so early that it might have issues. This was
    discussed back in the day in [1] to [2], but confirmed to be ok by
    VMWare.
    We were all somewhat convinced by this, but a bad feeling remained not
    only with me but also with Bernd [4].
    A recent SRU review denial made me rethink all of it and I think we can
    make it safer without thwarting the purpose of the original change.
    Note: Disambiguation of service names used below:
    vgauth - open-vm-tools.vgauth.service
    vmtoolsd - open-vm-tools.service
    fs - systemd-remount-fs.service
    tmp - systemd-tmpfiles-setup.service
    cloud-init - cloud-init-local.service
    Currently we have these dependency requirements:
    - vgauth should be before vmtoolsd
    - cloud init should be before vmtoolsd
    - cloud init has to be really early in general
      - therefore this is using DefaultDependencies=No
    That lead to this graph:
     fs / tmp -> vmtoolsd -> cloud-init
    And d3d47039 added it to be like:
     fs / tmp -> vmtoolsd -> cloud-init
                   ^
     vgauth --|
    But there is no need to have vgauth without any pre-dependencies at all.
    It is only needed to be "before" vmtoolsd, therefore we can make it:
     fs / tmp -> vgauth -> vmtoolsd -> cloud-init
    That will make execution of vgauth much less error-prone (even though I
    have no hard issue to report) while at the same time holding up all
    known required ordering constraints.
    [1]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1804287/comments/3
    [2]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1804287/comments/12
    [3]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1804287/comments/25
    [4]: https://github.com/bzed/pkg-open-vm-tools/pull/15#issuecomment-447237910
    Signed-off-by: Christian Ehrhardt <email address hidden>

open-vm-tools (2:10.3.5-6) unstable; urgency=medium

  * [43ec618] Correct and/or improve handling of certain quiesced
    snapshot failures.
    Thanks to Oliver Kurth (Closes: #921470)

open-vm-tools (2:10.3.5-5) unstable; urgency=medium

  * [54cce3e] Start vmtoolsd after apparmor.service.
    Github issue #17

open-vm-tools (2:10.3.5-4) unstable; urgency=medium

  [ Alf Gaida ]
  * [e13792d] udevadm trigger should not fail (Closes: #917642)

open-vm-tools (2:10.3.5-3) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [d3d4703] Start vgauth before vmtoolsd.
    VGAuthService needs to be ready when vmtoolsd runs. Certain cases - e.g.
    Site Reco...

Read more...

Changed in open-vm-tools (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for open-vm-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.1 KiB)

This bug was fixed in the package open-vm-tools - 2:10.3.5-7~ubuntu0.18.04.1

---------------
open-vm-tools (2:10.3.5-7~ubuntu0.18.04.1) bionic; urgency=medium

  * Backport recent open-vm-tools (LP: #1813944)
    - also adresses handling of quiesced snapshot failures (LP: #1814832)
    - also adresses issues with resolutionKMS plugins sometimes fails to
      load at boot (LP: #1818473)

open-vm-tools (2:10.3.5-7) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [71b468f] make vgauth service execution more reliable.
    Since d3d47039 "Start vgauth before vmtoolsd" there is a potential race
    of starting vgauth so early that it might have issues. This was
    discussed back in the day in [1] to [2], but confirmed to be ok by
    VMWare.
    We were all somewhat convinced by this, but a bad feeling remained not
    only with me but also with Bernd [4].
    A recent SRU review denial made me rethink all of it and I think we can
    make it safer without thwarting the purpose of the original change.
    Note: Disambiguation of service names used below:
    vgauth - open-vm-tools.vgauth.service
    vmtoolsd - open-vm-tools.service
    fs - systemd-remount-fs.service
    tmp - systemd-tmpfiles-setup.service
    cloud-init - cloud-init-local.service
    Currently we have these dependency requirements:
    - vgauth should be before vmtoolsd
    - cloud init should be before vmtoolsd
    - cloud init has to be really early in general
      - therefore this is using DefaultDependencies=No
    That lead to this graph:
     fs / tmp -> vmtoolsd -> cloud-init
    And d3d47039 added it to be like:
     fs / tmp -> vmtoolsd -> cloud-init
                   ^
     vgauth --|
    But there is no need to have vgauth without any pre-dependencies at all.
    It is only needed to be "before" vmtoolsd, therefore we can make it:
     fs / tmp -> vgauth -> vmtoolsd -> cloud-init
    That will make execution of vgauth much less error-prone (even though I
    have no hard issue to report) while at the same time holding up all
    known required ordering constraints.
    [1]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1804287/comments/3
    [2]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1804287/comments/12
    [3]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1804287/comments/25
    [4]: https://github.com/bzed/pkg-open-vm-tools/pull/15#issuecomment-447237910
    Signed-off-by: Christian Ehrhardt <email address hidden>

open-vm-tools (2:10.3.5-6) unstable; urgency=medium

  * [43ec618] Correct and/or improve handling of certain quiesced
    snapshot failures.
    Thanks to Oliver Kurth (Closes: #921470)

open-vm-tools (2:10.3.5-5) unstable; urgency=medium

  * [54cce3e] Start vmtoolsd after apparmor.service.
    Github issue #17

open-vm-tools (2:10.3.5-4) unstable; urgency=medium

  [ Alf Gaida ]
  * [e13792d] udevadm trigger should not fail (Closes: #917642)

open-vm-tools (2:10.3.5-3) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [d3d4703] Start vgauth before vmtoolsd.
    VGAuthService needs to be ready when vmtoolsd runs. Certain cases - e.g.
    Site Reco...

Read more...

Changed in open-vm-tools (Ubuntu Bionic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.