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
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
|
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.
Saturday, 09 March 2013, 08:00 GMT
Reason for closing: Works for me
Additional comments about closing: Please reopen if anyone can still reproduce.
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
http://pkgs.fedoraproject.org/cgit/gnu-efi.git/tree/?h=f18&id=76e9368fa88a36c52d37a197bef693850895f53f
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.
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.
Anything I can to to test or debug to help out here?
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 :)
So something is wrong with the patch.
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?
Unfortunately I cannot take a look at this until a week or two.
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 .
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.
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.
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.
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.
-----------------------------------------
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.
-----------------------------------------
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?
Thanks.
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.
/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.
(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?
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'.
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.
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.
FS#34191