Description of problem: I've used livecd-tools-16.11-1.fc16.x86_64 on F16 to write the F17.TC1 live desktop image to a USB key, as follows: livecd-iso-to-disk --format --reset-mbr --unencrypted-home --noverify --efi /home/jsmith/ISO/Fedora-17-Beta-rc4-x86_64-Live-Desktop.iso /dev/sdb When I boot from the USB key on a Lenovo Thinkpad x200 (with the BIOS set to boot only from UEFI mode), I get a GRUB menu, but then the system complains and says "Error 15: File not found". Version-Release number of selected component (if applicable): livecd-tools-16.11-1.fc16.x86_64 How reproducible: Every time. Tried two different USB keys. Steps to Reproduce: 1. Build a F17.TC1 live USB key (with the --efi switch to livecd-iso-to-disk) 2. Boot from it 3. Look for the error message from GRUB Actual results: Error 15: File not found Expected results: GRUB should be able to boot the Live image Additional info:
Fails in a VirtualBox 4.1.12 guest using EFI. Also fails in 17 Beta Gold. Works in 16 Final. If necessary I could rebuild the 17 TCs/RCs to see which is the first one that fails.
Results of testing on x86_64 DVDs in a VirtualBox 4.1.12 guest using EFI: 17 Alpha TC1 PASS (X startup failed, falling back to text mode) 17 Alpha TC2 PASS (X startup failed, falling back to text mode) 17 Alpha RC1 FAIL (grub prompt) 17 Alpha RC2 FAIL (grub prompt) 17 Alpha RC3 FAIL (grub prompt) 17 Alpha RC4 FAIL (grub prompt) 17 Beta TC1 FAIL (grub prompt) 17 Beta TC2 FAIL (grub prompt) 17 Beta RC1 FAIL (grub prompt) 17 Beta RC2 FAIL (grub prompt) 17 Beta RC3 FAIL (grub prompt) 17 Beta RC4 FAIL (grub prompt) 17 Final TC1 FAIL (grub prompt) Note that Adam Williamson gave a pass to 17 Alpha RC4 and 17 Beta RC3 in the test matrices, so VirtualBox behaves differently from whatever hardware he was using. The delta ISOs for rebuilding these ISO are at http://dl.fedoraproject.org/pub/alt/stage/deltaisos/ and will be in the archive/ subdirectory after 17 is released. I'll keep these ISOs on my HDD for a while in case there are questions.
The behavior with 15 and 16 Final is the same as 17 Alpha TC{1,2} - it boots, after a long delay, but X startup fails and it drops to text mode. With 14 Final it drops to some kind of interactive EFI prompt and I have no idea what's up with that.
The behavior with 15 and 16 Final is already reported in bug 742695.
For what it's worth, writing the disk image to the USB key using "dd" instead of livecd-iso-to-disk allows me to boot on the EFI machine. It seems that livecd-iso-to-disk is doing something that makes GRUB unhappy with the path to one of the files. I'm happy to do additional testing if you have something you'd like me to try.
This makes a EFI boot USB of the DVD Disk-Utility Format USB (8 GB) /dev/sdb1 fat label=LIVE boot flag (CAPS) /dev/sdb2 (7GB) label=LIVE-REPO -(need 3.6 Gb for DVD.iso on /dev/sdb2) Note; 2 partitions being written below: mkdosfs 3.0.9 (31 Jan 2010) mkdosfs 3.0.9 (31 Jan 2010) # ./tools_livecd-iso-to-disk.sh --format --efi Fedora-17-TC1-x86_64-DVD.iso /dev/sdb1 Verifying image... ./tools_livecd-iso-to-disk.sh: line 900: checkisomd5: command not found Are you SURE you want to continue? Press Enter to continue or ctrl-c to abort /Packages found, will copy source .iso to target WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdb!!! Press Enter to continue or ctrl-c to abort wipefs: WARNING: /dev/sdb: appears to contain 'dos' partition table Waiting for devices to settle... mkdosfs 3.0.9 (31 Jan 2010) mkdosfs 3.0.9 (31 Jan 2010) parted: invalid token: legacy_boot Cleaning up to exit... root@robert-Tris55:/home/robert/Desktop# root@robert-Tris55:/home/robert/Desktop# ./tools_livecd-iso-to-disk.sh --format --efi Fedora-17-TC1-x86_64-DVD.iso /dev/sdb1 Verifying image... ./tools_livecd-iso-to-disk.sh: line 900: checkisomd5: command not found Are you SURE you want to continue? Press Enter to continue or ctrl-c to abort /Packages found, will copy source .iso to target WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdb!!! Press Enter to continue or ctrl-c to abort wipefs: WARNING: /dev/sdb: appears to contain 'gpt' partition table Waiting for devices to settle... mkdosfs 3.0.9 (31 Jan 2010) mkdosfs 3.0.9 (31 Jan 2010) Copying live image to target device. squashfs.img 137752576 100% 8.60MB/s 0:00:15 (xfer#1, to-check=0/1) sent 137769465 bytes received 31 bytes 8888354.58 bytes/sec total size is 137752576 speedup is 1.00 Copying /home/robert/Desktop/Fedora-17-TC1-x86_64-DVD.iso Fedora-17-TC1-x86_64-DVD.iso 3832545280 100% 4.88MB/s 0:12:28 (xfer#1, to-check=0/1) sent 3833013210 bytes received 31 bytes 5114093.72 bytes/sec total size is 3832545280 speedup is 1.00 Updating boot config file Installing boot loader Target device is now set up with a Live image! # Note I did not attempt install on this MacBookProi7
note this was done on Trisquel 5.5 (Ubuntu) laptop with git (raw) of l-i-t-d downloaded and marked executable. Also tested in f17 TC1 gnome3 install to HD
The livecd-tools fix for bug 806166 should also take care of this one. Please try the latest build from testing. I've tested with TC1, F16 and RHEL6 DVD's and Livecds and they all work on EFI. FYI - as of anaconda-17.23-1 we don't need to make 2 partitions on the USB for DVD's. The latest litd has been modified to handle this.
Still get the grub prompt using 17 Final TC2 and VirtualBox 4.1.14.
Jared, can you let us know if your system is still problematic with TC2/TC3/TC4? I think Andre's bug is different and specific to VBox. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes, TC4 appears to work much better. I wrote the image to the USB key using " livecd-iso-to-disk --format --reset-mbr --efi Fedora-17.TC4-x86_64-Live-Desktop.iso /dev/sdb", set my BIOS to UEFI only booting, and booted from the USB key. I think we can now close the bug, as I think the problem with livecd-iso-to-disk has been fixed.
OK. Since the OP's bug is fixed and there's no indication any other issues mentioned in this bug are truly related, closing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I filed bug 820797 for the grub prompt issue for EFI booting in VirtualBox.
works on TC5: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_TC5_Install#USB_Stick
This is still an issue. I am trying to install onto an Asus ultrabook ux-31e via the usb. I have tried all suggestions above except for satellit's method since I only have a 4.2gb usb stick. I will get the error 15, or it just hangs after the following message: "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... I have tried with the live f17 dvd, cd and netinst iso files (64bit) all with the same results. Hopefully we can get this to work as this great ultrabook will suck without fedora. Ubunto usb install works fine so something must be missing from the F17 installer? Cheers, Jon
Jon: your report sounds nothing like the original here, and the original reporter confirmed his bug was fixed. Please file yours separately. If possible it would be useful if you could try Fedora 18 Beta TC6 - https://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC6/ - because we cannot do anything about 17 at this point, 17 is released. We wouldn't necessarily recommend you use Fedora 18 as a day-to-day OS at this point unless you're comfortable with running pre-release software, but it would be useful to know at least if you can successfully run the installer via native UEFI. But in a new report. Thanks.
Hmmm, it sounds like the identical issue to me, including the livecd command the op used, what sounds different to you? I will try F18 TC6 and see if I have some success but I see no reason to open a new bug since this one describes what I am experiencing so accurately, though it may have been solved previously it seems to have resurfaced. Best regards, Jon
For a start, you're not using the same system. For a second, Jared said writing the image using dd worked fine for him, but you say "I have tried all suggestions above except for satellit's method since I only have a 4.2gb usb stick.", implying you tried writing it using dd and it didn't work.