Thanks for this, Wayne. I'll address each point individually.

(In reply to comment #0)
> Description of problem:
> 
> I have noted a number of places mentioning UEFI need updates or refinements. 
> The note at the top of chapter 7 should be modified from:
> 
> <quote>
> Fedora 16 does not support UEFI for 32-bit x86 systems.
> </quote>
> 
> to
> 
> <quote>
> Fedora 16 does not support UEFI booting on 32-bit x86 systems. Only BIOS is
> supported for such systems.
> </quote>
> 
> (The original wording suggests that you can't install Fedora 16 on such
> systems.)

No problem. I've fixed that up.

> 
> Section 7.1.3 ("Additional Boot Options") doesn't describe using the network
> install CD at all.  (That section needs to include the steps for a network
> install, which of course are nearly the same as for a local install.  The
> main difference is the the network connection must be useable at install
> time, and the install itself will generally take longer then installing from
> local media, but has the advantage is installing the latest versions of each
> package.)

I'm unsure why the network install CD needs to be specifically mentioned in "Additional Boot Options". The installer prompts for a network connection if one hasn't been set up to connect automatically, the "Boot Options" chapter has a section on "Specifying the Network Settings" if they do need to be specified at boot time, and the "Configuring Installation Source" chapter explains how to specify a networked installation repo at boot time. 

And as you say, the installation process is very similar to a local installation, so I don't see any need to mention the netinst.iso specifically. But please elaborate if you still feel mentioning it would be beneficial.


> 
> Section 9.5.1, the "Note" box says to use system-config-network, but the
> following paragraph says to use NetworkManager tool.  I don't believe those
> are
> the same thing, and the actual name of the NetworkManager tool isn't
> NetworkManager (?); also the wrong font is used, if that is indeed the
> utility
> name.

Yes, NetworkManager can take care of configuration after installation, so I've edited this note. The location will likely change in F18, so just search for the following note text: "You can also use Network Manager to change your network configuration after you have completed the installation. "

However, the font is correct in the following paragraph. Publican assigns the font based on the tag we enter, which is determined by the function of the reference. In this case, the first referred to a GUI dialog, the second to the application itself, hence the different fonts.


> 
> The Warning box in section 9.11, "Use Free Space", says "If your 64-bit x86
> system uses UEFI instead of BIOS, you will need to manually create a /boot
> partition. This partition must have an ext3 file system."  Surely this should
> be "ext2, ext3, or ext4 file system"?  This note is repeated in 9.13.  This
> contradicts the note in 9.13.5 ("recommended disk layout").

This isn't necessarily a contradiction. For the note in the "Recommended Partitioning Scheme", I assume you're referring to the following:

"The GRUB bootloader in Fedora 17 supports only the ext2, ext3, and ext4 (recommended) file systems. You cannot use any other file system for /boot, such as Btrfs, XFS, or VFAT. "

This refers to what GRUB supports but does not refer to BIOS or EFI, whereas the "Use Free Space" admonition refers specifically to EFI, which may necessitate further restrictions on which file system is used. If you are confident that saying only ext3 is supported is wrong, can you please provide more information?

> 
> Section 9.13 omits any reference to the "BIOS boot" partition, or the ESP. 
> I think the ESP should be shown in the recommended layout, as vfat, 150-300
> MiB
> sized partition mounted at /boot/efi/.  With a note stating that ext2, ext3,
> or
> ext4 types could be used but may cause problems with dual-booted systems. 
> (I noted that Anaconda does not create a separate ESP when automatically
> partitioning the disk.)

I've just fixed this up in bug 827138, along with some other partitioning requirements.

> 
> In Appendix A, table A.1 "Partition Types" is out-dated.  At the very least
> you
> need to add the entry for the ESP and the BIOS Boot partitions.  The take
> should list both the BIOS type number (a one-byte hex number) and the GPT
> GUID numbers which are much longer.  (Instead of the GUIDs for GPT
> partitions, I would suggest listing the gdisk/cgdisk/sgdisk two-byte hex
> codes.  Or maybe both should be listed, as it is possible someone may need
> to format a GPT disk using some other tool.)

David Lehman has told me that he doesn't believe that GUIDs need to be listed.

I'd like to add the one-byte hex values for BIOS Boot and ESP, but am unable to find them anywhere online. If you know them, Wayne, let me know and I'll add them to the table.

> I'm unsure why the network install CD needs to be specifically mentioned in
> "Additional Boot Options".

Only because, most people don't know this option exists at all.  It is a useful option, especially when installing some time after the version was initially released (because then people install from local media, but the first yum update reinstalls hundreds of packages, so it saves time to use a network install in that case.)  But the guide doesn't even mention there is such an option, yet it lists other options.  That's why to me it would make sense to at least mention a network install.

> "You can also use Network Manager to change your network configuration
> after you have completed the installation. "

"NetworkManager" is one word, but I think the actual, executable utility is one of "nmcli", "nm-tool", or "nm-applet".  That's why I said the font was wrong.

> If you are confident that saying only ext3 is supported is wrong, can
> you please provide more information?

I ran F16 installer, and it creates ext4, not ext3.  The system works fine.  So "ext3" only is certainly wrong.  But I don't know about ext2 support; that's just a guess on my part.

> I'd like to add the one-byte hex values for BIOS Boot and ESP, but am
> unable to find them anywhere online. If you know them, Wayne, let me know
> and I'll add them to the table.

I found them only by asking the Rod Smith, the author of gdisk.  A part of his email response is below.  If you need more information, I found he is willing to respond to emails (rodsmith).

On 01/02/2012 05:28 AM, Pollock, Wayne wrote:
> ...
> Thanks for great information!  It it very timely for me.  I do have one
> question, on the partition type numbers.  Your articles and web page
> show these as two byte numbers, for example 0xEF02.  I understand the
> first byte corresponds to the MBR one byte type code.  I'm guessing
> the second byte is a fake value, used by your tool, to set attributes
> in the GPT entry.  Is that right?  I'd appreciate a clarification of
> what those two byte hex codes mean.

More-or-less, yes. When I wrote gdisk, I was aiming for something that
was as similar to Linux's fdisk as possible, but the GPT partition type
codes are ungainly GUID values, which couldn't be shown easily on the
partition table summary display, much less entered easily by human
beings. Thus, I decided to implement a code system in which I used an
MBR type code (0x07 for NTFS, 0xEF for an EFI System Partition, etc.) as
the first byte and 0x00 for the second byte. Since the MBR-GPT type code
correspondence isn't 1:1, I expanded this by using additional arbitrary
second-byte values for related codes that don't have corresponding MBR
partition types. The 0xEF02 code you mention, for instance, corresponds
to a BIOS Boot Partition. There's no such code on MBR, but as it's a
type of boot loader partition, it's similar in purpose to the ESP (type
code 0xEF00), so 0xEF02 is a sensible code for it. There's a lot of this
will Solaris, Apple, and FreeBSD type codes, too.

In any event, on some level this is all entirely arbitrary. My goal in
the numbering was simply to smooth the way for people who are familiar
with MBR type codes. The mapping is set up in the parttypes.cc file, in
the PartType::AddAllTypes() function.

<end of email>

Hope that's the information you wanted.  Happy Thanksgiving!

Well, this is an ancient bug and the guide has been almost completely rewritten in the meantime, so I think we can safely close this. If there are still problems with what the guide says about UEFI, feel free to open another bug for the same component.