FS#31894 - [gummiboot-efi] CD does not boot in UEFI mode.

Attached to Project: Arch Linux
Opened by thorazine74 (thorazine74) - Thursday, 11 October 2012, 08:03 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 28 January 2013, 08:24 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Medium
Priority Normal
Reported Version 2012.10.06
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

I tried to boot ISO 2012.10.06 from CD using UEFI and it didnt launch the kernel. It just loads an UEFI shell, trying to start startup.nsh and then nothing else.
Trying to launch one of the bootx64.efi from this shell results in a cursor at the top shelf and no CD reading at all.

Machine specs:
Mobo is Asus P8Z77V-LE with UEFI BIOS version 0806.
CPU/iGPU: Core i5 3570K/Intel HD 4500
Storage: SATA6G 3TB HD & SATA3G DVD-Drive.
DVD booting in UEFI mode.

HD is already partitioned with GPT using gdisk from Parted Magic Live CD.
I already have a EFI System Partition in the HD, with REFIND Boot Manager installed in fs0:\EFI\refind\refind_x64.efi.
I also have EFI Shell 2.0 installed in fs0:\Shellx64.efi

Adding the efi loader from the ISO to the NVRAM using
bcfg boot add 3 fs1:\EFI\bootx64.efi "ArchIso (Gummiboot)"
results in a valid BIOS boot entry that successfully launches Gummiboot and this in turn launches the kernel.
However I'm not sure if this is launched in fact in UEFI mode because after logging it and modprobing efivars I do not see any /sys/firmware/efi.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 28 January 2013, 08:24 GMT
Reason for closing:  Fixed
Additional comments about closing:  15-2
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 13 October 2012, 18:31 GMT
If you disable your HDD thats has a valid EFI boot partition with some executables, DVD boots fine?
Comment by thorazine74 (thorazine74) - Sunday, 14 October 2012, 22:53 GMT
With HDD disabled I get the same result.
I looked at the files in the CD's EFI, and it looks like there its 2 EFI shells aside from the main Arch entry, somehow v2 shell from the CD is being launched instead of the main entry that launches the kernel.
Also it looks like Gummiboot on the CD has some kind of menu, with 2 EFI shells and the default Arch Linux entry, I dont get see any menu when booting, how come the EFI Shell v2 entry from that menu end up launched? Some kind of fail safe option?
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 14 October 2012, 23:06 GMT
Odd, so your EFI firmware automatically launches shellx64_vX.efi instead of boot/bootx64.efi this is a bit crazy. When you are in the efi-shell, can you execute boot/bootx64.efi ? This should launch gummiboot...

Side note: When you look at CD-ISO for /EFI directory is probably that your EFI firmware does not understand ISO-9660 (the filesystem that your are looking), instead uses "El Torito" image (efiboot.img) that contains the same EFI executables (gummiboot and shells).
Comment by thorazine74 (thorazine74) - Sunday, 14 October 2012, 23:21 GMT
Launching boot/bootx64.efi from inside the EFI shell, results in a white square cursor at the top left of the EFI shell window and nothing else; no CD reading activity.
However launching this same file from an entry added to the firmware boot manager successfully launches gummiboot which in turn launches the kernel.

