FS#32647 - [gummiboot] No entries except defaults are listed with 8-2

Attached to Project: Arch Linux
Opened by Mika Fischer (mika.fischer) - Wednesday, 14 November 2012, 11:50 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 09 March 2013, 08:00 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
I still have the issue that no entries are present, so only the defaults can be chosen (EFI default loader, EFI shell, Windows bootloader). So I can't boot Arch with gummiboot, unfortunately.

It reads loader/loader.conf, since it uses the timeout value specified there. But none of the files in loader/entries are used.

I tried adding some debug Print()s, however everything I change makes the machine lock up immediately :/ Not sure what's the best way to debug this...

Additional info:
* package version: 8-2
This task depends upon

Closed by  Tom Gundersen (tomegun)
Saturday, 09 March 2013, 08:00 GMT
Reason for closing:  Works for me
Additional comments about closing:  Please reopen if anyone can still reproduce.
Comment by Mika Fischer (mika.fischer) - Tuesday, 20 November 2012, 07:32 GMT
Tried the binary compiled by Kay Sievers, and that one works! So this seems to be yet another compilation issue...
Comment by Mika Fischer (mika.fischer) - Tuesday, 20 November 2012, 07:49 GMT
The issue is the patch [1] that Arch applies to gnu-efi-libs. Without this patch gummiboot works fine. With it applied, gummiboot cannot open the \\loader\\entries directory to read the entry files...

So whatever the patch tries to do, it's not doing it properly. Tobias, do you know what it's supposed to fix? Can it be removed?

The other patch [2] is still needed. My machine locks up immediately without it...

