On a 64-bit 3.9-0 kernel, running Debian Sid, KDE desktop, VMware Player 5.0.2 build 1031769, patched with the vmware9.k3.8rc4.patch builds all the modules perfectly. On the same hardware (and a couple of others), on a 3.9-1 kernel, the module updater crashes silently after I choose "Install". When run from a terminal, you see only this, after choosing "Install" on the updater GUI:
don@delle6500:~$ vmplayer
Logging to /tmp/vmware-don/vmware-modconfig-5155.log
don@delle6500:~$
The request for root password did not appear on screen, so the vmware-gksu call apparently failed.
In the user's log file, everything looks normal/successful, except here:
.
.
.
2013-05-10T13:23:53.038-05:00| vthread-3| I120: Trying to find a suitable PBM set for kernel "3.9-1.towo-siduction-amd64".
2013-05-10T13:23:53.038-05:00| vthread-3| I120: No matching PBM set was found for kernel "3.9-1.towo-siduction-amd64".
2013-05-10T13:23:53.038-05:00| vthread-3| I120: Validating path "/lib/modules/3.9-1.towo-siduction-amd64/build/include" for kernel release "3.9-1.towo-siduction-amd64".
.
.
The user's log file ends here:
2013-05-10T13:23:53.045-05:00| vthread-3| I120: Preprocessed UTS_RELEASE, got value "3.9-1.towo-siduction-amd64".
2013-05-10T13:23:53.045-05:00| vthread-3| I120: The header path "/lib/modules/3.9-1.towo-siduction-amd64/build/include" for the kernel "3.9-1.towo-siduction-amd64" is valid. Whoohoo!
2013-05-10T13:23:53.045-05:00| vthread-3| I120: The GCC version matches the kernel GCC minor version like a glove.
2013-05-10T13:23:56.033-05:00| vthread-3| I120: Validating path "/lib/modules/3.9-1.towo-siduction-amd64/build/include" for kernel release "3.9-1.towo-siduction-amd64".
2013-05-10T13:23:56.041-05:00| vthread-3| I120: Preprocessed UTS_RELEASE, got value "3.9-1.towo-siduction-amd64".
2013-05-10T13:23:56.041-05:00| vthread-3| I120: The header path "/lib/modules/3.9-1.towo-siduction-amd64/build/include" for the kernel "3.9-1.towo-siduction-amd64" is valid. Whoohoo!
2013-05-10T13:23:56.041-05:00| vthread-3| I120: The GCC version matches the kernel GCC minor version like a glove.
2013-05-10T13:23:56.041-05:00| vthread-3| I120: Relaunching with /usr/bin/vmware-gksu '/usr/bin/vmware-modconfig' --icon='vmware-player' --appname='VMware'
don@delle6500:/tmp/vmware-don$
I checked the three root logs and found nothing unusual. The linux-header files for the kernel are installed, and were found by the module updater as indicated above -- so why the "no PBM set" error? Based on previous forum comments regarding the ".h" files in the header package under /include/linux, I did a side-by-side comparison of the 3.9-0 files to the 3.9-1 files, and they look the same when viewed with dolphin.
I'm outta gas on this -- hopefully someone else can confirm the problem, or offer a theory, and thanks in advance.
Learning experience here -- the problem is NOT the new kernel. With a "workaround", the modules will compile for 3.9.1. I had forgotten that a couple of things changed earlier in the week:
(1) new kernel released, and
(2) major sid upgrades after Wheezy release.
Observing that the problem occurs prior to, or in conjunction with calling /usr/bin/vmware-gksu, resulting in no gksu request for the root password, I tried running the module-updater directly, as root, and the modules built with no problem.
I don't think the problem is in KDE -- I used my E-17 desktop to do this workaround. There is something in the Debian sid aka "Jessie" upgrades that is interfering with the gksu call -- that's the end of my ability to find the root cause.
Workaround:
Open a root terminal and issue
/usr/bin/vmware-modconfig --icon=vmware-player --appname=VMware
EDIT 11 MAY: On one system, the workaround did not run successfully in a root terminal. It was necessary to go to the tty console, as root, cd to the /usr/bin directory, and issue: Code: vmware-modconfig --console --install-all --icon=vmware-player --appname=VMware |
I am changing the thread title to better reflect the nature of the problem.