[opensuse-factory] Leap 42.2 efibootmgr version bump request due to bug
Hi, Both Leap 42.1 and 42.2 take efibootmgr from SLE, which is version 0.6.0 with various patches. Tumbleweed has 0.12 already. For comparison: Debian Jessy has 0.11, Sid has 14. Version 0.6.0 dates back to 2013 [1] Version 0.12 dates back to at least February 2016 [2] In July 2016 they dropped the preceding 0 Can we have a Version Bump to at least the same Version Factory has? And thus bump the version for SLE too? Problem: On my Microsoft Surface Pro 4 grub2-install calls efibootmgr which exists with 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. 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. 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 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. I could try using a Live USB Key and edit the Grub entries on it to boot the installed Leap, but that could only do as a temp fix. 1: http://linux.dell.com/efibootmgr/ 2: https://github.com/rhinstaller/efibootmgr/commits/master/Make.version Kind regards Michael Melcher -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/10/2016 18:03, Michael Melcher wrote:
Hi,
Both Leap 42.1 and 42.2 take efibootmgr from SLE, which is version 0.6.0 with various patches.
Tumbleweed has 0.12 already.
For comparison: Debian Jessy has 0.11, Sid has 14. Version 0.6.0 dates back to 2013 [1] Version 0.12 dates back to at least February 2016 [2] In July 2016 they dropped the preceding 0
Can we have a Version Bump to at least the same Version Factory has? And thus bump the version for SLE too?
Problem: On my Microsoft Surface Pro 4 grub2-install calls efibootmgr which exists with 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.
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.
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
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.
I could try using a Live USB Key and edit the Grub entries on it to boot the installed Leap, but that could only do as a temp fix.
1: http://linux.dell.com/efibootmgr/ 2: https://github.com/rhinstaller/efibootmgr/commits/master/Make.version
Kind regards Michael Melcher You should open a bug, 42.2 is only accepting bugfixes. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 5. Oktober 2016, 18:08:39 CEST schrieb Dave Plater:
On 05/10/2016 18:03, Michael Melcher wrote:
Hi,
Both Leap 42.1 and 42.2 take efibootmgr from SLE, which is version 0.6.0 with various patches.
Tumbleweed has 0.12 already.
For comparison: Debian Jessy has 0.11, Sid has 14. Version 0.6.0 dates back to 2013 [1] Version 0.12 dates back to at least February 2016 [2] In July 2016 they dropped the preceding 0
Can we have a Version Bump to at least the same Version Factory has? And thus bump the version for SLE too?
Problem: On my Microsoft Surface Pro 4 grub2-install calls efibootmgr which exists with 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.
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.
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
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.
I could try using a Live USB Key and edit the Grub entries on it to boot the installed Leap, but that could only do as a temp fix.
1: http://linux.dell.com/efibootmgr/ 2: https://github.com/rhinstaller/efibootmgr/commits/master/Make.version
Kind regards Michael Melcher
You should open a bug, 42.2 is only accepting bugfixes. Dave P
Of course I could open a bug report for this (and probably will). However, it should be considered to do a version bump anyway. 1: Tumbleweed has version 0.12 for months already, thus that version has been tested for a while. 2: Version 0.6 is over 3 years old. Fixing bugs that have already been fixed years ago just takes valuable developer resources that could be spent on maintaining the current version. 3: Not only would openSuse users profit from it on newer hardware, but also SLE users if that version bump makes it into SLE for one of the next Service Packs. Also on the only Bugfixes Topic: Just 2 weeks ago Plasma has been bumped in Beta 2 to 5.8.0 Beta. Quoting Ludwig Nussel on the topic "Since Plasma 5.8 is still a beta version it deserves more attention and thorough testing now." As far as I can see from the Tumbleweed announcements on this list Plasma 5.8 hasn't made it into Tumbleweed yet, as DimStar wrote on September 30. "KDE Plasma 5.8 is being prepared. We hope for a timely integration". Thus it was untested completely before it got into 42.2 (or am I missing something here?) So IMHO, if a Desktop System can be updated to the latest Beta, which was just released a couple days before it got included in 42.2, something core relevant like efibootmgr could be updated as well, especially since the requested bump has been tested for months already in Tumbleweed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
michael.melcher82@gmail.com schrieb:
[...] So IMHO, if a Desktop System can be updated to the latest Beta, which was just released a couple days before it got included in 42.2, something core relevant like efibootmgr could be updated as well, especially since the requested bump has been tested for months already in Tumbleweed.
While it may look like we magically made Plasma 5.8 appear in Leap just a day after the official release it required quite some coordination way in advance, packaging snapshots ahead of time and over hours of several people to make that happen. It was certainly not an ad-hoc action and not routine at all. We're heading for RC1 now, so if you found a bug with efibootmgr please file a bug in Bugzilla with the necessary information ASAP. The package maintainer has to decide how to fix that bug then. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Ludwig, thanks for explaining this. As for efibootmgr. I still think it'd be good if software that has been tested in tumbleweed for a while could be included in Leap too. Anyway, the issue I had seems to have come from no space in efivars and not from efibootmgr itself, so I'm fine :-) Kind regards Michael Melcher Am Dienstag, den 11.10.2016, 18:38 +0200 schrieb Ludwig Nussel:
michael.melcher82@gmail.com schrieb:
[...] So IMHO, if a Desktop System can be updated to the latest Beta, which was just released a couple days before it got included in 42.2, something core relevant like efibootmgr could be updated as well, especially since the requested bump has been tested for months already in Tumbleweed.
While it may look like we magically made Plasma 5.8 appear in Leap just a day after the official release it required quite some coordination way in advance, packaging snapshots ahead of time and over hours of several people to make that happen. It was certainly not an ad-hoc action and not routine at all.
We're heading for RC1 now, so if you found a bug with efibootmgr please file a bug in Bugzilla with the necessary information ASAP. The package maintainer has to decide how to fix that bug then.
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
05.10.2016 19:03, Michael Melcher пишет:
Hi,
Both Leap 42.1 and 42.2 take efibootmgr from SLE, which is version 0.6.0 with various patches.
Tumbleweed has 0.12 already.
For comparison: Debian Jessy has 0.11, Sid has 14. Version 0.6.0 dates back to 2013 [1] Version 0.12 dates back to at least February 2016 [2] In July 2016 they dropped the preceding 0
Can we have a Version Bump to at least the same Version Factory has? And thus bump the version for SLE too?
Problem: On my Microsoft Surface Pro 4 grub2-install calls efibootmgr which exists with status=8000000000000002
Where do you see this status? efibootmgr itself return 0 or 1.
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.
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.
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.
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.
I could try using a Live USB Key and edit the Grub entries on it to boot the installed Leap, but that could only do as a temp fix.
1: http://linux.dell.com/efibootmgr/ 2: https://github.com/rhinstaller/efibootmgr/commits/master/Make.version
Kind regards Michael Melcher
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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
participants (5)
-
Andrei Borzenkov -
Dave Plater -
Ludwig Nussel -
Michael Melcher -
michael.melcher82＠gmail.com