[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gnu-efi-libs-x86_64-call-fix.patch?h=packages/gnu-efi-libs
[2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/disable-ms_abi-flag.patch?h=packages/gnu-efi-libs
Comment by Mika Fischer (mika.fischer) - Tuesday, 20 November 2012, 09:40 GMT Comment by Keshav Amburay (the.ridikulus.rat) - Tuesday, 20 November 2012, 09:45 GMT
The gnu-efi-libs-x86_64-call-fix.patch patch comes from http://sourceforge.net/tracker/?func=detail&aid=3576537&group_id=163609&atid=828423 . The author felipec is an Arch user. The main problem that has been solved by the patch has been discussed at https://bbs.archlinux.org/viewtopic.php?pid=1174362#p1174362 . The main change in gnu-efi upstream 3.0s (from 3.0r) was to eliminate the need for the patch by using newer features of gcc >=4.6 (ms_abi) but that feature did not work properly, so was disabled by disable-ms_abi-flag.patch . If ms_abi works properly, then that change can be enabled by removing 2nd patch in which case the 1st patch is not required.

In the refind-efi-0.4.7-1 arch pkg, it was built against gnu-efi-libs-3.0s-1 which has ms_abi enabled. That failed in all systems.

The author uses fedora's gnu-efi which is currently gnu-efi 3.0q with fedora patches, whereas the latest upstream (sourceforge) release is 3.0s which Arch uses. I think the main issue in our package is the CFLAGS/CPPFLAGS/CXXFLAGS/LDFLAGS that is passed by makepkg to gnu-efi Makefile while the pkg is built.
Comment by Mika Fischer (mika.fischer) - Tuesday, 20 November 2012, 10:02 GMT
Hm, OK. But fact is that patch [1] breaks things for me that do work without it. If it fixes things that are broken for others, that's of course an unfortunate situation...

As far as I understand the spec file, Fedora uses no {C,CPP,CXX,LD}FLAGS at all:
http://pkgs.fedoraproject.org/cgit/gnu-efi.git/tree/gnu-efi.spec?h=f18&id=76e9368fa88a36c52d37a197bef693850895f53f

What flags are passed by makepkg? Maybe they should all be disabled? I'll try that in the evening.
Comment by Mika Fischer (mika.fischer) - Tuesday, 20 November 2012, 17:56 GMT
It seems that there are no {C,CPP,CXX,LD}FLAGS set by makepkg. If you look, in gnu-efi-3.0/Make.defaults, they're all set to fixed values. So that can't be the problem.
Comment by Greg KH (gregkh) - Wednesday, 28 November 2012, 17:34 GMT
I've run into this as well, I had to fall-back to using the Fedora pre-build version of gummiboot.

Anything I can to to test or debug to help out here?
Comment by Mika Fischer (mika.fischer) - Wednesday, 28 November 2012, 18:14 GMT
Would you mind trying to recompile gnu-efi-libs without the patch mentioned above and then recompile gummiboot-efi, to see if that fixes it for you too?

Steps:
- sudo abs
- Copy /var/abs/extra/gnu-efi-libs somewhere
- Edit PKGBUILD and comment out the line "patch -Np1 -i ../gnu-efi-libs-x86_64-call-fix.patch" in the build() function
- makepkg -si
- Copy /var/abs/extra/gummiboot-efi somewhere
- makepkg -si
- Do whatever you need to do to put the new gummiboot binary onto your efi system partition

Oh, of course you could also have a quick look whether the patch in question makes sense. You have a much higher chance of understanding it than me :)
Comment by Greg KH (gregkh) - Wednesday, 28 November 2012, 23:31 GMT
Yes, removing that patch from the gnu-efi-libs package fixes gummiboot (I built gummiboot from its git tree, I didn't use the arch package).

So something is wrong with the patch.

Comment by Mika Fischer (mika.fischer) - Thursday, 29 November 2012, 12:41 GMT
Thanks!

This weekend I'll hopefully have some time to try to find out whether reFind also works without this patch. If it does, can it be removed from gnu-efi-libs?
Comment by Tobias Powalowski (tpowa) - Thursday, 29 November 2012, 13:38 GMT
Sure please test and report. I cannot test any UEFI related issue due to old hardware which doesn't support UEFI at all.
Comment by Felipe Contreras (felipec) - Friday, 30 November 2012, 04:50 GMT
So there's problems with the patch, and problems without the patch. I suppose without the patch the assembler stub is not used, so one way to move this forward would be to generate the stuff with the appropriate gcc options, and then slowly compare it with my patch, and find at which point these systems break/work.

Unfortunately I cannot take a look at this until a week or two.
Comment by Keshav Amburay (the.ridikulus.rat) - Friday, 30 November 2012, 05:30 GMT
@felipec: gnu-efi 3.0s upstream release actually uses gcc's ms_abi support. But for some reason it totally screws up any bootloader built against that gnu-efi 3.0s. The https://projects.archlinux.org/svntogit/packages.git/tree/trunk/disable-ms_abi-flag.patch?h=packages/gnu-efi-libs disables ms_abi support, and thus gnu-efi fallback to the assembler stub. Your patch changes the assembler stub which is enabled only if the second is used. So either both patches are required or both are not required.

If you can find out why gcc ms_abi code in gnu-efi 3.0s is failing (and maybe correct that issue), that would be a better solution rather than modifying and using the assembler stub.

The author of the ms_abi code in gnu-efi maintains his own git repo with fedora specific patches at https://github.com/vathpela/gnu-efi/commits/fedora .
Comment by Felipe Contreras (felipec) - Friday, 30 November 2012, 06:13 GMT
It's not just the ms ABI, it's also -maccumulate-outgoing-args.

So basically what we need is to convert back and forth from AMD64 ABI and x64 win ABI, and there are 3 ways of doing it:

1) The original gnu-efi asm stub
2) My modified gnu-efi asm stub
3) Use gcc with ms_abi and -maccumulate-outgoing-args

In all these cases assembler code converts from one ABI to the other. 1) is clearly broken in my machine, and 2) works just fine. I wrote that after reading the AMD64 ABI, x64 win ABI documents, and relevant code, like GRUB, which seems to be doing something similar.

I actually contacted Mathew Garret which forwarded me to Peter Jones to whom I explained the rationale of my patch, and why I think gcc is doing unnecessary stuff, I got one reply, but not any more.

