Ubuntu 16.10 does not start on Vmware Workstation 10.0.7

Did you install server or desktop?
Did you MD5 test the ISO you downloaded?

It's desktop version.
I will check md5sums but I'm sure there OK: I've had the same problem also
on beta, and on some daily images I tried after beta

Il gio 13 ott 2016, 18:32 actionparsnip <
<email address hidden>> ha scritto:

> Your question #402993 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/402993
>
> Status: Open => Needs information
>
> actionparsnip requested more information:
> Did you install server or desktop?
> Did you MD5 test the ISO you downloaded?
>
> --
> To answer this request for more information, you can either reply to
> this email or enter your reply at the following page:
> https://answers.launchpad.net/ubuntu/+question/402993
>
> You received this question notification because you asked the question.
>

Have you tried different video options in the VM?

I tried disabling the option accelerate 3d graphics and I got the same result.

I managed to get some debugging info by starting in recovery model and resuming to normal boot (the recovery menu shows, but after resume I get the crash before X startup).
I see a kernel panic, but I couldn't get the full screenshot because the console is frozen.
https://postimg.org/image/43dhdbb7h/
Do you know a way to capture the full log?

I also tried to run the X failsafe mode: X starts, but then I don't know what to do now

Thanks for your help!

Have you tried Xubuntu? It doesn't require compositing.

If that works then we know it's a video issue, or you can just use Xubuntu :-)

I have the same problem wit XUbuntu

All I can suggest is report a bug. Maybe others can advise here

Do you have to use VMWare? Is there no scope to use Virtualbox?

I need vmware
I will try to open a bug. Which package should I file to?

thanks

Add the following line to your vmx file:

cpuid.1.eax = "0000:0000:0000:0001:0000:0110:1010:0101"

it works ;)

It seems to work. Can you tell me what does that line do?

I've found it as a workaround for esx migration.
Changes the CPU information passed to the guest OS (Stepping, model, family, proc type..)
But I really don't know why Ubuntu don't like the original one.

Out of curiosity, are you on desktop or mobile PC?

I have a laptop: Lenovo W540 with i7-4800MQ
Do you think it is worth to open a bug?

Sure seems an issue related to the CPU ( I have a similar CPU), but I wonder if is an hypervisor issue or it's the same installing directly on the system.

My processor is i7-4900k and I also have this issue.
Blade's fix help me.

I have the same problem in my Windows 7 64bit VMware Workstation 12 Pro. My CPU is Intel Core i5-4210U. The guest OS is Ubuntu 16.10 Desktop AMD64.

I captured the kernel crash stack trace screenshot <https://www.dropbox.com/s/qyz940qgfd0w0kt/Ubuntu16.10-2016-10-14-19-27-16.png?dl=1> with luck, since it usually hang on Ubuntu splash rolling dots screen.

Bye the way, I tried the same guest OS (Ubuntu 16.10 Desktop AMD64) in the VirtualBox, it could boot to desktop. But Ubuntu 16.10 seems not very stable, especially when I installed and configured the fcitx chewing input mothod, it'll crash the whole VirtualBox.

VMware is internally tracking this issue under problem report 1747569.

Our engineering team believes we have identified a regression in the Linux kernel's intel_powerclamp module which will render Ubuntu 16.10 unreliable in a VMware virtual machine on certain modern Intel host CPUs in certain virtual machine configurations. If the virtual CPU does not expose the MONITOR/MWAIT feature, a defect in function powerclamp_probe causes the intel_powerclamp module to attempt to use the MONITOR instruction anyway, which leads to the onset of a failure cascade ending with the guest OS halting the CPU.

We are preparing a fix for the underlying issue, and will send it to LKML when it's ready.

The initial failure (which will almost certainly have scrolled off the top of the guest console) is:

