Updating shim-signed freezes computer during postinstall

Bug #1491615 reported by Jens on 2015-09-02
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

When performing an update using ubuntu's default GUI tool, during the "configuring shim-signed" message, the computer freezes and needs to be reset. Unfortunately, there is nothing in the system log except for corruption (a lot of null bytes). But I experience these hard freezes regularly, whenever a GRUB or EFI related package is being updated, always during postinstall.

[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ESRT=0xd9f7f998 ACPI=0xd8f97000 ACPI 2.0=0xd8f97000 SMBIOS=0xf04d0 MPS=0xfd510
[ 0.000000] esrt: Reserving ESRT space from 0x00000000d9f7f998 to 0x00000000d9f7f9d0.
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: MSI MS-7817/CSM-B85M-E45 (MS-7817), BIOS V10.9 04/21/2015
Linux kiste 3.19.0-26-generic #28~14.04.1-Ubuntu SMP Wed Aug 12 14:09:17 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

This bug exists and keeps reappearing since I originally installed Ubuntu 14.04. However, for some reason it does not happen with a very similar second machine. This machine does not load the 'efi' kernel module on boot, can this be the reason?

[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: MSI MS-7817/H81M-P33 (MS-7817), BIOS V1.5 05/30/2014
Linux desktop 3.19.0+ #6 SMP Sat Feb 21 20:08:01 CET 2015 x86_64 x86_64 x86_64 GNU/Linux

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: shim-signed 1.9+0.8-0ubuntu2
ProcVersionSignature: Ubuntu 3.19.0-26.28~14.04.1-generic 3.19.8-ckt4
Uname: Linux 3.19.0-26-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.12
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Sep 2 09:33:16 2015
SourcePackage: shim-signed
UpgradeStatus: No upgrade log present (probably fresh install)
ApportVersion: 2.14.1-0ubuntu3.13
Architecture: amd64
 /dev/snd/controlC1: jens 2628 F.... pulseaudio
 /dev/snd/controlC0: jens 2628 F.... pulseaudio
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=/dev/mapper/linuxkiste--vg-swap_1
 p2p1 no wireless extensions.

 lo no wireless extensions.
MachineType: MSI MS-7817
Package: linux (not installed)
 PATH=(custom, no user)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-28-generic root=/dev/mapper/hostname--vg-root ro splash quiet netconsole=6666@,6665@ vt.handoff=7
ProcVersionSignature: Ubuntu 3.19.0-28.30~14.04.1-generic 3.19.8-ckt5
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
 linux-restricted-modules-3.19.0-28-generic N/A
 linux-backports-modules-3.19.0-28-generic N/A
 linux-firmware 1.127.15

Tags: trusty
Uname: Linux 3.19.0-28-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)

_MarkForUpload: True
dmi.bios.date: 04/21/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V10.9
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: CSM-B85M-E45 (MS-7817)
dmi.board.vendor: MSI
dmi.board.version: 2.0
dmi.chassis.asset.tag: To be filled by O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 2.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV10.9:bd04/21/2015:svnMSI:pnMS-7817:pvr2.0:rvnMSI:rnCSM-B85M-E45(MS-7817):rvr2.0:cvnMSI:ct3:cvr2.0:
dmi.product.name: MS-7817
dmi.product.version: 2.0
dmi.sys.vendor: MSI

Jens (jens-launchpad-net) wrote :
Steve Langasek (vorlon) wrote :

The only code that's executed in the shim-signed maintainer script is grub-install, so if this is a bug in Ubuntu code it would have to be a bug in grub2 or something that grub2 calls.

If you run 'efibootmgr -v', does it reproduce the behavior?

This is most likely a bug in your firmware and not in Ubuntu.

affects: shim-signed (Ubuntu) → grub2 (Ubuntu)
Changed in grub2 (Ubuntu):
status: New → Incomplete
Jens (jens-launchpad-net) wrote :
Download full text (3.9 KiB)

This bug is triggered during "os-prober" when it finds an active swap partition. At least, this is what is visible in the syslog.

The kernel log shows this:

[61932.439623] general protection fault: 0000 [#1] SMP
[61932.439644] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c uas usb_storage pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bnep rfcomm bluetooth nls_iso8859_1 intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm serio_raw lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic 8250_fintek tpm_infineon snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi mac_hid intel_smartconnect snd_seq snd_seq_device snd_timer snd mei_me mei shpchp soundcore parport_pc ppdev lp parport dm_crypt netconsole configfs hid_generic usbhid hid mxm_wmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper i2c_algo_bit cryptd drm_kms_helper drm ahci r8169 libahci mii wmi video
[61932.439979] CPU: 3 PID: 22789 Comm: cat Tainted: G W OE 3.19.0-26-generic #28~14.04.1-Ubuntu
[61932.440001] Hardware name: MSI MS-7817/CSM-B85M-E45 (MS-7817), BIOS V10.9 04/21/2015
[61932.440019] task: ffff88012a7c13a0 ti: ffff8800c7cfc000 task.ti: ffff8800c7cfc000
[61932.440097] RIP: 0010:[<ffffffff8106eebc>] [<ffffffff8106eebc>] efi_call+0x7c/0x100
[61932.440118] RSP: 0018:ffff8800c7cffc60 EFLAGS: 00010002
[61932.440131] RAX: 0000000000000001 RBX: 0000000000000092 RCX: ffff8802116c7000
[61932.440148] RDX: ffff8802116c7400 RSI: ffff8802116c7000 RDI: 2d78756e696c2f63
[61932.440164] RBP: ffff8800c7cffd48 R08: ffff8802116c7820 R09: ffff8802116c7410
[61932.440181] R10: 0000000000001000 R11: 0000000000000246 R12: ffff8802116c7000
[61932.440197] R13: ffff8802116c7400 R14: ffff8802116c7820 R15: 000000000009a000
[61932.440214] FS: 00007ffa57bf6740(0000) GS:ffff88021eb80000(0000) knlGS:0000000000000000
[61932.440233] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[61932.440246] CR2: 0000000001a95038 CR3: 000000000009a000 CR4: 00000000001407e0
[61932.440263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[61932.440279] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[61932.440295] Stack:
[61932.440300] 0000000000000001 000001c100000000 ffff88012a7c13a0 ffff88021edf7e08
[61932.440321] ffff8802116c7418 0000000000000001 ffff8800c7cffd00 0000000080050033
[61932.440341] 0000000000000000 0000000000000000 00007ffeca3a3880 00007ffa57664bac
[61932.440360] Call Trace:
[61932.440370] [<ffffffff81669558>] ? virt_efi_get_variable+0x68/0xa0
[61932.440386] [<ffffffff81665b08>] efivar_entry_get+0x48/0xb0
[61932.440400] [<ffffffff8166678a>] efivar_data_read+0x4a/0x90
[61932.440414] [<ffffffff81666c06>] efivar_attr_show+0x46/0x70
[61932.440430] [<ffffffff81264dfc>] sysfs_kf_seq_show+0xcc/0x1e0
[61932.440445] [<ffffffff812633f3>] kernfs_seq_show+0x23/0x30
[61932.440459] [<ffffffff8121029a>] seq_read+0xea/0x370
[61932.440472] [<ffffffff81263bd5>] kernfs_fop_read+0x105/0x170
[61932.440487] [<ffffffff811ecdd8>] __vfs_read+0x18...


Steve Langasek (vorlon) wrote :

Finding a swap partition should not trigger any EFI calls in the kernel. But calling 'efibootmgr -v' may. Have you tried running that command, as suggested in my previous message?

As far as I can see, os-prober itself never calls any EFI interfaces, it only checks for the presence of /sys/firmware/efi. Are you sure that os-prober is the process that's crashing?

This bug report does probably need to be assigned to the kernel, but I'd like to get the above information before reassigning.

Jens (jens-launchpad-net) wrote :

Sorry, I forgot. 'efibootmgr -v' (and 'sudo efibootmgr -v') neither causes an oops nor a crash. It just prints some boot information and what looks like a hex dump of the harddisks' boot sectors.

Steve Langasek (vorlon) wrote :

Thanks for the info. it's still not apparent to me what would be triggering this crash, but I think that's enough info now to assign this over to the kernel team for investigation.

affects: grub2 (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → New

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

apport-collect 1491615

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.

Changed in linux (Ubuntu):
status: New → Incomplete
Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: kernel-key

apport information

tags: added: apport-collected
description: updated

apport information

apport information

apport information

apport information

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

apport information

apport information

apport information

apport information

apport information

apport information

Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.3 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.2-unstable/

tags: added: kernel-da-key
removed: kernel-key
Jens (jens-launchpad-net) wrote :

I have installed the mainline kernel, but how do I provoke the series of operations that caused this bug, ie. a kernel update with subsequent 'Oops' in (I suppose) the 'efi' module?

On Thu, Sep 17, 2015 at 08:08:52PM -0000, Jens wrote:
> I have installed the mainline kernel, but how do I provoke the series of
> operations that caused this bug, ie. a kernel update with subsequent
> 'Oops' in (I suppose) the 'efi' module?

Can you trigger the behavior under the old kernel by running 'sudo

Jens (jens-launchpad-net) wrote :

No, unfortunately not. :(

Steve Langasek (vorlon) wrote :

On Fri, Sep 18, 2015 at 07:19:58PM -0000, Jens wrote:
> No, unfortunately not. :(

Is that true for both the old and new kernels? Is it possible that
update-grub triggers the failure only on the old kernel?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers