Created attachment 844705 [details] baseline dmesg output Description of problem: on a Lenovo x120e, the install fails at the step to install the boot entry. Version-Release number of selected component (if applicable): UEFI firmware 1.16 How reproducible: always. Steps to Reproduce: 1. set up install with complete replacement of drive content 2. install proceeds through adding components and post-install process 3. at setp to install efiboot the process stops Actual results: See Bug 1006304 for trace details. Attached are attempts to run efibootmgr by booting the f20 live x86_64 DVD. Expected results: Install successfully installs efiboot and completes normally. Additional info: Assumption was that NVRAM as too full. Booted the live x86_64 DVD and used efibootmgr to remove the last entry, LAN boot, and take it out of the boot list, producing the following for efibootmgr -v: BootCurrent: 0005 Timeout: 0 seconds BootOrder: 0005,0006,0007,0008 Boot0000 Setup Boot0001 Boot Menu Boot0002 Diagnostic Splash Screen Boot0003 Rescue and Recovery Boot0004 Startup Interrupt Menu Boot0005* USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55 Boot0006* USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49 Boot0007* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600 Boot0008* USB HDD 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803 Then tried: efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi No change reported to efibootmgr -v Rebooted and next tried: dmesg -n7 dmesg > dmseg.1 efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi dmesg > dmseg.2 efibootmgr -v Still no change. See attachments
Created attachment 844706 [details] dmesg output after efibootmgr update attempt
Possibly related: qemu 1.6.1-3, running a recent snapshot of the OVMF UEFI firmware (from https://launchpad.net/ubuntu/trusty/+package/ovmf), with qemu -pflash mode (trying to get read/write access to flash), trying to install the f20 x86-64 live-image, the kernel oopses: [ 0.000000] Linux version 3.11.10-301.fc20.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC) ) #1 SMP Thu Dec 5 14:01:17 UTC 2013 [ 0.000000] Command line: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Xfce-x86_64-20-1 ro rd.live.image quiet rhgb nomodeset [...] [ 0.000000] efi: EFI v2.31 by EDK II [ 0.000000] efi: ACPI=0x7ca70000 ACPI 2.0=0x7ca70014 [ 0.000000] efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x00000000000a0000) (0MB) [ 0.000000] efi: mem01: type=2, attr=0xf, range=[0x0000000000100000-0x0000000000102000) (0MB) [ 0.000000] efi: mem02: type=7, attr=0xf, range=[0x0000000000102000-0x0000000000800000) (6MB) [ 0.000000] efi: mem03: type=4, attr=0xf, range=[0x0000000000800000-0x0000000001000000) (8MB) [ 0.000000] efi: mem04: type=2, attr=0xf, range=[0x0000000001000000-0x0000000002409000) (20MB) [ 0.000000] efi: mem05: type=7, attr=0xf, range=[0x0000000002409000-0x000000003e0a9000) (956MB) [ 0.000000] efi: mem06: type=2, attr=0xf, range=[0x000000003e0a9000-0x0000000040000000) (31MB) [ 0.000000] efi: mem07: type=7, attr=0xf, range=[0x0000000040000000-0x000000005a8e1000) (424MB) [ 0.000000] efi: mem08: type=2, attr=0xf, range=[0x000000005a8e1000-0x0000000079000000) (487MB) [ 0.000000] efi: mem09: type=4, attr=0xf, range=[0x0000000079000000-0x0000000079020000) (0MB) [...] [ 0.000000] Hypervisor detected: KVM [...] [ 0.000000] ACPI: RSDP 000000007ca70014 00024 (v02 OVMF ) [ 0.000000] ACPI: XSDT 000000007ca6f0e8 0003C (v01 OVMF OVMFEDK2 20130221 01000013) [ 0.000000] ACPI: FACP 000000007ca6e000 000F4 (v03 OVMF OVMFEDK2 20130221 OVMF 00000099) [ 0.000000] ACPI: DSDT 000000007ca6c000 00D57 (v01 INTEL OVMF 00000004 INTL 20131218) [ 0.000000] ACPI: FACS 000000007ca74000 00040 [ 0.000000] ACPI: APIC 000000007ca6d000 00080 (v01 OVMF OVMFEDK2 20130221 OVMF 00000099) [ 0.000000] ACPI: SSDT 000000007ca6b000 00057 (v01 REDHAT OVMF 00000001 INTL 20131218) [...] [ 144.463921] BUG: unable to handle kernel paging request at 000000007cfd0058 [ 144.463934] IP: [<ffff88007b32d6be>] 0xffff88007b32d6bd [ 144.463945] PGD 76788067 PUD 0 [ 144.463950] Oops: 0000 [#1] SMP [ 144.463955] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth xt_conntra ck cfg80211 rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf _nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_n at_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ppdev microcode parport_pc i2c_piix4 parport serio_raw nfsd a uth_rpcgss nfs_acl lockd isofs squashfs btrfs xor zlib_deflate raid6_pq libcrc32c virtio_net virtio_balloon drm_kms_helper ttm virtio _pci virtio_ring drm virtio i2c_core ata_generic pata_acpi sunrpc loop [ 144.464015] CPU: 1 PID: 1754 Comm: efibootmgr Not tainted 3.11.10-301.fc20.x86_64 #1 [ 144.464019] task: ffff88007cca87a0 ti: ffff880076774000 task.ti: ffff880076774000 [ 144.464022] RIP: 0010:[<ffff88007b32d6be>] [<ffff88007b32d6be>] 0xffff88007b32d6bd [ 144.464027] RSP: 0018:ffff880076775b00 EFLAGS: 00010002 [ 144.464029] RAX: 000000007cfd0048 RBX: ffffffffffffff8f RCX: 0000000000000000 [ 144.464031] RDX: 000000000000004e RSI: ffff880076775e20 RDI: ffff88007ca47018 [ 144.464033] RBP: ffff880076775c10 R08: 0000000000000000 R09: ffff880076775e2f [ 144.464035] R10: ffffffff814ff0ff R11: 0000000000000004 R12: 0000000000000007 [ 144.464037] R13: 0000000000000070 R14: ffffffff81fd5aa0 R15: ffffffff81cb7200 [ 144.464043] FS: 00007f18ba647740(0000) GS:ffff88007a500000(0000) knlGS:0000000000000000 [ 144.464046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 144.464048] CR2: 000000007cfd0058 CR3: 000000007676c000 CR4: 00000000000006e0 [ 144.464062] Stack: [ 144.464064] ffff88007ca53044 ffff880076775e20 0000000000000010 ffffffff812b45fc [ 144.464069] ffff880076775bc8 0000000700000000 0000000000000070 ffff880074688418 [ 144.464072] ffff880076775e20 ffff88007468c000 ffffffff812a85dc ffffffff812af0a3 [ 144.464076] Call Trace: [ 144.464133] [<ffffffff812b45fc>] ? mls_context_isvalid+0x2c/0xb0 [ 144.464138] [<ffffffff812a85dc>] ? sidtab_context_to_sid+0x30c/0x480 [ 144.464141] [<ffffffff812af0a3>] ? string_to_context_struct+0x293/0x380 [ 144.464163] [<ffffffff810622eb>] ? efi_call5+0x4b/0x80 [ 144.464169] [<ffffffff81061a21>] ? virt_efi_set_variable+0x31/0x40 [ 144.464194] [<ffffffff814fdff6>] ? efivar_entry_set+0x116/0x140 [ 144.464198] [<ffffffff814ff167>] ? efivar_create+0xd7/0x200 [ 144.464210] [<ffffffff8121dcb0>] ? write+0x100/0x180 [ 144.464217] [<ffffffff811a8f7d>] ? vfs_write+0xbd/0x1e0 [ 144.464221] [<ffffffff811b434b>] ? putname+0x2b/0x40 [ 144.464225] [<ffffffff811a99b9>] ? SyS_write+0x49/0xa0 [ 144.464244] [<ffffffff810e6596>] ? __audit_syscall_exit+0x1f6/0x2a0 [ 144.464263] [<ffffffff816533d9>] ? system_call_fastpath+0x16/0x1b [ 144.464265] 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 7b 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 [ 144.464316] RIP [<ffff88007b32d6be>] 0xffff88007b32d6bd [ 144.464321] RSP <ffff880076775b00> [ 144.464323] CR2: 000000007cfd0058 [ 144.464327] ---[ end trace ca87859527dc905f ]---
Related LP bug & comment (specific to OVMF): https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1274376/comments/15 The common part between the LP bug and comment 2 here is: virt_efi_set_variable() efi_call5() <outer space> I suspect that something in the kernel wrt. the virtual mapping of runtime services was broken for a while, temporarily. The following command on the upstream tree: git log --no-merges --oneline --reverse v3.10.. -- \ drivers/firmware/efi/ \ arch/x86/platform/efi/ \ arch/x86/include/asm/efi.h \ include/linux/efi.h lists quite a few commits, so I think it should be bisectable. However I have no clue how backports go into Fedora kernels -- that is, how to bisect a Fedora kernel. For example, the dmesg attachments and comment 2 too mention "3.11.10-301.fc20", but if I go now to koji, the most recent Fedora 20 kernel is "3.13.3-201.fc20". It has jumped two minor upstream releases in the version part, and the downstream build counter (the release part) has probably become completely unrelated. A nonlinear release history doesn't exactly simplify bisection. Since the BZ was reported for rawhide... does it reproduce with the most recent "rawhide, Fedora-Live-Desktop-x86_64" build? http://koji.fedoraproject.org/koji/tasks?state=closed&view=tree&method=livecd&order=-id (Currently the most recent one seems to be task 6521698, with a 3.14rc2 based kernel.) In any case, the Fedora 20 live CD (with kernel 3.11.10-301.fc20.x86_64) could be busted for good, since Fedora doesn't seem to update live images: http://forums.fedoraforum.org/showthread.php?t=234915
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.