This is known in the anaconda team, but not reported until now.

When doing an F18 live install with the current Alpha stuff, /etc/fstab is not written properly to the installed system - you wind up with the /etc/fstab from the live environment.

The installed system still actually boots, because the root partition location is passed in on cmdline. But we're aware of at least the following consequences:

The /home partition (which will be automatically created as long as the target disk is big enough) won't be mounted
No swap partition will be activated
The /boot partition (one is always created by autopart) won't be mounted
No other partitions the user may create in custom partitioning will be mounted

A consequence of /home not being mounted is that firstboot will create the user and initial files in a /home directory on the root partition, so even if you fixup fstab, you'd have to move that stuff across too. Having no swap partition can lead to ugly OOM behaviour. And /boot not being mounted means kernel updates won't work right - the package will write everything to a /boot subdirectory of the root partition, which isn't what'll actually be used on boot. You'd just be stuck with the initially installed kernel forever.

There may be other consequences we haven't figured out yet either. This is obviously really bad breakage and should be considered an Alpha blocker. Let's say it's a conditional violation of "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops", for kernel updates, but there's other justifications available too.