14.04 ovmf causes oops when running update-grub under kvm

Bug #1274376 reported by Jamie Strandboge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
edk2 (Ubuntu)
New
Undecided
Unassigned
linux (Ubuntu)
Incomplete
High
Unassigned

Bug Description

On up to date 14.04, if I create a vm with:
virt-install --connect=qemu:///system --name=sb-saucy-amd64 --arch=x86_64 --ram=768 \
--disk=path=<path to>/sb-saucy-amd64.qcow2,size=8,format=qcow2,bus=ide,sparse=True \
--virt-type=kvm --accelerate --hvm --cdrom=<path to>/saucy-desktop-amd64.iso \
--os-type=linux --os-variant=generic26 --graphics=vnc --network=network=default,model=virtio \
--video=cirrus --noreboot --boot=loader=OVMF.fd

I get to the EFI boot menu. Choose Install Ubuntu, then automatic partitioning, with everything else defaults. By the time it gets to 'Running update-grub', the installer kernel oops with the attached screenshot (to get it, go to tty1 when grub starts installing, then it will eventually oops when update-grub is run).

If I downgrade to ovmf that is in 13.10, the install completes without a traceback. Obviously, the kernel should not traceback, but clearly there is a problem with edk2 too, so I am filing the bug there. Please reassign as necessary.
---
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
DistroRelease: Ubuntu 13.10
HibernationDevice: RESUME=UUID=5c808fe7-5d32-4495-9356-68f006fa5726
InstallationDate: Installed on 2014-01-30 (0 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Beta amd64 (20131011)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MarkForUpload: True
Package: linux (not installed)
ProcFB: 0 cirrusdrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-15-generic.efi.signed root=UUID=23bf8ad7-6ea2-4551-aac2-051639a48858 ro quiet splash vt.handoff=7
ProcVersionSignature: User Name 3.11.0-15.23-generic 3.11.10
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-15-generic N/A
 linux-backports-modules-3.11.0-15-generic N/A
 linux-firmware 1.116
RfKill:

Tags: saucy
Uname: Linux 3.11.0-15-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Changed in edk2 (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
Revision history for this message
Steve Langasek (vorlon) wrote :

Is this reproducible for you when installing trusty (vs. saucy)? Dimitri tells me that he's successfully installed trusty inside qemu running with the new ovmf. It's possible that this is not a bug in edk2 at all, only a latent bug in the kernel that has been exposed by a behavior change in edk2.

Or it may be that his qemu configuration differs from yours in some relevant way.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

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

apport-collect 1274376

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
Revision history for this message
Jamie Strandboge (jdstrand) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected saucy
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote : BootDmesg.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : CRDA.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : Lspci.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : ProcEnviron.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : ProcModules.txt

apport information

Revision history for this message
Jamie Strandboge (jdstrand) wrote : PulseList.txt

apport information

affects: linux (Ubuntu) → linux-signed (Ubuntu)
affects: linux-signed (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → New
tags: added: bot-stop-nagging
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ok, I found that if I installed Ubuntu 13.10 in a VM with ovmf 0~20121205.edae8d2d-1, the install would complete. If I shutdown the vm and then upgrade ovmf to 0~20131029.2f34e065-1 and start the vm it runs. However, I get this traceback (apport-collected) if I run 'sudo grub-install --uefi-secure-boot':
[ 439.293814] CPU: 0 PID: 2413 Comm: efibootmgr Not tainted 3.11.0-15-generic #23-Ubuntu
[ 439.293817] task: ffff880020e79770 ti: ffff88001d3c2000 task.ti: ffff88001d3c2000
[ 439.293818] RIP: 0010:[<ffff88002e32d6be>] [<ffff88002e32d6be>] 0xffff88002e32d6bd
[ 439.293822] RSP: 0018:ffff88001d3c3b00 EFLAGS: 00010002
[ 439.293823] RAX: 000000002ffd0048 RBX: ffffffffffffff83 RCX: 0000000000000000
[ 439.293825] RDX: 000000000000004e RSI: ffff88001d3c3e20 RDI: ffff88002fa47018
[ 439.293826] RBP: ffff88001d3c3c10 R08: 0000000000000000 R09: ffff88001d3c3e2f
[ 439.293828] R10: 0000000000000064 R11: 0000000000000004 R12: 0000000000000000
[ 439.293829] R13: 0000000000000007 R14: 000000000000007c R15: ffffffff81fbe0c0
[ 439.293832] FS: 00007f1688fc1740(0000) GS:ffff88002be00000(0000) knlGS:0000000000000000
[ 439.293833] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 439.293835] CR2: 000000002ffd0058 CR3: 000000002254d000 CR4: 00000000000006f0
[ 439.293845] Stack:
[ 439.293847] ffff88002fa53044 ffff88001d3c3e20 0000000000000010 ffffffff81092599
[ 439.293850] ffff8800290d8000 0000000700000000 000000000000007c ffff880028d30418
[ 439.293853] ffff88001d3c3e20 ffff880028d33000 ffff8800290d8000 ffff88001d3c3ba8
[ 439.293855] Call Trace:
[ 439.293864] [<ffffffff81092599>] ? ttwu_do_wakeup+0x19/0xd0
[ 439.293868] [<ffffffff81094410>] ? try_to_wake_up+0x200/0x2b0
[ 439.293874] [<ffffffff8105ce2b>] ? efi_call5+0x4b/0x80
[ 439.293878] [<ffffffff8105c561>] ? virt_efi_set_variable+0x31/0x40
[ 439.293883] [<ffffffff815b4fee>] ? efivar_entry_set+0x11e/0x150
[ 439.293889] [<ffffffff8118dc98>] ? kmem_cache_alloc_trace+0x108/0x130
[ 439.293892] [<ffffffff815b6177>] ? efivar_create+0xd7/0x200
[ 439.293896] [<ffffffff8121b3e0>] ? write+0x100/0x180
[ 439.293901] [<ffffffff811a712d>] ? vfs_write+0xbd/0x1e0
[ 439.293904] [<ffffffff811a649b>] ? do_sys_open+0x1bb/0x270
[ 439.293907] [<ffffffff811a7b69>] ? SyS_write+0x49/0xa0
[ 439.293914] [<ffffffff816f721d>] ? system_call_fastpath+0x1a/0x1f
[ 439.293915] Code: d0 48 89 45 88 8b 85 1c ff ff ff 83 e0 01 85 c0 0f 84 9e 04 00 00 c6 45 df 00 48 b8 10 13 3a 2e 00 88 ff ff 48 8b 00 48 8b 40 10 <8b> 40 10 89 c0 48 89 45 80 8b 85 1c ff ff ff 83 e0 08 85 c0 74
[ 439.293940] RIP [<ffff88002e32d6be>] 0xffff88002e32d6bd
[ 439.293943] RSP <ffff88001d3c3b00>
[ 439.293944] CR2: 000000002ffd0058
[ 439.293947] ---[ end trace 56b006e298955580 ]---

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I just filed bug #1274749 and thought it might be related.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

FYI, secure boot is not enabled in OVMF and it is set to default values under Device Manager.

Revision history for this message
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 v3.13 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'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-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/v3.14-rc1-trusty/

tags: added: kernel-da-key
Changed in linux (Ubuntu):
importance: Undecided → High
status: Confirmed → Incomplete
Revision history for this message
Dimitri John Ledkov (xnox) wrote : Re: [Bug 1274376] Re: 14.04 ovmf causes oops when running update-grub under kvm

On 30 January 2014 22:57, Jamie Strandboge <email address hidden> wrote:
> apport information
>
> ** Tags added: apport-collected saucy
>
> ** Description changed:
>
> On up to date 14.04, if I create a vm with:
> virt-install --connect=qemu:///system --name=sb-saucy-amd64 --arch=x86_64 --ram=768 \
> --disk=path=<path to>/sb-saucy-amd64.qcow2,size=8,format=qcow2,bus=ide,sparse=True \
> --virt-type=kvm --accelerate --hvm --cdrom=<path to>/saucy-desktop-amd64.iso \
> --os-type=linux --os-variant=generic26 --graphics=vnc --network=network=default,model=virtio \
> --video=cirrus --noreboot --boot=loader=OVMF.fd
>

I believe --boot=loader=OVMF.fd is not correct option. A valid one is
--boot-loader=OVMF.fd.
Nonetheless, that wouldn't be ideal way to execute OVMF.fd. It's
better to make a copy of OVMF.fd and provision the copy to qemu as a
-pflash copy-of-OVMF.fd in Read-Write mode, cause then one can store
all variables & secureboot keys which survive a reboot. Does
virt-install support provisioning "-pflash" devices?

--
Regards,

Dimitri.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

On 4 February 2014 09:46, Dimitri John Ledkov <email address hidden> wrote:
> On 30 January 2014 22:57, Jamie Strandboge <email address hidden> wrote:
>> apport information
>>
>> ** Tags added: apport-collected saucy
>>
>> ** Description changed:
>>
>> On up to date 14.04, if I create a vm with:
>> virt-install --connect=qemu:///system --name=sb-saucy-amd64 --arch=x86_64 --ram=768 \
>> --disk=path=<path to>/sb-saucy-amd64.qcow2,size=8,format=qcow2,bus=ide,sparse=True \
>> --virt-type=kvm --accelerate --hvm --cdrom=<path to>/saucy-desktop-amd64.iso \
>> --os-type=linux --os-variant=generic26 --graphics=vnc --network=network=default,model=virtio \
>> --video=cirrus --noreboot --boot=loader=OVMF.fd
>>
>
> I believe --boot=loader=OVMF.fd is not correct option. A valid one is
> --boot-loader=OVMF.fd.

Bah, checked my old scripts and manual, the
--boot=loader=path/to/ovmf.fd is correct syntax.

> Nonetheless, that wouldn't be ideal way to execute OVMF.fd. It's
> better to make a copy of OVMF.fd and provision the copy to qemu as a
> -pflash copy-of-OVMF.fd in Read-Write mode, cause then one can store
> all variables & secureboot keys which survive a reboot. Does
> virt-install support provisioning "-pflash" devices?

--
Regards,

Dimitri.

tags: added: efibugs
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I'm not sure what needs doing here, unassigning myself.

Changed in edk2 (Ubuntu):
assignee: Dimitri John Ledkov (xnox) → Steve Langasek (vorlon)
Steve Langasek (vorlon)
Changed in edk2 (Ubuntu):
assignee: Steve Langasek (vorlon) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.