Description of problem: Cannot install Fedora 17-x86_64 on Asus ux31e ultrabook Version-Release number of selected component (if applicable): Fedora17 live media How reproducible: Always Steps to Reproduce: 1. Download F17 live media or DVD or netinst iso file 2. Use liveUSB Creator to write iso image to USB stick 3. Boot Asus from USB stick Actual results: Grub loads then when it trys to boot into the OS I get "Error 15: file not found" from the boot loader. or it will attempt to boot then give this message and freeze: "Trying to allocate 1135 pages for VMLINUZ Got pages at 0x2c9c000 [Linux-EFI, setup=0x102a. size=0x46e190] [Initrd, addr=0x7e3c5000, size=0x1735d60]" Then it hangs... Expected results: F17 starts. Additional info: I have tried using 'dd' as well as many of the other suggestions out their for booting with UEFI Best regards, Jon
I forgot to mention that I also tried #livecd-iso-to-disk --format --efi Fedora-17-x86_64-DVD.iso /dev/sdb with the same results. Cheers, Jon
If you remove 'quiet' and 'rhgb' from the kernel cmdline do you get anymore output after the address output? If not then this is either a grub or kernel bug related you your hardware.
I am having the exact same problem. I built an F17 x86-64 Live USB installation using a PC that was already running F17 and the livecd-creator utility. The LiveUSB works fine on the PC it was built upon. That PC is a non-UEFI system. Then I tried carrying the working Live USB over to a bare metal x86-64 system that has a UEFI-BIOS. On that system, all USB devices are UEFI devices, there is no non-UEFI option for USB devices. When starting the system off of the Live USB, the system fails to boot. The Grub menu appears, and offers the standard two boot options. Upon choosing either one, Grub issues "Error 15: File Not Found." Unlike the previous poster, there are no other errors displayed. This is very clearly a bootloader problem with UEFI device recognition. The kernel command line is never executed. To answer your question: Removing 'quiet' and 'rhgb' has no effect, because the kernel command line is never executed because the requisite file is not found. I'm not sure which file is being referred to by Grub Error 15. If someone could help to clarify that, it would help in fixing the problem. Thanks.
FYI the "bare metal" x86-64 box that fails to boot the working Live USB is an Asus M5A97 LE R2.0, which has an Award UEFI bios and an AMD 970 / SB950 chipset.
OK, after doing a little digging, I've determined that this bug is actually comprised of a number of bugs. The original poster only got far enough to see the first one. FIRST: The LiveUSB that's created by the liveusb-creator utility doesn't create the grub configuration files accurately for booting using UEFI. The paths that are created in the configuration file aren't even accurate paths on the USB drive. In specific, the following file contains garbage: # cat LIVE/EFI/BOOT/BOOTX64.conf default=0 splashimage=/EFI/BOOT/splash.xpm.gz timeout 10 hiddenmenu title Fedora-17-x86_64-Live-KDE.iso kernel /isolinux/vmlinuz0 root=live:LABEL=Fedora-17-x86_64-Live-KDE.iso rootfstype=auto rw liveimg overlay=UUID=1E6F-32D6 quiet rhgb initrd /isolinux/initrd0.img title Verify and Boot Fedora-17-x86_64-Live-KDE.iso kernel /isolinux/vmlinuz0 root=live:LABEL=Fedora-17-x86_64-Live-KDE.iso rootfstype=auto rw liveimg overlay=UUID=1E6F-32D6 quiet rhgb rd.live.check initrd /isolinux/initrd0.img If you look at the actual paths on the USB stick, the configuration file points to the /isolinux directory to find initrd0.img, but there is no /isolinux directory! The result is that the initial ram disk image is never located, which causes Grub to issue Error 15: File Not Found, and the boot is halted. The correct line entries in this file should be: initrd /syslinux/initrd0.img Implementing this change allows the boot process to locate the ramdisk and the boot proceeds as expected until it is halted by a second error. I'll summarize that one in another post.
SECOND: The kernel line contains an incorrect "by-label" reference to the Live CD .ISO file. Once the first error has been fixed, the initial ramdisk image is loaded and the boot proceeds normally until dracut aborts because it is unable to process the initque. It issues the following two errors. Warning: /dev/disk/by-label/Fedora-17-x86_64-Live-KDE.iso does not exist and Warning: /dev/mapper/live-rw does not exist. If you look at /dev/disk/by-label, the directory hasn't been populated with a reference to Fedora-17-x86_64-Live-KDE.iso. Similarly /dev/mapper doesn't contain live-rw. Hope this helps.
Fixed in https://github.com/lmacken/liveusb-creator/commit/10f4fb3b82e081b835e268713f76c55026bb131f https://github.com/lmacken/liveusb-creator/commit/30a87a0694e5c1bad792b7115d8216a2f953384c and https://github.com/lmacken/liveusb-creator/commit/18ed6caff4ed9804d53e9bde6fc1481bd5ee00c1
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.