VMware Communities
outofmemory
Contributor
Contributor

VMware 8.0.2 PANIC on Fedora 17, Kernel 3.3.7/3.0.0

I've been using VMware Workstation for years now (on Fedora hosts).

Usually when I updated my system and a new Kernel got installed, VMware would bring up this dialog saying that the modules have to be rebuilt. That never really worked (with new Kernel versions), failing with errors like "Failed to build module vmnet". So I kept booting the Fedora system with an older Kernel (but usually found some patch that made it work with the new Kernel version).

The point is, VMware recognized that the system was running with a different Kernel and refused to start until its modules have been rebuilt.

Now, on a Fedora 17 system with Kernel 3.3.7, VMware won't even try to rebuild its modules. It'll just start right up. So when starting a virtual machine, VMware panics. By that, I mean it looks like a Linux Kernel panic, whole screen turns black, shows only some useless backtrace. Switching tty (Ctrl+Alt+F3) not possible. SSH daemon still running, so it's possible to log on to the machine remotely and shutdown (> 20 minutes). Issuing something like "ps aux" will show a little bit of output, then get stuck (same for kill). When rebooting, the system log sometimes shows fsck warnings (inodes repaired), indicating that data loss might have occured.

Since I couldn't find an older Kernel in the Fedora 17 repository, I manually compiled and installed Kernel 3.0.0. However, that doesn't seem to change anything. VMware doesn't recompile any modules by itself. I can't make it do so by removing /usr/lib/vmware/modules/source/.patched, because that file doesn't exist. Running vmware-modconfig --console --install-all does not throw any error, but starting a VM will still cause this VMware panic.

Long story short:
VMware always used to rebuild properly, when I booted into an older Kernel. Why doesn't it even try now with one (3.0.0), and still fail to start a VM?
Reply
0 Kudos
10 Replies
mfelker
Expert
Expert

What type of processor do you have?  If it is AMD and not Intel you will only be ablel to install VMware and create a machine but lwhen you power on the machione you will get a PANIC.  This has been discussed before (maybe on this forum - certainly on the beta forum).  Since I've been running Fedora 16-17 with the 3.x kernels happened every  single time (I have an AMD).  You won't get help from the Fedora developers either who cliam its a VMware problem - its not.

I just use Ubuntu. Or you can use Virtualbox.  Or you can get an Intel chip.  If you are in fact using an Intel this is very interesting (but sad of course).  Let us know.

Reply
0 Kudos
outofmemory
Contributor
Contributor

Indeed, I do have an AMD processor.

So it's a bug somewhere in Fedora 17 that only affects AMD chips? Can't be in the Kernel though, since I've manually installed one, so where?

I most certainly won't just use Ubuntu (not a fan), I'd prefer to stick with Fedora. However, I've installed Debian and set it up like the Fedora installation (same software, same home dir, same system settings). I'll install VMware on Debian and let you know how it went.

I do play around with VirtualBox a little, but besides the fact that migrating virtual machines from VMware to VirtualBox is a lot of work, there's something else:

VirtualBox VMs seem to run unstable. VMware is reliable - none of my virtual machines has ever crashed in VMware (except if the host hardware wasn't working properly or the virtual machine itself wasn't "clean", e.g. many poweroffs). One time, a fresh VirtualBox VM (Fedora, very few packages installed, no X11, not even base packages) crashed with a Kernel panic for no reason. Another time, I've just installed Debian in a VirtualBox VM and on first bootup, I discovered, that my /etc/apt/sources.list was somehow broken.

Those incidents made me loose some confidence in VirtualBox, so I'll keep using VMware as long as I can.

Reply
0 Kudos
mfelker
Expert
Expert

It's pretty amazing that you compiled your own kernel on Fedora and its still PANIC'ed.  I'd report this bug again to Redhat bugzilla but the last time I did I got grief. Debian should definitely work for you.  It probably won't change your mind but I am usinig VMware on Ubuntu 12.10 (Quantel) pre- alpha.  By using Gnome 3 insteaD  of the Ubuntu desktop abortion it works pretty well on 3.4.  VMware works fine on openSUSE 12.1 with kernel 3.1.  It also works on Windoiws 8 for what that's worth.

Cheers

Reply
0 Kudos
outofmemory
Contributor
Contributor

I'll report a bug to Redhat.

I still don't get why VMware doesn't even try anymore to rebuild its modules when booting a new/different Kernel.