It shouldn't be hard to write a simple test case to exercise this code in the machines affected, but I can't do it at the moment.
Comment by Mika Fischer (mika.fischer) - Friday, 30 November 2012, 07:54 GMT
@felipec: Thanks for chiming in! Could you clarify a few things for me?

As far as I understand it, the three cases you described correspond to the following application of the arch patches in gnu-efi-libs:
1) The original gnu-efi asm stub: disable-ms_abi-flag.patch APPLIED, gnu-efi-libs-x86_64-call-fix.patch NOT APPLIED
2) My modified gnu-efi asm stub: disable-ms_abi-flag.patch APPLIED, gnu-efi-libs-x86_64-call-fix.patch APPLIED
3) Use gcc with ms_abi and -maccumulate-outgoing-args: disable-ms_abi-flag.patch NOT APPLIED, gnu-efi-libs-x86_64-call-fix.patch NOT APPLIED

Am I understanding that correctly?

So my experience with gummiboot is (I'll try the same with reFind soon):
1) works fine
2) works partially but some function calls fail when they shouldn't, rendering it practically unusable
3) crashes immediately

Can you confirm that your experience with gummiboot is different for the three cases?

Oh and could you describe what problems you had that your patch fixed, so I could try to reproduce them here.
Comment by Keshav Amburay (the.ridikulus.rat) - Friday, 30 November 2012, 08:41 GMT
@mika.fischer: Yes, that's how the patches are used in these three cases. Though I do not know what issue @felipec faced exactly and how the call-fix patch fixes it. As he explained before case 2 works in his system while case 1 failed. Case 3 was added only in 3.0s release. Since Fedora's gnu-efi pkg is currently at 3.0q, case 3 is not relevant if you are comparing Arch's pkg with Fedora's pkg.

