14.04 ovmf causes oops when running update-grub under kvm

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.

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.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

This change was made by a bot.

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 ]---

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

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

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/

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.

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.

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