Hi again, got it fixed. The Debian on MS Surface Pro 4 Guide [1] at the last point "Troubleshooting" mentioned something about EFI being out of space. Though on Debian it's a different error than the one I got. I still tried what was suggested there: mkdir /tmp/efivars mount -t efivarfs none /tmp/efivars rm /tmp/efivars/dump-type0-* After that I had to reboot into Windows again, cuz the previous attempts with efibootmgr removed the entry i had set again, so I created a new entry "TempLinux" with EasyUEFI tool. Booted Linux again and repeated the below mentioned efibootmgr command. This time it didn't result in the error but instead lists all boot entries, including the newly created "opensuse" one. # efibootmgr -c -d /dev/nvme0n1 -p 1 -w -L opensuse -l \EFI\opensuse\grubx64.efi BootCurrent: 0003 Timeout: 2 seconds BootOrder: 0004,0003,0001,0002,0005,0006 Boot0000* MsTemp Boot0001* Windows Boot Manager Boot0002* Internal Storage Boot0003* TempLinux Boot0005* USB Storage Boot0006 PXE Network Boot0004* opensuse 1: https://github.com/jimdigriz/debian-mssp4 Am Dienstag, den 11.10.2016, 17:33 +0200 schrieb Michael Melcher:
Hi,
sorry for the late reply. I had some troubles with my Surface and had to do a full factory reset.
The factory reset also did reset the EFI to the state it was at shipping time.
Before I did the reset though I did try other kernels, as you suggested that that might be the reason. I tried kernel:stable but got the same issue.
Now after resetting the device I installed 42.2 again and got the same issue. I could set up the EFI Boot entry with the EasyUEFI tool, though, to boot into Linux.
Everything below is from the fresh install:
Am Mittwoch, den 05.10.2016, 20:08 +0300 schrieb Andrei Borzenkov:
Where do you see this status? efibootmgr itself return 0 or 1.
I see this Status in both, grub2-install and in efibootmgr. grub2-install -v [cutoff] grub2-install: info: adding 181 padding fixup entries. grub2-install: info: writing 952 bytes of a fixup block starting at 0xc000. grub2-install: info: reading /usr/lib/grub2/x86_64-efi/fshelp.mod. grub2-install: info: reading /usr/lib/grub2/x86_64-efi/ext2.mod. grub2-install: info: reading /usr/lib/grub2/x86_64-efi/part_gpt.mod. grub2-install: info: kernel_img=0x1848b90, kernel_size=0x18a00. grub2-install: info: the core size is 0x1c6d8. grub2-install: info: writing 0x1da00 bytes. grub2-install: info: copying `/boot/grub2/x86_64-efi/core.efi' -> `/boot/efi/EFI/opensuse/grubx64.efi'. grub2-install: info: Registering with EFI: distributor = `opensuse', path = `\EFI\opensuse\grubx64.efi', ESP at hostdisk//dev/nvme0n1,gpt1. grub2-install: info: executing efibootmgr --version
/dev/null.
grub2-install: info: executing modprobe -q efivars. grub2-install: info: executing efibootmgr -b 0003 -B.
requested operation failed: status=8000000000000002
grub2-install: info: executing efibootmgr -c -d /dev/nvme0n1 -p 1 -w -L opensuse -l \EFI\opensuse\grubx64.efi.
requested operation failed: status=8000000000000002
Installation finished. No error reported.
# efibootmgr -c -d /dev/nvme0n1 -p 1 -w -L opensuse -l \EFI\opensuse\grubx64.efi
requested operation failed: status=8000000000000002
There already exist a couple bug reports for that from fedora, launchpad (ubuntu) and others - although for other devices. These bug reports date back between 2 and 4 years already.
References, please.
Google for the Status Code and shows the date too.
Newer Versions of efibootmgr don't seem to have this issue anymore, as I had successfully installed Tumbleweed, Debian Jessie and Debian Sid on my Surface. Only the version in Leap 42.x got this problem.
How do you know it is efibootmgr? Did you test different versions under the same conditions? All mentioned distros have different kernels.
As mentioned above, I tried a newer Kernel, with the same result.
Thus updating to a newer version - which has already been tested for a while in Tumbleweed, would not only fix this issue but also add support for other newer devices
Very little is needed from efibootmgr for what we use it - entering reference to a file on ESP. I would be very surprised if failure were due to efibootmgr.
All I can say is, that it worked well with Debian and Tumbleweed, both have a newer efibootmgr version.
Since I can't add a EFI Menu Entry from within the EFI manually I am stuck with an installed Linux that can't be booted.
The first thing to test is to manually set variable via efivarfs. If this fails, it has nothing to do with efibootmgr.
Please elaborate on this. Give an example maybe?
Kind regards Michael Melcher -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org