ASUS Q500A laptop with Aptio firmware/UEFI version 208 (GOP 3.0.14.1015). Aptio is made by American Megatrends Inc. The Fedora 19 Live CD and Fedora 20 Live CD are only bootable when operating in CSM mode (legacy mode). The Fedora Live CD's tested were Fedora-Live-Desktop-x86_64-19-1.iso and the Fedora-20-Beta-x86_64-DVD.iso. On the same machine, I can boot Windows 8 in UEFI (Secure Boot ON, CSM mode OFF), Gparted 0.17.0-1 (Secure Boot OFF, CSM mode OFF), and Ubuntu 12 and 13 (Secure Boot OFF, CSM mode OFF). I examined the filesystem of Windows 8, Gparted, Fedora and Ubuntu. The on-disc file systems look exactly the same sans capitalization. That is, Windows 8 uses efi/boot/bootx64.efi; Fedora uses EFI/BOOT/BOOTX64.efi; Gparted uses EFI/boot/bootx64.efi; and Ubuntu uses EFI/BOOT/BOOTx64.efi. I don't know how to check signatures on the components, however. As Fedora 20 will be out soon, I am happy to provide feedback and help test fixes. Its very frustrating to be unable to install or use Fedora.
This is completely unrelated component
> On the same machine, I can boot Windows 8 in UEFI > (Secure Boot ON, CSM mode OFF), Gparted 0.17.0-1 > (Secure Boot OFF, CSM mode OFF), and Ubuntu 12 and > 13 (Secure Boot OFF, CSM mode OFF). I was wrong here.... I *cannot* boot Ubuntu 12 or 13 in UEFI. The difference between Windows/Gparted (successful UEFI boot) and Fedora/Ubuntu (fails to UEFI boot) is the case of the filename "bootx64.efi". I would *love* to get my hands on a Fedora 19 or 20 ISO where the filename is all lowercase.
Moving to 'shim' - it may not be the exact component, but it should involve the proper people.
I was able to correct the problem, but I'm not sure what the problem was. There were two potential problems. First, the case sensitivity of EFI/BOOT/bootx64.efi. Second, the bootable UEFI DVD may have been built incorrectly. I'm fairly certain it was the first issue since I used Fedora's notes to build the bootable UEFI DVD (http://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI). The attached script changes the case of bootx64.efi and then rebuilds the bootable UEFI DVD according to the Fedora wiki page. The changes tested positive on Fedora 19, Ubuntu 12 and Ubuntu 13 (previously, none would boot in UEFI mode). This fix likely has limited scope since I did not come across others reporting a "no UEFI boot" issue. Its likely limited to ASUS laptops, Aptio UEFI around version 205, etc.
Created attachment 837355 [details] Script to rebuild Desktop ISO with lowercase bootx64.efi filename for ASUS laptops running Aptio UEFI
Created attachment 837454 [details] 837355: Script to rebuild Desktop ISO with lowercase bootx64.efi filename for ASUS laptops running Aptio UEFI
(In reply to Bill Nottingham from comment #3) > Moving to 'shim' - it may not be the exact component, but it should involve > the proper people. Unfortunately, I don't really know enough to help out with the component decision. I noticed Ubuntu's bug tracker wanted Live CD and other boot problems filed against the kernel. https://wiki.ubuntu.com/Bugs/FindRightPackage#Kernel.
I will bet anything you like that we only call it BOOTx64.efi because we found some *other* hardware won't recognize it if it's called bootx64.efi . You mark my words...
A suggestion to test: Could building the filesystem mounted as type "msdos" rather than "vfat" help? I'm skeptical that this would fix the problem, since it would likely just make it all look to be a single case to the EFI, but it's worth trying....
(In reply to Adam Williamson from comment #8) > I will bet anything you like that we only call it BOOTx64.efi because we > found some *other* hardware won't recognize it if it's called bootx64.efi . > You mark my words... Well, if we're careful, we should be able to make it exist in FAT rather than VFAT space, in which case there's no difference. I thought I'd made sure of this in the past, but apparently not.
I think #c10 is actually the case in F21 - can somebody try this on affected hardware to be sure?
(In reply to Peter Jones from comment #11) > I think #c10 is actually the case in F21 - can somebody try this on affected > hardware to be sure? Peter - how can I test C10? What, exactly, do you want done? Do you want me to download and test something already built? Or do you want me to modify something? When I remaster the ISO provided by Fedora, here's what I use when rebuilding the image (from the script offered in C6): mkisofs -U -A "$VOLUME_NAME" -V "$VOLUME_NAME" -volset "$VOLUME_NAME" \ -input-charset utf-8 -J -joliet-long -r -v -T -x ./lost+found \ -o "$DESTINATION_ISO" -b "$BIN_NAME" -c "$CAT_NAME" -no-emul-boot \ -boot-load-size 4 -boot-info-table -eltorito-alt-boot \ -e "$IMG_NAME" -no-emul-boot . Where does FAT/VFAT come into play in the above command? What should I change to what?
Empty comment added because I forgot to check the "additional info" for C12 in response to Peter's C11 feedback. Sorry about that.
I don't mean to sound rude, but please stop pinging me for information. I'm also stalled waiting for information.
The 'your requests' (or whatever) mails are auto-generated for any bug which is in a 'needinfo' state for you. I think the question pjones wants answered is simply, is this still a problem with a Fedora 21 image? Your initial report is for 19/20, and he thinks he fixed it between 20 and 21.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.