Case 3 seems to fail for all systems. According to Peter Jones there must be something going wrong in our gcc/binutils or the FLAGS used in our gnu-efi-libs pkg (our gcc's default FLAGS and/or makepkg.conf FLAGS). However the best option would be to use gcc's inbuilt x64 win abi calls support (ms_abi) rather than using the asm stub (i.e. fix case 3 and ditch the asm stub). Atleast thats my opinion.

Arch's refind-efi pkg no longer uses gnu-efi-libs, it instead uses Intel's Tianocore UDK/EDK2 toolkit. So it would be useless to try Arch's pkg. If you want to test rEFInd, you can manually compile the source using "make gnuefi" and try it.
Comment by Mika Fischer (mika.fischer) - Saturday, 01 December 2012, 11:02 GMT
Ok, then I don't see what else I can do here. The current gnu-efi-libs shipped by Arch is broken for me and others. Removing felipec's patch fixes things for me and also for Greg.

Sure, it would be nice to get the ms-abi stuff working, but I'm not in a position to fix that. And until it's fixed, I'd prefer a working version of gnu-efi-libs.

Let me know if I can provide any other info, test things, etc.
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 03 December 2012, 03:37 GMT
Can you post the output of /usr/share/gnu-efi/x86_64/tcc.efi (run in UEFI Shell) from gnu-efi-libs package in all the three cases?
Comment by Mika Fischer (mika.fischer) - Monday, 03 December 2012, 19:18 GMT
In all three cases the output is the same and indicates that everything is working fine:
-----------------------------------------
Hello
Returning Failure works
0 args works just fine here.
1 arg works just fine here.
2 args works just fine here.
3 args works just fine here.
4 args works just fine here.
5 args works just fine here.
6 args works just fine here.
7 args works just fine here.
8 args works just fine here.
9 args works just fine here.
10 args works just fine here.
-----------------------------------------
Comment by Mika Fischer (mika.fischer) - Tuesday, 04 December 2012, 08:54 GMT
I also tried compiling linking and mangling (objdump) gummiboot with the same flags as this tcc binary in case 3, but it still crashes immediately...
Comment by beta990 (beta990) - Tuesday, 08 January 2013, 11:58 GMT
Still not working here: ASUS P8H67-M Pro. Also not working with the latest (unlisted) Arch ISO. Could there not a legacy iso be released for other/ASUS motherboards until the problem is fixed?
Comment by Tobias Powalowski (tpowa) - Wednesday, 23 January 2013, 10:22 GMT
Ok guys, let's try to make this somehow working.
Removing felipes patch seems to fix it for most people.
Felipe are you fine with removing it and you compile it yourself until your issues are fixed?
Comment by Tobias Powalowski (tpowa) - Wednesday, 23 January 2013, 11:53 GMT
I removed the x86_64 patch, please confirm if gummiboot in testing does now work as expected.
Thanks.
Comment by Mika Fischer (mika.fischer) - Wednesday, 23 January 2013, 18:05 GMT
Version 15-2 from testing works fine for me. Thanks!
Comment by David Rheinsberg (dvdhrm) - Wednesday, 13 February 2013, 17:59 GMT
  • Field changed: Percent Complete (100% → 0%)
Broken for me with 17-1 again.
Comment by David Rheinsberg (dvdhrm) - Friday, 15 February 2013, 23:33 GMT
Compiling gummiboot-efi from the official git repository (no using AUR, which is broken) solves all issues for me. I don't know why, but this might be some upstream bug in version 17.
Comment by Tobias Powalowski (tpowa) - Thursday, 21 February 2013, 21:58 GMT
Please try 23.
Comment by Serge Canizares (enluminaire) - Saturday, 23 February 2013, 16:17 GMT
I just sync'd and tried installing gummiboot 23, and am seeing the error message "no entries in \loader\entries\*conf ". After the default timeout, efi switches to grub2, which I have as my second bootloader, per below:

BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0000,0005
Boot0000* Gummiboot HD(1,800,100000,609cdd35-1714-4e73-a31a-e0c9b5d9b2c8)File(\EFI\gummiboot\gummiboot.efi)
Boot0005* Arch Linux (GRUB) HD(1,800,100000,609cdd35-1714-4e73-a31a-e0c9b5d9b2c8)File(\EFI\arch_grub\grubx64.efi)

grub then successfully boots.
I'm using an Asus UX31a notebook -- would be heppy to provide any additional info to help resolve the issue, as I would prefer to use gummiboot over grub.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 23 February 2013, 16:26 GMT
23-1 works fine for me (Tested at work, with an Asus P8H61-M | Firmware: 4602) [archiso]
Comment by Serge Canizares (enluminaire) - Saturday, 23 February 2013, 17:37 GMT
As a bit of additional info, if I copy

/usr/lib/gummiboot/gummibootx64.efi

into

/boot/efi/EFI/boot/bootx64.efi

then at reboot time gummiboot will launch with the only menu option as (I think) "Default EFI bootloader", which when selected in turn launches gummiboot with the default boot option set in loader.conf (and again no other menu options). That in turn will finally boot the pc.

Althernatively, if at boot time I hit escape, I am able to select Gummiboot as my boot option, and gummiboot will succesfully launch with only the default option selectable. Again, I can successfully boot the pc from there.

However, simply allowing the efi boot order set in efibootmgr to choose gummiboot after power on always end with gummiboot failing with the "no entries in \loader\entries\*.conf" error, and then failing over to grub.
Comment by Tobias Powalowski (tpowa) - Saturday, 23 February 2013, 17:53 GMT
Does it also work with gummiboot 23-2 from testing?
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 23 February 2013, 18:10 GMT
I will test next week, when I have access to such machine again.
Comment by Serge Canizares (enluminaire) - Saturday, 23 February 2013, 18:20 GMT
@Tobias -- ok, when I install 23-2 from testing, at boot time, if I allow the bootloader order set by efibootmgr to default to gummiboot, it simply freezes up with a blank screen; no failover to grub either. The same thing occurs when I hit Esc key at boot and manually choose the Gummiboot option.
Comment by Tobias Powalowski (tpowa) - Tuesday, 26 February 2013, 17:09 GMT
Now 23-3 in testing.
Comment by Tom Gundersen (tomegun) - Friday, 01 March 2013, 20:02 GMT
Could people still experiencing problems try with gummiboot-24 from [testing]?
Comment by Serge Canizares (enluminaire) - Saturday, 02 March 2013, 00:09 GMT
@Tom, I just tried upgrading to gummiboot-24 from testing, but the install fails with this

(1/1) installing gummiboot [##############################] 100%
File system /boot is not a FAT EFI System Partition (ESP) file system.
error: command failed to execute correctly

I use /boot/efi as my ESP, and that is fat32, but indeed /boot is ext4.

/dev/sda2 on /boot type ext4
/dev/sda1 on /boot/efi type vfat

Does v24 require /boot as the ESP?
Comment by Serge Canizares (enluminaire) - Saturday, 02 March 2013, 00:41 GMT
@Tobias, I missed your comment on 23-3 in testing. I just installed that. Gummiboot will successfully launch the default boot option specified in loader.conf; however, pressing and key at the gummiboot menu fails to bring up the list of entries I have in /boot/efi/loader/entries. Only the default appears.
Comment by Tom Gundersen (tomegun) - Saturday, 02 March 2013, 09:57 GMT
Serge: yes, that's the only supported setup. However, it is only required for the instal/upgrade to work, so you could just ignore the warning and copy it manually as before.

Could you post one of your entries that does not work, together with the one that does?

To avoid any configuration errors, you could remount your efi partition as /boot and run 'gummiboot remove'followed by 'gummiboot install'.
Comment by Keshav Amburay (the.ridikulus.rat) - Saturday, 02 March 2013, 13:53 GMT
@tomegun: No where gummiboot mandates ESP to be mounted at /boot. There is a --path option in /usr/bin/gummiboot that can be used to specify the mountpoint of ESP. The pkg should not assume that ESP is mounted at /boot. /boot/efi has been used as mountpoint for ESP since Intel Itanium days and now used as default ESP mountpoint by many distros. Not that /boot as ESP is wrong, but it should not be considered default.

Also why are the diff arch gummiboot *.efi files in the respective linux specific arch pkgs, instead of 'any' arch? Gummiboot is a boot manager and is independent of the host OS. Technically it should be 'any' pkg like other UEFI bootloaders.

EDIT: Slightly offtopic, but since UEFI is becoming more common, and gummiboot is being used by many people and also by archiso, i suggest moving the pkg to [core] so that the devs can signoff pkg updates.
Comment by Tom Gundersen (tomegun) - Sunday, 03 March 2013, 02:27 GMT
Keshav:

The gumiboot installation tool defaults to ESP being /boot, so we won't work around that in the package. People can still use the tool with the option you mention manually in case they want that. We will likely soon try to standardise on ESP being /boot, but more on that later.

If the use case of differing architectures between EFI and host is a common one, then support for that should be added upstream. Due to the installation tool, we can't have arch = any. However if upstream adds support for building both efi images on both architectures and the installation tool learns to deal with that, this won't be a problem.

Once things have stabilised a bit I will purpose moving this to core. We might want to rethink how we instal kernels in general. It should all be clearer in a few weeks.
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 06 March 2013, 15:34 GMT
@Tom: Can you remove this automatic installation or make it conditionally (similar to what happens with syslinux)? I guess this a a bad idea if you are installing in a chroot enviroment, (ie. preparing an image for archiso) on EFI systems, and also make that install process shows an error on non-EFI systems.
Comment by Tom Gundersen (tomegun) - Thursday, 07 March 2013, 00:15 GMT
@djgera: please open new bug or write to the ML (short answer: i don't think that is necessary, but let's discuss it).
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 March 2013, 02:01 GMT
Yes, better. Done at  FS#34191 
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 08 March 2013, 19:26 GMT
Finally I got access to EFI machine on my work, sorry for the delay. 24-1 works fine here (Asus P8H61-M | Firmware: 4602) [archiso].
Comment by Keshav Amburay (the.ridikulus.rat) - Saturday, 09 March 2013, 03:47 GMT
Does gummiboot 24-1 pkg fix this for all other users?

Loading...