On Jan 25, 2013, at 5:33 PM, Chris Murphy lists@colorremedies.com wrote:

http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/Making...

3.3.1 refers to a efidisk.img file in the images/ directory on the Fedora 18 installation DVD. This file doesn't exist. There is an efiboot.img, but I'm not sure if that's what should be referenced instead.

https://bugzilla.redhat.com/show_bug.cgi?id=904292

I've updated the bug.

efiboot.img instead of efidisk.img is probably what was intended, but as it turns out, is also incorrect because efiboot.img is not in fact bootable. It only contains boot loaders and will not boot to an installer.

The correct answer is Fedora-18-x86_64-netinst.iso, also known as boot.iso (the two have identical sha256sums for their respective arch).

Where the remaining distinction for BIOS and UEFI is, is the method of creating the media:

A. CD/DVD burned to actual media, produces BIOS/UEFI/UEFI SB bootable media.

B. dd, produces BIOS/UEFI/UEFI SB bootable media.

C. liveusb-creator, still does not produce UEFI bootable media https://bugzilla.redhat.com/show_bug.cgi?id=810112

D. livecd-tools, is the most capable method, but it's also complex with many switches, and documentation presently does tell the user how to make UEFI or hybrid BIOS/UEFI boot media.

Because of this, I think the order of recommended media making methods should change to this order. The suggested order is from easy to advanced. A and B methods are available on all platforms, produce bootable media for all three ISOs: DVD, Live, Netinst, easy to document and for users to follow minimal step instructions; conversely C and D offer more features like persistence and encrypted home, but require more involved instructions that include downloading and installing software, software which is not available at all on OS X.

Last, Table 3.1 needs to be updated. Everywhere boot.iso is found, it should refer to Netinst ISO media. And the last three columns for UEFI should be DVD ISO, Netinst ISO, Netinst ISO, respectively. That is filed as separate bug: https://bugzilla.redhat.com/show_bug.cgi?id=904904

Chris Murphy