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
Opened by thorazine74 (thorazine74) - Thursday, 11 October 2012, 08:03 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 28 January 2013, 08:24 GMT
|
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
Monday, 28 January 2013, 08:24 GMT
Reason for closing: Fixed
Additional comments about closing: 15-2
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?
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).
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.
(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.
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
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.
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.
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.
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 ;)
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
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.
I have only access to this EFI machine each friday, so I can test any experiment.
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.
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)
i have a SSD formatted with GPT and a UEFI motherboard (gigabyte GA-Z77X-UD5H-WB Latest BIOS version)
i could try gummiboot-8 to see if its fixed or not
and its not in arch repo [extra] yet
[#1] https://aur.archlinux.org/packages.php?ID=63529
http://freedesktop.org/wiki/Software/gummiboot
is there a compiled version that i can try ?
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.
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
}
----------
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...
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/
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.
https://bbs.archlinux.org/viewtopic.php?id=153941
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)
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.
EDIT: 15-2