http://bugzilla.opensuse.org/show_bug.cgi?id=907672 Bug ID: 907672 Summary: Bootloader grub2-efi installation fails - unable to boot from EFI disk later Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: IA64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: woa46@yahoo.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- Created attachment 615396 --> http://bugzilla.opensuse.org/attachment.cgi?id=615396&action=edit strace run of successful invocation of efibootmgr I have a problem with grub2-efi that is similar to Bug 822770. On initial installation, the bootloader installation produced the message about an error in the bootloader system and gave the option of retrying or ignoring it. I tried one retry and it didn't work, so I ignored it. The system did not boot when the installation disk was removed and I booted the rescue system. On typing efibootmgr, I got the following output: BootCurrent: 0002 Timeout: 2 seconds BootOrder: 2002,2003,2001 Boot0000* EFI Network 0 for IPv4 (C4-54-44-04-C9-78) Boot0001* EFI Network 0 for IPv6 (C4-54-44-04-C9-78) Boot0002* EFI DVD/CDROM (MATSHITABD-MLT UJ272) Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network I typed: efibootmgr -c -d /dev/sdc -p 2 -L opensuse -l \\EFI\\opensuse\\grubx64.efi It failed with ENOSPC which indicates that the Bios EFI subsystem is out of resources. After this, I tried a number of things and sometimes the same command would succeed with Boot0003 correctly installed. After this, I reflashed the Bios and the command would succeed with the following output: Timeout: 0 seconds BootOrder: 0004,0003,2003,2001,2002 Boot0000* EFI USB Device (KingstonDataTraveler 3.0) Boot0001* EFI Network 0 for IPv4 (C4-54-44-04-C9-78) Boot0002* EFI Network 0 for IPv6 (C4-54-44-04-C9-78) Boot0003* opensuse-secureboot Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network Boot0004* opensuse A verbose run of efibootmgr gives the following output: BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0004,0003,2001,2003,2002 Boot0000* EFI USB Device (KingstonDataTraveler 3.0) ACPI(a0341d0,0)PCI(1d,0)USB(0,0)USB(0,0)HD(1,800,200001,5b8c0aab)RC Boot0001* EFI Network 0 for IPv4 (C4-54-44-04-C9-78) ACPI(a0341d0,0)PCI(1c,3)PCI(0,0)MAC(c4544404c978,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0RC Boot0002* EFI Network 0 for IPv6 (C4-54-44-04-C9-78) ACPI(a0341d0,0)PCI(1c,3)PCI(0,0)MAC(c4544404c978,0)030d3c000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000RC Boot0003* opensuse-secureboot HD(1,800,200001,5b8c0aab)File(\EFI\opensuse\shim.efi) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC Boot0004* opensuse HD(2,200800,32000,30ef0665-2a13-11e3-a895-a67aabe62594)File(\EFI\opensuse\grubx64.efi) (by now, I was booting off of a flash drive) I made an strace of a successful run of efibootmgr and have left it in the attachment efibootmgr.strace. Again, when I try to boot off of the disk, it indicates that there is no bootable device and when I boot off of the rescue system, the opensuse boot that I just installed is not there. It appears that for some reason, the EFI subsystem of the Bios is deleting the disk boot on system reboot. Or else, the ops->set_variable command of the EFI efi_runtime_services_64_t table is accepting the command to set the variable and silently discarding it. There is another problem that appears to be with the EFI subsystem. The intel_bios_dumper command fails with EIO. An strace of this command in operation is in the attachment for bios.strace. Finally, I tried to set up a windows boot on my flash drive with the following grub2 code: menuentry 'Windows Boot Manager (on /dev/sdc2)' { insmod chain insmod part_gpt insmod fat search --fs-uuid --set=root 62a3-a7b0 set prefix=(${root})/EFI/Microsoft/Boot echo $prefix: ls $prefix chainloader $prefix/bootmgfw.efi } On booting this entry, it properly lists the contents of the /EFI/Microsoft/Boot directory, but then fails on the invocation of the chainloader command with the message "not a valid root device". At the lower level in the grub2-efi code, it is making a call to the ops->open_protocol function of the efi_boot_services_64_t table. I cannot get the returned status with strace since this is a boot program. On conlusion, it appears that the EFI subsystem of the Bios is not performing correctly. Whether this is configuration issue or there is a more serious problem. I thought that at the minimum, your technical support staff would be able to find out why it is deleting the new boot entry on boot. I would think that this problem has occurred before during development. I thank you sincerely for any help that you can provide. -- You are receiving this mail because: You are on the CC list for the bug.