I installed vmware 7.1.5 on two different SuSE 12.1 machines.
One is an upgraded system (11.4 → 12.1) and the other one
is a freshly installed one. On the freshly installed one everything
is working normally.
On the upgraded one vmware doesn’t work. The only difference
that I realized is the following error message:
“process 20475: Attempt to remove filter function 0x7f644f441980 user
data 0x8d30e0, but no such filter has been added
D-Bus not built with -rdynamic so unable to print a backtrace”
So what’s wrong???
Of course, the upgraded one is my working horse and I do not want to
reinstall everything from the very beginning!!
Thanks in advance,
Uwe.
PS: See also me previous thread “Vmware 7.1.5 and SuSE 12.1”
I’m not familiar with vmware at all, so had a quick google with ‘vmware Attempt to remove filter function solved’ (and similar). I want to point you at this thread:
I note that hal and dbus are mentioned a lot in the links returned. Now, hal is generally not required for normal desktop use with 11.4 onwards, but I wonder whether that explains the difference between your working and non-working installations - just a guess on my part. (It can be installed if necessary). Check what processes are running on the host for both.
So while your problem is dbus you think, you are refering to installing vmware. We do have a new forum for all questions concerning virtualization here: Virtualization
Second, as you found out, doing a clean install is highly recommended over an upgrade. Its hard to say what you need to do now, but did you know you can do a clean install of the OS without over writing your /home folder if you maintained a separate partition for /home? You must modify the partition setup so that your separate /home partition is mounted only and not formatted. When you do the install, all of your old settings will be maintained. You only need to reload your old applications and this works just as you had hoped for your upgrade, but all apps loaded are fully from the new openSUSE version as required.
Another way is very tedious but you can open YaST / Software / Software Management use the view button to select repositories and then go down all the repositories you have, make sure they are for openSUSE 12.1 and that all applications install come from an openSUSE 12.1 repository and upgrade any that are not. You can even search on such things as dbus and make sure all apps install are from openSUSE 12.1. Use the application versions tab to see its source.
Guys, I don’t think the OP is claiming that this is a dbus issue - only that dbus reported a message (with the updated installation). The OP is asking what might be the difference between the updated OS and the ‘clean install’ vmware?
thanks for your hints. First a comment to jdmedaniel3: A new installation may be recommended,
but why is there the option for upgrading ?!? A new installation on my side is not just saving the
/home directory or not format the partition where it is on. After all the years I have added a lot
of software, like NAG, dislin, INTEL fortran, etc. So I don’t like to reinstall everything, just to get
vmware working again!
Now to the hints by deano_ferrari: Yes, I know the idea to start the “HAL” service. But how can I do
it under SuSE 12.1? After your suggestions I did a “dbus restart” on both machines. The freshly
installed one gives no warnings or errors. It just started the dbus service. The upgraded one gives
to additional lines:
“Starting D-Bus daemonUnknown username “haldaemon” in message bus configuration file
Unknown username “polkituser” in message bus configuration file”
So, there is the haldeamon hint again! But how can I start it? There is nothing (?) under
“services” in yast2! Even looking under “User and Group Management” I found nothing
appropriate and what is the “message bus configuration file”?
So please help and I wish you all a Happy New Year.
Now to the hints by deano_ferrari: Yes, I know the idea to start the “HAL” service. But how can I do
it under SuSE 12.1? After your suggestions I did a “dbus restart” on both machines. The freshly
installed one gives no warnings or errors. It just started the dbus service. The upgraded one gives
to additional lines:
“Starting D-Bus daemonUnknown username “haldaemon” in message bus configuration file
Unknown username “polkituser” in message bus configuration file”
So, there is the haldeamon hint again! But how can I start it? There is nothing (?) under
“services” in yast2! Even looking under “User and Group Management” I found nothing
appropriate and what is the “message bus configuration file”?
Well, you didn’t provide the ‘ps -A’ output that I hinted at previously, so it leaves me to guess about whether hal is required or not. As explained before, most of us no longer require this deprecated daemon and its no longer installed by default.
Thinking about this some more - take a look at the dbus configuration files in /etc/dbus-1/system.d/ for both systems. It is likely that there is a vmware config file that may differ between the upgrade an clean-install machines, causing the problem you’re experiencing. It may just be a matter of copying the working file… or we could just be chasing our tails.
‘hal’ not found in package names. Trying capabilities.
No provider of ‘hal’ found.
Sorry, but I expected this. Comparing the two directories, you mentioned, leads
me to copy two files with “hal” or “PolicyKit” in it to something else. Now I don’t
get the warnings/error messages, but… vmware didn’t start.
What do you think, will it help, if I downgrade the kernel from 3.x to 2.x? And how
can I do it?
That’s not surprising. Nobody uses hal anymore. udev takes care of everything now (for the best and for the worst).
Compile hal for 12.1 maybe and (probably) boot in System V, but … it might not work. Does vmware need hal? Then vmware is wrong. Find out everything that requires hal and replace hal policies with udev rules… It might not be fun though.
But I never used vmware. So I guess I can not help here.
I must interject that while doing an upgrade is an option and that it did result in a installation that will boot and startup, it has resulted in mixed versions and orphaned applications that do not work properly together. As by evidence of a clean install that works and an upgrade that does not work properly, how long does it take to get to a fully working copy after an upgrade is performed? If you do not remove your old settings because you do not format /home, I suggest that a fully working system is just a few added repositories and application installations away from which all loaded programs will work because they were compiled to work together. Some things like hal are removed and some things like systemd are a new default option. And a clean install is not a guarantee that all things will work, but it seems like you have your own evidence of just how well a clean install works. Now one thing is for sure, we want your installation to work properly and we have volunteers here that will tirelessly attempt to help you out and further I wish you all of the luck in the world on finding a solution, but in the end, if no resolution is found, consider all of the facts you have learned.
However, like please_try_again, I’m not familiar with vmware, and most apps no longer require hal at all. (What I was suggesting, was that your /etc/dbus-1/system.d/ policy configs might differ somewhere, because the upgrade may have left something irrelevant in place).
I must interject that while doing an upgrade is an option and that it did result in a installation that will boot and startup, it has resulted in mixed versions and orphaned applications that do not work properly together. As by evidence of a clean install that works and an upgrade that does not work properly, how long does it take to get to a fully working copy after an upgrade is performed? If you do not remove your old settings because you do not format /home, I suggest that a fully working system is just a few added repositories and application installations away from which all loaded programs will work because they were compiled to work together. Some things like hal are removed and some things like systemd are a new default option. And a clean install is not a guarantee that all things will work, but it seems like you have your own evidence of just how well a clean install works. Now one thing is for sure, we want your installation to work properly and we have volunteers here that will tirelessly attempt to help you out and further I wish you all of the luck in the world on finding a solution, but in the end, if no resolution is found, consider all of the facts you have learned.
I have to agree completely with this line of thinking here, especially with something as complex as vmware, and its assumed requirements.
It’s kind of funny that a piece of virtualization software needs a (btw obsolete) hardware abstraction layer. If it’s installed on the host - as I don’t know what you are doing exactly - make sure the daemon is not enable by default. I’m not sure what effect it might have*, but it’s certainly not advisable IMO. Anyway since it’s not needed (by Linux at least) , it can not be advisable.
Can we assume that the issue you reported in another thread about the floppy drive spinning crazy in VirtualBox is not related with the use of the hal daemon? Just a thought…
I’d still like to know whether the vmware on the the ‘clean install’ machine has hal installed, and therefore the upgrade left behind some kind of ‘phantom’ dependency on hal (through dbus config or some older package still present). In other words, although the OP met the requirement by installing hal, maybe it is not really using it. Easy enough to check by killing hald (if actually running) with vmware running.
and its no longer installed by default.