I'll probably compile Kernel 2.6 on my Fedora to see if it'll then recognize the difference, rebuild and maybe even start a VM without panicking.

So I've set up a Debian Squeeze and installed VMware Workstation 8.0.3. On first run it actually tried and succeeded to rebuild its modules (like it should). I started a VM and it worked right away. Plus all my settings from Fedora (like VM favorites) are right there, because I mounted the same Home partition I use in Fedora.

I did run into some difficulties however, like after installing VMware, the Debian package management system (apt-get install) throws lots of errors whining about missing LSB tags in VMware scripts.

Reply
0 Kudos
mfelker
Expert
Expert

Yes. I forgot that Debian throws a lot of error messages after you install WS. They mean nothing - ignore them. Often it throws GRUB errors as well depending on your partitioning. They also mean nothing and can be ignored.

Glad that Debian otherwise seems working for you. Let us know how your VM is working!

Reply
0 Kudos
outofmemory
Contributor
Contributor

VMware is working like a charm on Debian!

I'm still getting VMware errors when install software (not everytime, just in some cases):

# apt-get install samba
Reading package lists... Done
Building dependency tree
Reading state information... Done
samba is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
Setting up nfs-kernel-server (1:1.2.2-4squeeze2) ...
insserv: warning: script 'vmware-workstation-server' missing LSB tags and overrides
insserv: script vboxdrv: service vboxdrv already provided!
insserv: There is a loop between service munin-node and vmware-workstation-server if stopped
insserv:  loop involving service vmware-workstation-server at depth 2
insserv:  loop involving service munin-node at depth 1
insserv: Stopping vmware-workstation-server depends on munin-node and therefore on system facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing nfs-kernel-server (--configure):
subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
                                      Setting up samba (2:3.5.6~dfsg-3squeeze8) ...
insserv: warning: script 'vmware-workstation-server' missing LSB tags and overrides
insserv: script vboxdrv: service vboxdrv already provided!
insserv: There is a loop between service munin-node and vmware-workstation-server if stopped
insserv:  loop involving service vmware-workstation-server at depth 2
insserv:  loop involving service munin-node at depth 1
insserv: Stopping vmware-workstation-server depends on munin-node and therefore on system facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing samba (--configure):
subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
                                      Errors were encountered while processing:
nfs-kernel-server
samba
E: Sub-process /usr/bin/dpkg returned an error code (1)

Edit:

I figured it out.

Like I said before, as soon as VMware is installed, every apt-get run throws those warnings, but in most cases, it's working anyway, so they can be ignored. However, if for example installing services like samba or nfs, those VMware related warnings actually block the installation.

So when installing VMware on Debian, LSB tags have to be manually added to the VMware service scripts, otherwise aptitude is broken.

I know this is getting off-topic (Fedora, VMware panic ...), but maybe this will help somebody else.

Find out which VMware script is causing the trouble. In this case it's "/etc/init.d/vmware-workstation-server" (see above, script 'vmware-workstation-server' missing LSB tags).

Then add these LSB tags:

### BEGIN INIT INFO
# Provides:          vmware-worstation-server
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: VMware
# Description:       VMware Workstation
#
### END INIT INFO

This can go right above this note:

# No init info needed b/c system is using update-rc.d.

Alternatively, it's also possible to put these tags (init info) in additional files. This is probably the better solution, because even if the service scripts are recreated (by updating VMware), the tags are still there and don't have to be manually added again.

In this case, a new file /etc/insserv/overrides/vmware-workstation-server would have to be created (with begin init info - end init info). To be safe, override files can be created for all VMware service scripts, that would be (in addition to of "vmware-worstation-server") "vmware" and "vmware-USBArbitrator".

Reply
0 Kudos
outofmemory
Contributor
Contributor

I've just tried it another time, with VMware Workstation 8.0.3 on an up-to-date Fedora 17 on Kernel 3.4.

The good news is that VMware won't just start anymore unless its modules are built for the current Kernel. And this process obviously fails, but I found an article about a Patch for VMware Workstation 8.0.3 on Kernel 3.4.

The bad news is that (although the patch seems to work) I still get a VMware panic as soon as I start a virtual machine. This time I'm able to switch back to my X session with Ctrl+Alt+F1.

