having btrfs installed as the fs is causing a crash when trying to install the intel-microcode package

[Brinstar]

I am able to reproduce a bug which causes a kernel panic when the following conditions are met:

1. Xubuntu 16.04 beta 1 is installed
2. btrfs is used as the filesystem
3. The intel-microcode package is installed after the initial system setup is complete

I have got an actual photo of the screen when the crash happens as I was unable to locate the correct log file where this would have shown up.

I can provide any logs that may be useful

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubuntu-release-upgrader-core 1:16.04.7
ProcVersionSignature: Ubuntu 4.4.0-7.22-generic 4.4.2
Uname: Linux 4.4.0-7-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CrashDB: ubuntu
CurrentDesktop: XFCE
Date: Wed Mar 16 10:00:14 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-03-15 (0 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160224)
PackageArchitecture: all
SourcePackage: ubuntu-release-upgrader
Symptom: release-upgrade
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.20.1-0ubuntu2.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: guts 1798 F.... pulseaudio
 /dev/snd/controlC0: guts 1798 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 16.04
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-09-28 (90 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
MachineType: Dell Inc. Vostro 3300
NonfreeKernelModules: nvidia_uvm nvidia wl
Package: linux (not installed)
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-57-generic root=UUID=2ca3e37e-f0ef-40ea-b0af-041ef5aaeee8 ro quiet splash
ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-57-generic N/A
 linux-backports-modules-4.4.0-57-generic N/A
 linux-firmware 1.157.6
Tags: xenial
Uname: Linux 4.4.0-57-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/08/2014
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A12
dmi.board.name: 07JC8T
dmi.board.vendor: Dell Inc.
dmi.board.version: A12
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A12
dmi.modalias: dmi:bvnDellInc.:bvrA12:bd04/08/2014:svnDellInc.:pnVostro3300:pvrA12:rvnDellInc.:rn07JC8T:rvrA12:cvnDellInc.:ct8:cvrA12:
dmi.product.name: Vostro 3300
dmi.product.version: A12
dmi.sys.vendor: Dell Inc.

[Brinstar (brinstar)]

Also wanted to mention that installing the intel-microcode package works fine with ext4, so it seems to be btrfs related

[Brinstar (brinstar)]

I had removed the package from the system using recovery mode so that's why it may show differently in the attached logs

[autumna (autumna)]

Run into a very similar, possibly same kernel panic using XFCE (Ubuntu Studio 16.04 iso livecd with persistence).

1) switch to intel microcode proprietary driver.
2) reboot results in kernel panic, the iso can no longer load.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[aidanjt (aidanjt)]

I'm confident this is related to my bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597762

[Thomas Mayer (thomas303)]

Today, I did install intel-microcode on an up-to-date 16.04 system for the very first time of the system's lifetime. My disks are all btrfs-only. There were no issues at all, and the microcode also got updated.

I do not want to argue that this bug would be non-existent but that it is not necessarily reproducable with usage of btrfs alone. Still, btrfs could play a role here.

[David McBride (david-mcbride)]

I have seen this same problem affect a VMware VM running on paravirtualized hardware. Removing the intel-microcode package and regenerating the initramfs fixed the problem.

The root filesystem for these machines is btrfs. I suspect, however, that this may be a red herring; other machines with an identical configuration have worked elsewhere on a range of desktop hardware, so I suspect the problem may be isolated to a subset of machines, e.g. those with a particular CPU revision.

/proc/cpuinfo on the virtualized machine I seen this problem on reads as follows:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz
stepping : 4
microcode : 0x427
cpu MHz : 2200.000
cache size : 25600 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm epb fsgsbase smep dtherm ida arat pln pts
bugs :
bogomips : 4400.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

[Henrique de Moraes Holschuh (hmh)]

Well, a couple points.

1. Never attempt to update microcode from inside a VM. It is supposed to fail in the first place (not with a crash, though). Do it on the host/hyper-visor/dom0.

2. The processors showing an issue are too different, and running microcode updates that have been in the field for a long time, without any sort of crash reports. This is *extremely* unlikely to be an issue with the microcode update itself.

3. Therefore, this is leaves us with a bootloader, kernel or initramfs bug.

4. The live-cd issue might be an entirely different bug: the microcode update process requires that the initramfs image be modified, so it requires the live-cd bootloader to deal with reading the modified initramfs *properly*. It can be done using syslinux and the exactly correct setup for kernel/initramfs modification persistence (hint: no overlays). I have no idea if this specific live-cd does anything remotely like that, and if it doesn't use btrfs, it is likely to be a separate bug anyway.

Now, microcode updates are applied by the kernel well before *anything* filesystem-related runs, so the btrfs kernel code is not directly involved with the microcode update process itself (the data is loaded by the *bootloader*).

Unfortunately, we don't have enough information on this bug report to know what happened (we need a kernel log up to the crash for that :-( ).

Anyway, this bug likely has to be reassigned to the kernel...

[Robie Basak (racb)]

I happen to have come across this. I don't have the knowledge to help, but it does sound like this is a kernel issue rather than a problem with the intel-microcode package, so let's reassign it. Otherwise it won't get attention from anyone who might know.

"Critical" importance is probably not correct, but I'll let the kernel team triagers decide that.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1557989

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Brinstar (brinstar)]

apport information

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.10 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc2

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]