[ 5.736416] invalid opcode: 0000 [#1] SMP
[ 5.736455] Modules linked in: vmw_vsock_vmci_transport vsock vmw_balloon intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw glue_helper ablk_helper cryptd intel_rapl_perf input_leds joydev serio_raw snd_ens1371 snd_ac97_codec gameport ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore i2c_piix4 shpchp vmw_vmci nfit floppy(+) mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci e1000 mptspi mptscsih psmouse mptbase vmwgfx scsi_transport_spi ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm pata_acpi fjes
[ 5.744370] CPU: 1 PID: 912 Comm: kidle_inject/1 Not tainted 4.8.0-22-generic #24-Ubuntu
[ 5.744373] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[ 5.744375] task: ffff9658f7a663c0 task.stack: ffff9658fa908000
[ 5.744378] RIP: 0010:[<ffffffffc05728b8>] [<ffffffffc05728b8>] clamp_thread+0x2b8/0x5d0 [intel_powerclamp]
[ 5.744380] RSP: 0018:ffff9658fa90be00 EFLAGS: 00010246
[ 5.744383] RAX: ffff9658fa908008 RBX: 00000000fffee0a6 RCX: 0000000000000000
[ 5.744386] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 5.744388] RBP: ffff9658fa90bec0 R08: ffff9658fa908000 R09: 0000000000000000
[ 5.744391] R10: 000000000001cbf7 R11: 0000000000000000 R12: ffffffff8db581a0
[ 5.744393] R13: ffff9658fa908000 R14: 0000000000000000 R15: ffff9658fa908000
[ 5.744396] FS: 0000000000000000(0000) GS:ffff9658fc640000(0000) knlGS:0000000000000000
[ 5.744398] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.744401] CR2: 00007ffa6cc262e8 CR3: 000000003ab3b000 CR4: 00000000001406e0
[ 5.744403] Stack:
[ 5.744406] 0000000000000001 ffff9658f7a66dc0 ffff9658fc659200 00000000e878d638
[ 5.744409] 0000000000000001 00000002fc659200 0000000000000001 ffff9658fa908008
[ 5.744411] 0000000000000000 ffff9658fc64fea8 00000000fffee0a6 ffffffffc05720a0
[ 5.744414] Call Trace:
[ 5.744416] [<ffffffffc05720a0>] ? pkg_state_counter+0xa0/0xa0 [intel_powerclamp]
[ 5.744419] [<ffffffffc0572600>] ? powerclamp_set_cur_state+0x170/0x170 [intel_powerclamp]
[ 5.744421] [<ffffffffc0572600>] ? powerclamp_set_cur_state+0x170/0x170 [intel_powerclamp]
[ 5.744424] [<ffffffff8cca3c18>] kthread+0xd8/0xf0
[ 5.744427] [<ffffffff8d49f29f>] ret_from_fork+0x1f/0x40
[ 5.744429] [<ffffffff8cca3b40>] ? kthread_create_on_node+0x1e0/0x1e0
[ 5.744432] Code: cc e9 ba 00 00 00 eb 19 0f 1f 00 0f ae f0 65 48 8b 04 25 04 69 01 00 0f ae b8 08 c0 ff ff 0f ae f0 31 d2 48 8b 44 24 38 48 89 d1 <0f> 01 c8 49 8b 45 08 a8 08 75 0b b9 01 00 00 00 4c 89 f0 0f 01
[ 5.744434] RIP [<ffffffffc05728b8>] clamp_thread+0x2b8/0x5d0 [intel_powerclamp]
[ 5.744437] RSP <ffff9658fa90be00>
[ 5.744440] invalid opcode: 0000 [#2] SMP
[ 5.744452] ---[ end trace cf659c4076bf2804 ]---

I had the same problem.

1- Edit Ubuntu VM Configuration file (.vmx)

2- Add the following line cpuid.1.eax = "0000:0000:0000:0001:0000:0110:1010:0101"

3- Save the configuration file

4- Power on Ubuntu VM
I found this solution on YouTube Video.
Source: https://youtu.be/S7tC90nJQA4

Change the cpuid.1.eax is a workaround before discovering the root cause.

There is another workaround after discovered the root cause: "Add the kernel command-line option modprobe.blacklist=intel_powerclamp". This is from the VMware Communities <https://communities.vmware.com/message/2626830#2626830> where has details.

I think the cpuid.1.eax one is still the easist way to workaround this problem. :)

Setting cpuid.1.eax is certainly the easiest solution for most desktop virtualization users, but such a wholesale replacement of the virtual CPU's family/model/stepping data has the potential to cause other problems which might be much more difficult to troubleshoot, particularly if the workaround is applied incorrectly or is applied in a situation where it is not actually needed (e.g. with older Intel CPUs).

Although the "modprobe.blacklist" kernel command-line option is more difficult to implement, VMware strongly advises that it be used instead of the "cpuid.1.eax" VM config-file workaround. Blacklisting the module is a targeted workaround which will result in a significantly lower risk of undesirable side-effects.

That said, as long as you are confident in your ability to apply the "cpuid.1.eax" workaround accurately, understand the implications of what it's doing, and are confident in your ability to troubleshoot any potential complications which might arise, you can feel free to use it... It will be equally effective in stopping the failure from occurring.

Is there a bug in Launchpad for this?

halvors wrote:
> Is there a bug in Launchpad for this?

Yes, here: https://bugs.launchpad.net/ubuntu/yakkety/+source/linux/+bug/1630774