VMware PANIC on Fedora 17, Kernel 3.4
Jul  2 20:31:22 [HOST] kernel: [  408.858274] ------------[ cut here ]------------
Jul  2 20:31:22 [HOST] kernel: [  408.859224] kernel BUG at include/linux/mm.h:403!
Jul  2 20:31:22 [HOST] kernel: [  408.860123] invalid opcode: 0000 [#1] SMP
Jul  2 20:31:22 [HOST] kernel: [  408.861059] CPU 0
Jul  2 20:31:22 [HOST] kernel: [  408.861068] Modules linked in: vmnet(O) vsock(O) vmci(O) vmmon(O) tpm_bios ppdev parport_pc parport fuse ebtable_nat ebtables ipt_MASQUERADE
iptable_nat nf_nat xt_CHECKSUM iptable_mangle lockd sunrpc bridge stp llc bnep bluetooth be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i ip6t_REJECT cxgb3 mdio
libcxgbi nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 ib_iser rdma_cm nf_conntrack_ipv4 ip6table_filter nf_defrag_ipv4 ip6_tables ib_addr
iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi xt_state nf_conntrack xfs vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm vhost_net snd_page_alloc snd_timer eeepc_wmi asus_wmi r8169 snd sparse_keymap tun macvtap macvlan mii
kvm_amd kvm sp5100_tco i2c_piix4 amd64_edac_mod edac_core edac_mce_amd rfkill soundcore microcode k10temp serio_raw uinput btrfs libcrc32c zlib_deflate firewire_ohci
Jul  2 20:31:22 [HOST] kernel: firewire_core crc_itu_t mxm_wmi wmi radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan]
Jul  2 20:31:22 [HOST] kernel: [  408.863002]
Jul  2 20:31:22 [HOST] kernel: [  408.863004] Pid: 7814, comm: vmware-vmx Tainted: G         C O 3.4.4-3.fc17.x86_64 #1 To be filled by O.E.M. To be filled by O.E.M./SABERTOOTH
990FX
Jul  2 20:31:22 [HOST] kernel: [  408.863007] RIP: 0010:[<ffffffffa0943198>]  [<ffffffffa0943198>] get_page.part.2+0x4/0xe6c [vmmon]
Jul  2 20:31:22 [HOST] kernel: [  408.863013] RSP: 0018:ffff8803d0ccbd58  EFLAGS: 00010246
Jul  2 20:31:22 [HOST] kernel: [  408.863014] RAX: 0000000000000000 RBX: ffff88040dca8338 RCX: 0000000000000000
Jul  2 20:31:22 [HOST] kernel: [  408.863016] RDX: ffff8803fdf74000 RSI: ffffea000ff7dd00 RDI: ffff8803fdf75000
Jul  2 20:31:22 [HOST] kernel: [  408.863017] RBP: ffff8803d0ccbd58 R08: 0000000000440000 R09: 0000000000000000
Jul  2 20:31:22 [HOST] kernel: [  408.863018] R10: 0000000000000002 R11: ffff8803fdd9ebb0 R12: 0000000000000004
Jul  2 20:31:22 [HOST] kernel: [  408.863019] R13: 0000000000000003 R14: ffffea000ff7dd40 R15: 0000000000000001
Jul  2 20:31:22 [HOST] kernel: [  408.863020] FS:  00007fb11b82c740(0000) GS:ffff88043fc00000(0000) knlGS:0000000000000000
Jul  2 20:31:22 [HOST] kernel: [  408.863022] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul  2 20:31:22 [HOST] kernel: [  408.863023] CR2: 0000000000987720 CR3: 0000000404fbe000 CR4: 00000000000007f0
Jul  2 20:31:22 [HOST] kernel: [  408.863024] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul  2 20:31:22 [HOST] kernel: [  408.863025] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul  2 20:31:22 [HOST] kernel: [  408.863027] Process vmware-vmx (pid: 7814, threadinfo ffff8803d0cca000, task ffff8803d0eedc40)
Jul  2 20:31:22 [HOST] kernel: [  408.863027] Stack:
Jul  2 20:31:22 [HOST] kernel: [  408.863028]  ffff8803d0ccbdd8 ffffffffa09399ee ffff880404ce9e70 000000032f007c00
Jul  2 20:31:22 [HOST] kernel: [  408.863031]  ffff88040dca8310 0000000000000004 000200d200000002 0000000000000000
Jul  2 20:31:22 [HOST] kernel: [  408.863033]  ffff88040dca8300 0000000000000003 ffff8803d0ccbe38 ffff880404f31308
Jul  2 20:31:22 [HOST] kernel: [  408.863034] Call Trace:
Jul  2 20:31:22 [HOST] kernel: [  408.863037]  [<ffffffffa09399ee>] LinuxDriverMmap+0x29e/0x2c0 [vmmon]
Jul  2 20:31:22 [HOST] kernel: [  408.863041]  [<ffffffff8114cd80>] mmap_region+0x4c0/0x630
Jul  2 20:31:22 [HOST] kernel: [  408.863043]  [<ffffffff81146e23>] ? handle_mm_fault+0x1d3/0x2e0
Jul  2 20:31:22 [HOST] kernel: [  408.863045]  [<ffffffff8114d23d>] do_mmap_pgoff+0x34d/0x3a0
Jul  2 20:31:22 [HOST] kernel: [  408.863047]  [<ffffffff8114d3c0>] sys_mmap_pgoff+0x130/0x230
Jul  2 20:31:22 [HOST] kernel: [  408.863050]  [<ffffffff810d025c>] ? __audit_syscall_exit+0x3ec/0x450
Jul  2 20:31:22 [HOST] kernel: [  408.863053]  [<ffffffff81017772>] sys_mmap+0x22/0x30
Jul  2 20:31:22 [HOST] kernel: [  408.863056]  [<ffffffff815fc8a9>] system_call_fastpath+0x16/0x1b
Jul  2 20:31:22 [HOST] kernel: [  408.863056] Code: c7 c7 2d 58 94 a0 e8 08 a0 ff ff 31 c0 e9 8d fc ff ff c7 83 78 04 00 00 00 00 00 00 66 b8 00 e0 e9 fb fb ff ff 66 90 55 48 89
e5 <0f> 0b bf f2 ff ff ff e9 af 9e ff ff 00 00 00 00 00 00 00 00 00
Jul  2 20:31:22 [HOST] kernel: [  408.863068] RIP  [<ffffffffa0943198>] get_page.part.2+0x4/0xe6c [vmmon]
Jul  2 20:31:22 [HOST] kernel: [  408.863070]  RSP <ffff8803d0ccbd58>
Jul  2 20:31:22 [HOST] kernel: [  408.870476] ---[ end trace 815edf169d27005c ]---
Jul  2 20:31:24 [HOST] sh[907]: abrt-dump-oops: Found oopses: 1
Jul  2 20:31:24 [HOST] sh[907]: abrt-dump-oops: Creating dump directories
Jul  2 20:31:24 [HOST] abrtd: Directory 'oops-2012-07-02-20:31:24-7849-0' creation detected
Jul  2 20:31:24 [HOST] abrt-dump-oops: Reported 1 kernel oopses to Abrt
Jul  2 20:31:24 [HOST] abrtd: Can't open file '/var/spool/abrt/oops-2012-07-02-20:31:24-7849-0/uid': No such file or directory
Jul  2 20:31:24 [HOST] abrtd: New problem directory /var/spool/abrt/oops-2012-07-02-20:31:24-7849-0, processing
Jul  2 20:31:24 [HOST] abrtd: Can't open file '/var/spool/abrt/oops-2012-07-02-20:31:24-7849-0/uid': No such file or directory
Reply
0 Kudos
mfelker
Expert
Expert

For  Fedora kernels PANIC.  Try changing the VM processor preferred virtualization mode from Automatic to Binary Translation.  This  hint from  somebody    helped me to   avoid this   problem  - which I  had for  ages.

outofmemory
Contributor
Contributor

For testing purposes, I've reinstalled Fedora 17, updated it (Kernel 3.5.0-2.fc17.x86-64) and installed VMware Workstation 8.0.3 with this patch (patch-vmware803.tar) (MD5: 7e0776cda140c986b994e3d1f50eb8ad) - VMware PANIC again. Then did the exact same reinstallation on a test computer (different hardware) - and it worked.

Martin Felker wrote:

For  Fedora kernels PANIC.  Try changing the VM processor preferred virtualization mode from Automatic to Binary Translation.  This  hint from  somebody    helped me to   avoid this   problem  - which I  had for  ages.

Then I changed the virtualization engine mode from "Automatic" to "Binary translation" - and it actually WORKS!

Thank you for this tip!

The next thing I'm going to do is to change the virtualization engine mode for some VMs and see if that makes them slower.

Reply
0 Kudos
mfelker
Expert
Expert

Reply
0 Kudos