BTW, I was looking at EFI files in the CD using the EFI Shell, not a live system. So if my firmware doesnt understand iso-9660 I should only see the /EFI/* files, and nothing else? Thats the case indeed.
Comment by thorazine74 (thorazine74) - Sunday, 14 October 2012, 23:26 GMT
Just a guess, considering that the shell being launched is actually v2, and it looks like this file is the first in order in \EFI\ directory, could it be that my firmware is automatically launching the first .efi file found there instead of \EFI\boot\bootx64.efi?
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 15 October 2012, 00:45 GMT
Odd, the thing here is that we can do nothing, looks like something broken with EFI firmware,

(1) About FS: Exactly, if you do not see other directory than \EFI and \loader, yes you are on efiboot.img (fat16), if you see \arch, yes your are on iso9660
(2) who knows, maybe, can be interesting what happens if these shells instead appears directly on EFI\, reside on other directory like \EFI\shells. hehe

PS: If you have time, I can show step by step, how to re-mastering the ISO in few steps to modify the image efiboot.img in our way.
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 15 October 2012, 01:07 GMT
mkdir /tmp/new_img
mkdir /tmp/new_iso
cd /tmp/new_iso
bsdtar -x -f ~/archlinux-2012.10.06-dual.iso
mount EFI/archiso/efiboot.img /tmp/new_img
mkdir /tmp/new_img/EFI/shell
mv /tmp/new_img/EFI/shell*.efi /tmp/new_img/EFI/shell
sed 's@/EFI@/EFI/shell@' -i /tmp/new_img/loader/entries/uefi-shell*
umount /tmp/new_img
xorriso -as mkisofs \
-iso-level 3 \
-full-iso9660-filenames \
-volid "ARCH_201210" \
-appid "Arch Linux Live/Rescue CD" \
-publisher "Arch Linux <http://www.archlinux.org>" \
-preparer "prepared by mkarchiso" \
-eltorito-boot isolinux/isolinux.bin \
-eltorito-catalog isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
--efi-boot EFI/archiso/efiboot.img \
-isohybrid-mbr /tmp/new_iso/isolinux/isohdpfx.bin \
-output "/tmp/archlinux-2012.10.06-dual-remastered.iso" \
/tmp/new_iso
Comment by thorazine74 (thorazine74) - Monday, 15 October 2012, 13:59 GMT
I'll follow those steps and see what happens.

Comment by thorazine74 (thorazine74) - Monday, 15 October 2012, 22:11 GMT
I rebuilt the iso with the above steps and surprisingly the CD still boots to an EFI Shell!
I didnt check with the HDD disconnected but I'm pretty sure its the EFI Shell from the CD and not the one in my HDD's ESP.
Following the same steps I did a second remastered ISO, but this time instead of just moving the shell*.efi executables to a subdirectory, I renamed them to something like toolv1.efi & toolv2.efi. And I also removed the loader entries pertaining to them, leaving just the default arch conf file in the /loader/entries/
And this time I managed to sucessfully boot to Arch CD!
So I think we can conclude that either:
- This EFI BIOS is so plain buggy that launches whatever EFI Shell executable it finds anywhere on the media instead of the /EFI/boot/bootx64.efi that I think its mandated by the specs.
- Something is wrong with the gummiboot multiple entries configuration that result in one of the non-default entries being launched (I still dont get any gummiboot menu at all, shouldnt I get one? Even with just one menu config?)
I dont have time to do any more tests at the moment but I think it would be sane to assume that:
- If I leave the shellx64*.efi files in the original location but I remove their entries from gummiboot config and the EFI shell doesnt launch, the problem would be gummiboot.
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 15 October 2012, 22:34 GMT
Many thanks for doing some testing cases.

When you say, that CD boots, what do you see? CD boots in BIOS-legacy? (syslinux menu appears).
Yes gummiboot menu is visible with a timeout of 3 seconds[#1], then linux.efi is launched.

Comment by thorazine74 (thorazine74) - Tuesday, 16 October 2012, 06:58 GMT
Just after booting I see a white cursor at the top left of the screen, the CD is reading, and after a few seconds the video mode changes and the kernel starts booting.
I'm pretty sure the CD is booting in EFI-mode, this mobo's firmware (when CSM options are enabled) puts 2 differente entries in the boot menu for USB and DVD drives, the normal one, "P3: ATAPI...", and the UEFI one "UEFI: P3 ATAPI....". I did all the tests using the UEFI boot entry.
So I dont see any gummiboot menu (neither syslinux) at all.
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 16 October 2012, 07:54 GMT
Then I guess, for some reason gummiboot is not visible, maybe something broken with initial video in EFI... I think if you touch some key to cancel timeout of gummi boot (like cursors), there is no boot at all.
And if you blindly touch "enter" on any of three menu entries, respective EFI app will be launched (linux / shell v1 / shell v2).

If this is the case, maybe you can try to contact gummiboot authors ;)

Comment by thorazine74 (thorazine74) - Wednesday, 17 October 2012, 10:47 GMT
I doubt the EFI video is broken, if that were the case, the default gummiboot entry, which is Arch I think, should boot automatically after the timeout if I didnt touch any key, but I dont touch any key and the EFI Shell boots instead.

Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 18 October 2012, 01:07 GMT
oh then I understand bad ("And this time I managed to sucessfully boot to Arch CD!"), so linux.efi is not launched in any way?
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 26 October 2012, 20:00 GMT
Today I have the opportunity to test, for the first time, a real UEFI hardware (Asus P8H61-M | Firmware: 4602), but without success.
Boot in UEFI mode was not possible in both CD-ROM and USB-FLASH modes. The gummiboot-7-1 starts but fails to find configuration files:

"No loader found. Configuration files in \loader\entries\*.conf are needed." [#1]

I tried to rename files using short names but no sucess. (like arch64.conf, ...)

[#1] http://cgit.freedesktop.org/gummiboot/tree/gummiboot.c#n1594
Comment by Keshav Amburay (the.ridikulus.rat) - Tuesday, 30 October 2012, 06:07 GMT
To me this looks like either a problem with Asus firmwares and/or gummiboot multiple entries config problem. There is another report at https://bugs.archlinux.org/task/32271, might be same issue. Many other users (mostly Lenovo) have confirmed gummiboot-efi-7 working in their systems.

Gummiboot by default does not any menu and silently boots into default entry, unless the user presses "space bar" before timeout ( http://freedesktop.org/wiki/Software/gummiboot ). So no menu is not a problem.

Can someone try

[quote]
If I leave the shellx64*.efi files in the original location but I remove their entries from gummiboot config and the EFI shell doesnt launch, the problem would be gummiboot
[/quote]

and verify this? If so report this issue to the upstream author Kay Sievers at kay@vrfy.org . I have only tested in QEMU and it works.

EDIT: Also try booting unmodified iso, but without any shell*.efi files anywhere in the HDD, to verify whether it is the CD's shell*.efi that is being launched. The firmware most likely will not simply try any shell*.efi file, only /shellx64.efi (and that is not the filename for both shell files in the CD). If that is the case then somehow gummiboot is ignoring /loader/loader.conf's default entry option.
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 30 October 2012, 09:38 GMT
ISO as-is boot fine in qemu+ovmf, this is why I accepted your patches. I guess something is broken in the API from Asus firmware.

I have only access to this EFI machine each friday, so I can test any experiment.
Comment by Keshav Amburay (the.ridikulus.rat) - Tuesday, 30 October 2012, 16:30 GMT
Can anyone try creating the CD/USB with gummiboot-efi-7 ? Just replace older [USB]/EFI/boot/bootx64.efi with /usr/lib/gummiboot/gummibootx64.efi of gummiboot-efi-7 pkg.

The 2012.10.06 iso uses gummiboot-efi-6 . v7 was packaged on 12-OCT-2012, and according to git commit log fixes some issues. See https://bbs.archlinux.org/viewtopic.php?pid=1174679 for more info.

https://bugs.archlinux.org/task/32271 is a different issue with gummiboot-efi-7 that occurs only in installed Arch system, not with ISO CD/USB booting, so its unrelated to this issue.
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 30 October 2012, 18:33 GMT
as I said before my test is based on gummiboot-7
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 31 October 2012, 20:15 GMT
refind-0.4.6-1 boots fine and launches Linux without any issues on the same machine where gummiboot-7-1 fails to boot with msg about *.conf, for ussing refind with archiso I made a simple config.

I made other experiments with gummiboot without success, for example, having only one file in \loader\entries\ named archx64.conf, removed shell*.conf or trying to launch gummiboot from shell -> freeze machine, without errors messages.

-- EFI/boot/refind.conf --
textonly
scanfor manual

menuentry Linux {
loader \arch\boot\x86_64\vmlinuz
initrd \arch\boot\x86_64\archiso.img
options "archisolabel=ARCH_201210"
}
----

(As exception I have access to this machine today)
Comment by Heema (Heema) - Wednesday, 31 October 2012, 20:49 GMT
Thanks, that worked for me too

i have a SSD formatted with GPT and a UEFI motherboard (gigabyte GA-Z77X-UD5H-WB Latest BIOS version)
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 31 October 2012, 21:57 GMT
gummiboot also fails on your Gigabyte?
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 31 October 2012, 22:05 GMT
  • Field changed: Summary ([gummiboot] CD does not boot in UEFI mode. → [gummiboot-efi] CD does not boot in UEFI mode.)
gummiboot-8 is out
Comment by Heema (Heema) - Wednesday, 31 October 2012, 22:10 GMT
yeah it gave me the same error "No loader found. Configuration files in \loader\entries\*.conf are needed."

i could try gummiboot-8 to see if its fixed or not
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 31 October 2012, 22:18 GMT
Oh, yes please :) I do not have access to such machine until friday, to test again.
Comment by Heema (Heema) - Wednesday, 31 October 2012, 22:34 GMT
where can i download gummiboot-8 as there main site doesnt open for me

and its not in arch repo [extra] yet
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 01 November 2012, 20:58 GMT
oops sorry, still not released, only git commit preparing for version 8. You can build from git using AUR PKGBUILD [#1]

[#1] https://aur.archlinux.org/packages.php?ID=63529
Comment by Heema (Heema) - Saturday, 03 November 2012, 03:39 GMT
Sorry but ther main website is always down for me and there git
http://freedesktop.org/wiki/Software/gummiboot

is there a compiled version that i can try ?
Comment by Tobias Powalowski (tpowa) - Monday, 05 November 2012, 14:48 GMT
Status on v8?
Comment by Heema (Heema) - Monday, 05 November 2012, 17:06 GMT
tried v8 but it still gives the same error for me
Comment by beta990 (beta990) - Wednesday, 07 November 2012, 12:13 GMT
Still not fixed, have the same error on my ASUS P8H67-M Pro (b3) with latest BIOS. (See second comment below)
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2012, 13:21 GMT
Well feel free to donate me the hardware.
Comment by beta990 (beta990) - Wednesday, 07 November 2012, 14:06 GMT
I'm sorry for my reaction, but it would be nice if there was something of a beta test (yes even for a boot-iso), before releasing a new iso that doesn't work on (most) ASUS UEFI-boards.
The previous versions worked fine and I know that the Arch philosophy is using the latest (and the greatest), but at the moment their are so many changes to the base (rEFInd > Gummiboot), I don't know if it always that good.

Sorry again for my reaction.
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2012, 14:11 GMT
Well, we will find a fix and as far as I can say the archboot and archiso both provided kind of beta files and noone raised the voice.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 09 November 2012, 21:20 GMT
Yup, gummiboot-8-1 does not work (Asus P8H61-M | Firmware: 4602). I will, try to contact to author, if he can give some tips to debug the problem.
Comment by Maxime Gauduin (Alucryd) - Friday, 09 November 2012, 22:07 GMT
Same here with an ASUS Maximus V Gene, bios 1309 (latest).
Comment by Keshav Amburay (the.ridikulus.rat) - Saturday, 10 November 2012, 08:52 GMT
gummiboot 8 compiled against gnu-efi 3.0s fails in my QEMU (OVMF). The upstream author uses a fedora patched gnu-efi 3.0q ( http://pkgs.fedoraproject.org/cgit/gnu-efi.git/tree/ ) and his binary worked in my qemu. So I think something is wrong in our gnu-efi package due to which all uefi bootloaders built against it fail.

gummiboot 8 built against Arch's gnu-efi 3.0q boots in qemu. I don't know whether it is due to gnu-efi 3.0s source itself or due to our gcc/binutils or the CFLAGS/LDFLAGS passed by makepkg while building. Strangely the changes between upstream (sourceforge) gnu-efi 3.0q and 3.0s were all submitted by the fedora gnu-efi package maintainer (although fedora's package itself has not been updated to 3.0s). The fedora maintainer maintains a fork at https://github.com/vathpela/gnu-efi/commits/fedora . If possible please try both Arch's gnu-efi and the github (fedora) one and compare gummiboot compiled in both, in your system.

rEFInd compiled against gnu-efi 3.0s also fails, but since rEFInd supports building against Tianocore UDK2010 libs ( http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome ) (and is recommended by rEFInd author over gnu-efi-libs), the rEFInd package has been modified to compile using Tianocore UDK libs. So rEFInd 0.4.7-2 should work fine in most of the UEFI systems (including the Asus ones).

gummiboot, efilinux and other uefi bootloaders (elilo etc. in AUR) do not support Tianocore, so they are dependent on gnu-efi-libs. Grub2 does not use either gnu-efi or Tianocore and so is unaffected by these issues. For normal system (HDD/SSD) UEFI booting please use rEFInd or grub2. For Archiso, create a UEFI USB and replace existing (USB)/EFI/boot/bootx64.efi with /usr/lib/refind/refindx64.efi and then create (USB)/EFI/boot/refind.conf as described below. For Archboot see https://bbs.archlinux.org/viewtopic.php?pid=1190788#p1190788 .

If gummiboot still fails, I will send a patch for Archiso to use rEFInd.

EDIT: The menu text in refind-efi 0.4.7-2 will be right aligned. That is due to a minor string formatting issue in rEFInd source which has been fixed in upstream git repo. Anyway this does not affect the working of refindx64.efi .

-- (USB)/EFI/boot/refind.conf --
timeout 5
textonly

showtools about,reboot,shutdown,exit
# scan_driver_dirs EFI/tools/drivers_x64
scanfor manual,internal,external,optical

scan_delay 1
dont_scan_dirs EFI/boot

max_tags 0
default_selection "Arch Linux Archiso x86_64 UEFI USB"

menuentry "Arch Linux Archiso x86_64 UEFI USB" {
loader /arch/boot/x86_64/vmlinuz
initrd /arch/boot/x86_64/archiso.img
ostype Linux
graphics off
options "pci=nocrs add_efi_memmap archisobasedir=arch archisolabel=ARCH_201210"
}

menuentry "UEFI x86_64 Shell v2" {
loader /EFI/shellx64_v2.efi
graphics off
}

menuentry "UEFI x86_64 Shell v1" {
loader /EFI/shellx64_v1.efi
graphics off
}
----------
Comment by Maxime Gauduin (Alucryd) - Saturday, 10 November 2012, 10:06 GMT
I tried gummiboot 6, 7 and 8 compiled against gnu-efi q, r and s and all of them asked for conf files on my motherboard. Using refind and your conf file works like a charm.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 10 November 2012, 15:29 GMT
@Keshav: gummiboot-8-1 [was compiled against gnu-efi-libs-3.0r] (Arch Linux package) works for me on qemu.
When you say it fails: what do you mean exactly? (msg about *.conf, hang?, reboot?)
Note that if you are going to patch archiso with refind, please keep it minimal (no scanfor, no extra command line options, no timeout...) like my previous example of refind.conf.
PS: I see that new refind-efi packages includes iso9660 driver, so this can be used to keep efiboot.img minimal with only refind+conf+driver. syslinux-6.00 is comming with EFI support...
Comment by Keshav Amburay (the.ridikulus.rat) - Sunday, 11 November 2012, 17:08 GMT
@djgera: In case of gummiboot 8-1 pkg, I meant msg about *.conf in many users' systems. In qemu it works. But gummiboot v8 built against gnu-efi 3.0s fails. Even rEFInd 0.4.7 compiled against gnu-efi 3.0s (Arch pkg uses Tianocore UDK libs) fails.

Reg refind.conf I added those options with am aim of using rEFInd as a rescue boot manager. Since rEFInd does a good job of detecting other bootloaders. So I prefer having showtools, scanfor options. No need for timeout, scan_delay, max_tags. "graphics off" and "ostype Linux" may be required in some systems. add_efi_memmap is required in many uefi systems to get proper memmap in the kernel. pci=nocrs is required to get efifb working properly in Tianocore based UEFI firmwares (which includes almost all the firmwares out in the wild).

refind-efi 0.4.7-2 includes UEFI FS drivers which was possible due to using Tianocore UDK libs now. But iso9660 driver may not work as you expect it to. I have tested it and it does not work insude efiboot.ing

[quote: http://www.rodsbooks.com/refind/drivers.html ]
As a side note, using an ISO-9660 driver can theoretically help you keep the size of a custom Linux boot CD/DVD down to a reasonable value. This is because EFI systems normally boot from optical discs by reading a FAT image file in El Torito format and treating that file as an ESP. If you need to store the kernel both in that file and directly in the ISO-9660 filesystem (to maintain bootability on BIOS systems), that can represent an unwanted extra space requirement. Placing rEFInd and an ISO-9660 driver in the FAT image file should enable you to store the kernel on the disc only once. Unfortunately, this doesn't work in practice. When the ISO-9660 driver is loaded from the El Torito image, the driver discovers that the optical disc is in use and refuses to access it. It's possible to use EFI shell commands to give the ISO-9660 driver access to the shell device, but this causes the El Torito access to go away, which means that anything loaded from the El Torito image (such as rEFInd) is likely to malfunction. Also, some EFI implementations include ISO-9660 drivers, so you might not need a separate ISO-9660 driver if you're building a disc for a particular computer.
[/quote]

Syslinux efi test pkg : https://aur.archlinux.org/packages/syslinux-efi-git/
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 11 November 2012, 18:26 GMT
OK.

Offtopic: if pci=nocrs is needed, should report a bug to upstream as documentation says (kernel-parameters.txt). If add_efi_memmap is required, and is not enabled by default when boot via efistub, I think is optional. We should avoid workarounds.
Comment by Keshav Amburay (the.ridikulus.rat) - Friday, 30 November 2012, 05:40 GMT
This bug depends on https://bugs.archlinux.org/task/32647 . In fact right now both are discussing the same issue.
Comment by Lukas B (teateawhy) - Saturday, 01 December 2012, 11:26 GMT
The fix using rEFInd suggested by Keshav P R (the.ridikulus.rat) does not work on my asus mainboard, rEFInd hangs forever. You can read the full description here:
https://bbs.archlinux.org/viewtopic.php?id=153941
Comment by Louis Chan (louis058) - Monday, 03 December 2012, 17:52 GMT
The fix using rEFInd doesn't work on my Asrock H61M/U3S3 motherboard.
The menu for rEFInd pops up correctly, but upon trying to load archiso, it says that it cannot find vmlinuz (vmlinuz is definitely on the correct path)
Comment by Malstrond (Malstrond) - Thursday, 20 December 2012, 01:26 GMT
I can confirm the same thing happening on a Clevo W110ER Laptop with UEFI/BIOS version 1.02.09. So it's not just Asus boards.
Comment by Peter Cook (LawlFish) - Thursday, 20 December 2012, 23:14 GMT
This bug is also affecting my Lenovo 2012 ThinkCentre. If anyone would like me to provide more info for troubleshooting purposes I am more than happy to.
Comment by Matthew Iversen (Ivoz) - Tuesday, 22 January 2013, 05:53 GMT
I have a samsung series 5 laptop, with which gummiboot also fails to work on.

Replacing with rEFInd, with the config from https://bugs.archlinux.org/task/31894#comment102233 enabled me to use ArchISO to boot up.

The error I had with gummiboot was "No loader found. Configuration files in /loader/entries/*.conf are needed.” even though I am quite sure those files exist, and USB was labelled correctly.
Comment by Tobias Powalowski (tpowa) - Wednesday, 23 January 2013, 11:54 GMT
Does gummiboot in testing now work for this case?
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 24 January 2013, 18:31 GMT
15-2 finally works on ASUS EFI (Asus P8H61-M | Firmware: 4602) :) Tested both (El Torito CD and USB)

EDIT: 15-2

Loading...