rawhide glibc makes vmware crash -- Ideas?
Ami Fischman
I upgraded my glibc to rawhide (2.3.1-38) about a week ago (necessary for
other software that I need), and now vmware bombs out with:
XIO: fatal IO error 0 (Success) on X server ":0.0"
after 2831 requests (2830 known processed) with 99 events remaining.
right after startup (as it's painting its UI).
The vmnet/mon modules compile fine, but googling through the group I saw
other people mention that using the vmware-any-any-update25 patch worked
for them, so tried it. The modules still compile fine, but the error
remains.
Has anyone gotten a newish glibc 2.3.1 to work with vmware 3.2
(VMwareWorkstation-3.2.0-2230)? Any hints?
BTW, the system is a base rh8.0 + some rawhide rpms with XFree86-4.2.1-8
and garnome running the UI. I get the same error in an empty X server
running only an xterm in addition to vmware.
Thanks,
--
Ami Fischman
use...@fischman.org
Petr Vandrovec
>
> Hi there,
>
> I upgraded my glibc to rawhide (2.3.1-38) about a week ago (necessary for
> other software that I need), and now vmware bombs out with:
>
> XIO: fatal IO error 0 (Success) on X server ":0.0"
> after 2831 requests (2830 known processed) with 99 events remaining.
>
> right after startup (as it's painting its UI).
>
> The vmnet/mon modules compile fine, but googling through the group I saw
> other people mention that using the vmware-any-any-update25 patch worked
> for them, so tried it. The modules still compile fine, but the error
> remains.
>
> Has anyone gotten a newish glibc 2.3.1 to work with vmware 3.2
> (VMwareWorkstation-3.2.0-2230)? Any hints?
In addition to my email I sent you by mistake, looking at rpmfind.net,
latest glibc which works is 2.3.1-16. 2.3.1-30 is broken, and problem
comes from the NPTL library - so maybe it is not that trivial to fix :-(
I'll see, but you should also fill bugreport at RedHat...
Petr
Ami Fischman
> In addition to my email I sent you by mistake, looking at rpmfind.net,
> latest glibc which works is 2.3.1-16. 2.3.1-30 is broken, and problem
> comes from the NPTL library - so maybe it is not that trivial to fix :-(
Not sure where you are getting this information from. Do you have
experimental knowledge that -16 worked and -17 doesn't? What makes you
think NPTL has something to do with it? (wasn't NPTL included in the
earlier 2.3.1 releases as well?)
> I'll see, but you should also fill bugreport at RedHat...
Done. Bug #82505.
Cheers,
--
Ami Fischman
use...@fischman.org
Petr Vandrovec
>
> Petr Vandrovec <pe...@vandrovec.name> writes:
>
> > In addition to my email I sent you by mistake, looking at rpmfind.net,
> > latest glibc which works is 2.3.1-16. 2.3.1-30 is broken, and problem
> > comes from the NPTL library - so maybe it is not that trivial to fix :-(
>
> Not sure where you are getting this information from. Do you have
> experimental knowledge that -16 worked and -17 doesn't? What makes you
> think NPTL has something to do with it? (wasn't NPTL included in the
> earlier 2.3.1 releases as well?)
I tried it... Problem is that both VMware and glibc provide errno variable.
In the past (before NPTL) errno was just weak symbol, and so everyone
used errno from VMware. But NPTL change, except other, also changed errno
to be normal strong symbol - and so there are two errnos in the program,
and some code uses one errno, and some code another...
But fortunately glibc-2.3.1-16 and 2.3.1-3x are very compatible, so you
can just copy /lib/ld-2.3.1.so from 2.3.1-16 to your updated system
(do this from Midnight Commander, and never remove old file; if you'll
remove /lib/ld-2.3.1.so, you'll not be able to start any program!)
Petr
Ami Fischman
rawhide glibc), here's what ended up working.
Compile the attached file q.c into q.so. Put q.so into /usr/lib/, and
chmod it 555. Then rename the files /usr/lib/vmware/bin/vmware-{ui,mks},
giving them a ".bin" extension. Then create two new files named
/usr/lib/vmware/bin/vmware-{ui,mks} instead that contain:
-------------------
#!/bin/bash
LD_PRELOAD=q.so exec "$0.bin" "$@"
-------------------
chmod a+rx these new files, and all should be well.
The basic problem is that vmware binaries have their own copy of errno and
related functions, and there is a clash with the new glibc ones. q.so will
resolve this problem. The need for the scripts above arises from the fact
that each of the binaries launched by the initial /usr/bin/vmware call
needs to have the q.so preloaded.
q.c was written by Petr Vendrovec, and many thanks go to him for the work
he put into the debugging of the problem and the attached code!
In summary, q.c qorreqts the formerly inqurable qrashes.
Cheers,
--
Ami Fischman
use...@fischman.org
-------------------------------------------------------
/*
* Build with: gcc -W -Wall -shared -o q.so q.c
*/
#include <dlfcn.h>
#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>
void go(void) __attribute__((constructor));
void go(void) {
void* qh;
unsigned char *__real_errno_location, *__vm_errno_location;
qh = dlopen("libc.so.6", RTLD_GLOBAL);
__real_errno_location = dlsym(qh, "__errno_location");
__vm_errno_location = dlsym(NULL, "__errno_location");
printf("Got eroloc %p & %p\n", __vm_errno_location, __real_errno_location);
if (__real_errno_location && __vm_errno_location && __real_errno_location != __vm_errno_location) {
unsigned int errnobase = (int)__vm_errno_location;
unsigned int mpbase = errnobase & ~0xFFF;
unsigned int mplen = 4096;
if (errnobase + 5 > mpbase + mplen) {
mplen = mplen + 4096;
}
mprotect((void*)mpbase, mplen, PROT_READ|PROT_WRITE|PROT_EXEC);
*__vm_errno_location = 0xE9;
*(int*)(__vm_errno_location + 1) = __real_errno_location - __vm_errno_location - 5;
mprotect((void*)mpbase, mplen, PROT_READ|PROT_EXEC);
}
}
-------------------------------------------------------
Squeamish Ossifrage
> In the interest of posterity (and helping anyone else using vmware with
> rawhide glibc), here's what ended up working.
>
> Compile the attached file q.c into q.so. Put q.so into /usr/lib/, and
> chmod it 555. Then rename the files /usr/lib/vmware/bin/vmware-{ui,mks},
> giving them a ".bin" extension. Then create two new files named
> /usr/lib/vmware/bin/vmware-{ui,mks} instead that contain:
> -------------------
> #!/bin/bash
> LD_PRELOAD=q.so exec "$0.bin" "$@"
> -------------------
Wow, that's pretty cool... The only problem with using LD_PRELOAD is that
it ld will give up suid if LD_PRELOAD is used... So this will only work as
root, but that's better then not working at all!
Thanks!
Clem
Petr Vandrovec
If you'll do it exactly as Ami wrote, it will work even for non-root. You
can preload libraries from /lib and /usr/lib even to suid programs.
Petr
Ami Fischman
for suid progs (as long as you don't specify the full pathname to the
object). I have it working under my non-root user account now.
--
Ami Fischman
use...@fischman.org
Perry Ismangil
> As Petr pointed out, LD_PRELOADs from /lib and /usr/lib get picked up even
> for suid progs (as long as you don't specify the full pathname to the
> object). I have it working under my non-root user account now.
Thanks for all this bit, it's close to working now...
I still can't do it from non-root. Is there an ownership issue?
Here what I have so far
-r-xr-xr-x 1 root root 6108 Feb 6 10:35 /usr/lib/q.so
-rwxr-xr-x 1 root root 49 Feb 6 10:27 vmware-mks
-r-xr-xr-x 1 root root 543088 Sep 10 04:28 vmware-mks.bin
-rwxr-xr-x 1 root root 49 Feb 6 10:26 vmware-ui
-r-xr-xr-x 1 root root 1682552 Sep 10 04:28 vmware-ui.bin
$vmware &
Got eroloc 0x809caa0 & 0x401a8ac0
VMware Workstation Error:
Could not open /dev/vmmon: Permission denied.
Please make sure that the kernel module `vmmon' is loaded.
Press "Enter" to continue...
Thanks.
ChrisTooley
> As Petr pointed out, LD_PRELOADs from /lib and /usr/lib get picked up even
> for suid progs (as long as you don't specify the full pathname to the
> object). I have it working under my non-root user account now.
>
Ami Fischman
[...]
>> object). I have it working under my non-root user account now.
>>
> As do I, though I had to suid the shell scripts to do it.
Why? Works fine without that on my end...
--
Ami Fischman
use...@fischman.org
Bob Goddard
> ChrisTooley <cto...@phototropia.org> writes:
>
> [...]
>
>>> object). I have it working under my non-root user account now.
>>>
>> As do I, though I had to suid the shell scripts to do it.
>
> Why? Works fine without that on my end...
Suid is not required because it does not work on shell scripts.
The setting is dropped because of the security risk.
B
Narendra Sankar
instructions
and I can run vmware as root. But not as a user. It seems that the
LD_PRELOAD works, as I can see the reloc messages, but then I get
permission denied messages for vmmon. It seems that using LD_PRELOAD
kills the suid bit that is propagated from vmware to vmware-mks and
vmware-ui. I can chmod a+rw /dev/misc/vmmon and then the ui starts,
but it dies complaining about permissions on /dev/tty0 and /dev/tty7
(my x is running on tty7). So in order to get it to work, I had to
chmod a+rw /dev/vc/0 and /dev/vc/7. For full screen I had to chmod
a+rw /dev/vc/8.
Then vmware works fine. So I don't know if changing all these
permissions is the right thing to do, but at least it got vmware
running. Is there anyway to keep the LD_PRELOAD from killing the suid
bit. Is this true in general, or is there something in my gentoo
installation that makes this happen? Maybe someone can shed more light
on this.
Hope my hack helps others not able to run as non-root.
Naren
Ami Fischman
thread over on vmware.for-linux.general. Google has it at: