Problem with Vmware Server 1.0.* and kernel 2.4.37

vmware logoWhile today 2.6.32 is the mainline version of Linux kernel, 2.4 branch is still supported by Linux community developers who fix security bugs there but don’t add any new functionality (unlike 2.6 that grows with new features like a snowball). Sometimes it happens that Linux box runs too much services which cannot be stopped so that admin is not allowed to migrate from 2.4 to 2.6 to keep those services online.

In my example the box runs 2.4.37.7 kernel but Vmware Server 1.0.* fails on it with segmentation fault throwing into the logs the errors below in this post. Does that look familiar to anybody? Is there any solution to run Vmware Server at 2.4.37 kernel? Thank you!

...
Nov 24 15:26:29: vmx| NumVCPUs 1
Nov 24 15:26:29: vmx| UUID: location-UUID is 56 4d f2 10 ee e7 61 ad-47 0a 05 f7 f0 0f b7 74
Nov 24 15:26:29: vmx| MM: Using partialmap, 40960 pages AC 0 CE 1 TM 0 DOHU 0
Nov 24 15:26:29: vmx| UUID: canonical path is /var/lib/vmware/1/1.vmx
Nov 24 15:26:29: vmx| UUID: location-UUID is 56 4d f2 10 ee e7 61 ad-47 0a 05 f7 f0 0f b7 74
...
Nov 24 15:26:29: vmx| MM: using fileName /var/lib/vmware/1/564df210-eee7-61ad-470a-05f7f00fb774.vmem for paging
Nov 24 15:26:29: vmx| Msg_Reset:
Nov 24 15:26:29: vmx| ----------------------------------------
Nov 24 15:26:29: vmx| Opened paging file /var/lib/vmware/1/564df210-eee7-61ad-470a-05f7f00fb774.vmem
Nov 24 15:26:29: vmx| Mapped mainmem as pageable
Nov 24 15:26:29: vmx| MStat: Creating Stat vm.cpuusage
Nov 24 15:26:29: vmx| MStat: Creating Stat vm.ram
Nov 24 15:26:29: vmx| MStat: Creating Stat vm.uptime
Nov 24 15:26:29: vmx| AIOGNRC: Starting 4 I/O threads.
Nov 24 15:26:29: vmx| Caught signal 11 -- tid 18393
Nov 24 15:26:29: vmx| SIGNAL: eip 0x0 esp 0x40b38a9c ebp 0x40b38b0c
Nov 24 15:26:29: vmx| SIGNAL: eax 0x0 ebx 0x6cf208 ecx 0x6c67e0 edx 0x40b38ac4 esi 0x40b38bb0 edi 0x40b38ac4
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38a9c : 0x006c67fc 0x00000000 0x40b38ac4 0x00000000
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38aac : 0x00000000 0x00000000 0x00000000 0x00000000
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38abc : 0x00000000 0x40b38bb0 0x006cf208 0x40b38bb0
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38acc : 0x00000000 0x40b38b0c 0x40b38aa4 0x006c67e0
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38adc : 0x00000000 0x00000000 0x00000000 0x00000000
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38aec : 0x00000000 0x00000000 0x00000000 0x00000000
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38afc : 0x00000000 0x006c6760 0x00000000 0x00000000
Nov 24 15:26:29: vmx| SIGNAL: stack 0x40b38b0c : 0x00000000 0x00829aba 0x40b38bb0 0x00000000
Nov 24 15:26:29: vmx| Backtrace:
Nov 24 15:26:29: vmx| Backtrace[0] 0x40b3867c eip 0x805afc0
Nov 24 15:26:29: vmx| Backtrace[1] 0x40b3874c eip 0x80f358a
Nov 24 15:26:29: vmx| Backtrace[2] 0x40b387bc eip 0x80f331a
Nov 24 15:26:29: vmx| Backtrace[3] 0x40b38b0c eip 0x6cd0b8
Nov 24 15:26:29: vmx| Backtrace[4] 00000000 eip 0x829aba
Nov 24 15:26:29: vmx| Unexpected signal: 11.
Nov 24 15:26:29: vmx| Backtrace:
Nov 24 15:26:29: vmx| Backtrace[0] 0x40b3825c eip 0x805afc0
Nov 24 15:26:29: vmx| Backtrace[1] 0x40b3867c eip 0x80c02fb
Nov 24 15:26:29: vmx| Backtrace[2] 0x40b3874c eip 0x80f35ed
Nov 24 15:26:29: vmx| Backtrace[3] 0x40b387bc eip 0x80f331a
Nov 24 15:26:29: vmx| Backtrace[4] 0x40b38b0c eip 0x6cd0b8
Nov 24 15:26:29: vmx| Backtrace[5] 00000000 eip 0x829aba
Nov 24 15:26:29: vmx| Core dump limit is 51200 kb.
Nov 24 15:26:29: vmx| Attempting to dump core...
Nov 24 15:26:30: vmx| Msg_Post: Error
Nov 24 15:26:30: vmx| [msg.log.error.unrecoverable] VMware Server unrecoverable error: (vmx)
Nov 24 15:26:30: vmx| Unexpected signal: 11.
Nov 24 15:26:30: vmx| [msg.panic.haveLog] A log file is available in "/var/lib/vmware/1/vmware.log".
Nov 24 15:26:30: vmx| [msg.panic.haveCore] A core file is available in "/var/lib/vmware/1/core.18394".
...
Nov 24 15:26:30: vmx| [msg.panic.requestSupport.linux]
Nov 24 15:26:30: vmx| To collect files to submit to VMware support, run vm-support.
Nov 24 15:26:30: vmx| [msg.panic.response] We will respond on the basis of your support entitlement.
SHARE:
nv-author-image

Stefan Durand

My name is Stefan, I'm the admin of LinuxScrew. I am a full-time Linux/Unix sysadmin, a hobby Python programmer, and a part-time blogger. I post useful guides, tips, and tutorials on common Linux and Programming issues. Feel free to reach out in the comment section.

Leave a Reply

Your email address will not be published. Required fields are marked *