Kernel panics and boot problems in Zesty

[Barry Warsaw]

Back in Yakkety, I reported LP: #1627198 which described boot problems with the 4.8.0 kernel on a VMware Fusion guest of Yakkety. With a fresh install on Zesty, I'm seeing very similar boot problems.

With linux-image-generic 4.8.0.26.35, the system booted, but will not reboot. After the verbose console output during boot, I get a blank black screen and never get to the greeter screen.

If I then restore the known good (and running) snapshot, then dist-upgrade, the behavior is even worse. I see the kernel crash described in #1627198 and then the kernel panics.

So it looks like the problem has returned for Zesty.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: linux-image-4.8.0-26-generic 4.8.0-26.28 [modified: boot/vmlinuz-4.8.0-26-generic]
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: barry 2204 F.... pulseaudio
CurrentDesktop: Unity
Date: Tue Nov 8 19:25:32 2016
HibernationDevice: RESUME=UUID=f8d45a41-2138-40db-9c89-164021e8f811
InstallationDate: Installed on 2016-11-07 (1 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20161107)
IwConfig:
 ens33 no wireless extensions.

 lo no wireless extensions.
MachineType: VMware, Inc. VMware Virtual Platform
ProcFB: 0 svgadrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-26-generic root=UUID=ec4bce78-74fa-43dc-af9e-b26a9a2d562a ro
RelatedPackageVersions:
 linux-restricted-modules-4.8.0-26-generic N/A
 linux-backports-modules-4.8.0-26-generic N/A
 linux-firmware 1.161
RfKill:
 1: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/02/2015
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd07/02/2015:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Barry Warsaw (barry)]

4.8.0-27.29 from zesty-proposed does *not* fix the problem.

[Seth Forshee (sforshee)]

You're seeing the same usercopy crash? That doesn't make sense - zesty currently uses yakkety kernels, and the offending option is still disabled. Can you post the text from the oops here?

[Barry Warsaw (barry)]

Okay, this is highly strange, and quite unpredictable.

Because the boot console output in Fusion scrolled off and can't be captured (AFAICT), I don't have specifics, but there was definitely an oops and a kernel crash. At the end of the output I saw something like "recursive error fixed, reboot required". I didn't notice this before so I'd just restored an older known good snapshot and then went through the entire dist-upgrade path again, and each time got the same oops.

But then I noticed this last line, instead of restoring the snapshot I just power cycled the VM (though the Fusion menu item). This time it booted successfully, and I did *not* notice an oops.

Now the behavior is completely unpredictable. There seems to be a couple of end states when I boot this dist-upgraded Zesty VM, in roughly the order of most common to least common observation.

1) The console output scrolls by very quickly and the last thing I see is that lightdm is starting. Then the screen blacks and never comes back. Cannot log in.

2) Kernel oops ending with "invalid opcode: 0000 [#1] SMP" and a stack trace that I cannot see the bottom of.

3) Kernel oops which I can't see the top of, but includes a stack trace and ends in the message "BUG: unable to handle kernel paging request at 0000000ef62f811"

4) The boot process completes at the login screen, and I can log into the desktop just fine.

5) Console boot output proceeds seemingly as normal. The last thing I see is "[ OK ] Started Network manager Script Dispatcher Service" (although the last OK I see does change), then Fusion pops up a dialog that says "The CPU has been disabled by the guest operating system", meaning to me that the virtual CPU simply halted.

Crazy!

I'll see if there's some magic to get Fusion to capture the console output.

[Barry Warsaw (barry)]

FTR: OS X 10.11.6 fully updated

Fusion 8.5.2 (4635224)

[Seth Forshee (sforshee)]

One thing that you can try is checking dmesg and /var/log/kern.log from your successful boots to see if any oopses are logged in either place. If we can't get the kernel messages then we may have to resort to a bisect.

[Barry Warsaw (barry)]

dmesg from a successful boot

[Barry Warsaw (barry)]

Interestingly, kern.log is empty

[Seth Forshee (sforshee)]

There are a couple of things in kern.log.1 with 4.8.0-26, but if the dates in the log can be trusted they're from about a week ago. One of them looks like the same issue as in bug 1630774, and that one has a fix in 4.8.0-28.30. That build is still in the c-k-t ppa waiting to be copied out to -proposed, so could you give that build a try and see if it helps?

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/11179680

The other thing is a soft lockup which doesn't make any sense to me yet.

[Barry Warsaw (barry)]

On Nov 15, 2016, at 07:24 PM, Seth Forshee wrote:

>There are a couple of things in kern.log.1 with 4.8.0-26, but if the
>dates in the log can be trusted they're from about a week ago. One of
>them looks like the same issue as in bug 1630774, and that one has a fix
>in 4.8.0-28.30. That build is still in the c-k-t ppa waiting to be
>copied out to -proposed, so could you give that build a try and see if
>it helps?

.30 gave me 4 successful reboots in a row. Thanks!

[Seth Forshee (sforshee)]

Great! Based on that I'm marking this a duplicate of bug 1630774.