So after I solved the kernel related problem which was very likely caused by my uninstalling vmware-tools-daemon, the vmware-tools-daemon error at start appears again.
I don’t use vmware but virtualbox. So I prefer to have the vmware uninstalled, especially it gives an error saying the daemon failed every time I boot up the machine.
However, it seems it bundles with the main kernel as when you uninstall it, you uninstall the main kernel, and when you install your kernel it installs vmware tools.
For the moment, I only have the daemon disabled using Yast-service management. Anyway, I think people should be able to uninstall vmware when they don’t use it?
I don’t have that package installed here, and I don’t even find it in any of my configured repos:
wolfi@amiga:~> zypper se -s vmware
Daten des Repositories laden ...
Installierte Pakete lesen ...
S | Name | Typ | Version | Arch | Repository
--+-------------------+-------+--------------+--------+-------------------
i | xf86-video-vmware | Paket | 13.0.1-2.1.2 | x86_64 | openSUSE-13.1-1.10
v | xf86-video-vmware | Paket | 13.0.1-2.1.2 | i586 | openSUSE-13.1-1.10
wolfi@amiga:~>
So please post your repo list:
zypper lr -d
and the output of:
rpm -qi vmware-tools-daemon
It should of course be perfectly possible to uninstall it. Just do so in YaST, you’ll see any other changes there immediately (click on the “Installation Summary” tab). You may want to right-click on the package and set it to “Taboo - Never install”.
kernel-desktop-base should not be installed automatically anymore because you uninstalled it manually.
PS: I don’t even find it on the software search page: http://software.opensuse.org/search?baseproject=openSUSE%3A13.1&p=1&q=vmware-tools-daemon
I guess you mean “open-vm-tools”? (That package does contain an init script for a “VMWare Tools Daemon”)
But you should be able to uninstall that either.
I don’t have it installed here, so it should not be required by anything.
On 2014-02-20 10:26, bonedriven wrote:
>
> It is related to ‘this thread’ (http://tinyurl.com/pdzzgqo).
>
> So after I solved the kernel related problem which was very likely
> caused by my uninstalling vmware-tools-daemon, the vmware-tools-daemon
> error at start appears again.
What is the exact rpm package name? I can’t locate anything by that name.
On 2014-02-20 14:24, Carlos E. R. wrote:
> On 2014-02-20 10:26, bonedriven wrote:
>>
>> It is related to ‘this thread’ (http://tinyurl.com/pdzzgqo).
>>
>> So after I solved the kernel related problem which was very likely
>> caused by my uninstalling vmware-tools-daemon, the vmware-tools-daemon
>> error at start appears again.
>
> What is the exact rpm package name? I can’t locate anything by that name.
I think it should be ‘open-vm-tools’. And perhaps ‘libvmtools0’.
In fact, it is just this daemon shown by Yast-services management
vmtoolsd.service - LSB: VMWare Tools Daemon Loaded: loaded (/etc/init.d/vmtoolsd) Active: failed (Result: exit-code) since Thu 2014-02-20 10:05:57 CET; 4h 48min ago CGroup: /system.slice/vmtoolsd.service `-829 /usr/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse
Feb 20 10:05:55 PortSu systemd[1]: Starting LSB: VMWare Tools Daemon... Feb 20 10:05:57 PortSu vmtoolsd[759]: Starting vmtoolsd FATAL: Error inserting vmw_balloon (/lib/modules/3.11.10-7-desktop/kernel/drivers/misc/vmw_balloon.ko): No such device Feb 20 10:05:57 PortSu vmtoolsd[759]: FATAL: Module vmsync not found. Feb 20 10:05:57 PortSu vmsvc[849]: warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-app-ctx after class was initialised Feb 20 10:05:57 PortSu vmsvc[849]: warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-prop-thread-pool after class was initialised Feb 20 10:05:57 PortSu vmsvc[849]: warning] [vmtoolsd] The vmsvc service needs to run inside a virtual machine. Feb 20 10:05:57 PortSu vmtoolsd[759]: ..failed Feb 20 10:05:57 PortSu systemd[1]: vmtoolsd.service: control process exited, code=exited status=7 Feb 20 10:05:57 PortSu systemd[1]: Failed to start LSB: VMWare Tools Daemon. Feb 20 10:05:57 PortSu systemd[1]: Unit vmtoolsd.service entered failed state. Feb 20 10:08:15 pc-gm-71 systemd[1]: Stopped LSB: VMWare Tools Daemon.
I searched with zypper and can’t find a pacakge named ‘vmtoolsd’, but only a “libvmtools0”.
This service always gives me error during machine boot up (no impact on my system though it seems)
So I’d like to know how I get rid of this service completely? Or should I?
As I said, this is part of “open-vm-tools”, so uninstall that, and “open-vm-tools-gui” and “libvmtools0” as well.
Although, by looking at the dependencies it should suffice to only mark libvmtools0 for uninstallation, the other 2 should be selected automatically then.
zypper also just uses rpm, so all packages with all files are stored in the rpm database which you can query with “rpm -q”.
And “rpm -qf” as suggested will tell you to which package a certain file belongs.
On 2014-02-20 17:26, wolfi323 wrote:
>
> bonedriven;2626065 Wrote:
>> Well, I thought I could forget this rpm thing since I am with zypper…
> zypper also just uses rpm, so all packages with all files are stored in
> the rpm database which you can query with “rpm -q”.
> And “rpm -qf” as suggested will tell you to which package a certain file
> belongs.
Right.
If there is a zypper concoction that does the same thing (it may),
consider that it will try to refresh repositories before giving an
answer. if I do that at home, it means several minutes.
You could add the “–no-refresh” option to zypper, it will not refresh the repositories then.
But I’m not aware of an equivalent option to “-qf” in zypper.
zypper wp path_to_file
might do, but I’m not sure if that would give exactly the same results in any case. (wp = whatprovides)
> You could add the “–no-refresh” option to zypper, it will not refresh
> the repositories then.
I know, but I forget about that. What I do in those case is
intentionally running it as user: it can not refresh
> But I’m not aware to an equivalent option to “-qf” in zypper.
>
>
> Code:
> --------------------
> zypper wp path_to_file
> --------------------
>
> might do, but I’m not sure if that would give exactly the same results
> in any case. (wp = whatprovides)
Man page says, for the search command:
–provides
Search for packages which provide the search strings. A
search string here might be also any symbol provided by a package like
/bin/vi, libcurl.so.3, perl(Time::ParseDate), web_browser, e.g. search
for the package which provides the shell: zypper se --provides /bin/sh
“wp”/“what-provides” is actually just a shortcut to “se --provides --match-exact”:
# zypper wp /usr/bin/ls
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+-----------+--------------------+--------
i | coreutils | GNU Core Utilities | package
But it doesn’t work exactly like “rpm -qf”:
# zypper wp /lib/modules/3.11.10-7-desktop/
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...
No packages found.
# zypper se --provides /lib/modules/3.11.10-7-desktop/
Loading repository data...
Reading installed packages...
No packages found.
# rpm -qf /lib/modules/3.11.10-7-desktop/
kernel-desktop-3.11.10-7.1.x86_64
virtualbox-host-kmp-desktop-4.3.6_k3.11.10_7-108.11.x86_64
virtualbox-host-kmp-desktop-4.3.6_k3.11.10_7-108.13.x86_64
One particular difference is that “zypper wp” also shows not-installed (but available in the configured repos) packages, whereas “rpm -qf” only checks installed ones:
# zypper wp /usr/bin/pavucontrol
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+-------------+---------------------------+--------
| pavucontrol | PulseAudio Volume Control | package
# rpm -qf /usr/bin/pavucontrol
error: file /usr/bin/pavucontrol: No such file or directory
If it doesn’t find things, it is not that useful. Well, it is a
directory that it does not find, in your example.
>
> One particular difference is that “zypper wp” also shows not-installed
> (but available in the configured repos) packages, whereas “rpm -qf” only
> checks installed ones:
And that’s is a very interesting feature, I think recently introduced.
Previously I used “pin” for this need.
