As per the Fedora Server tech spec, its default filesystem should be XFS: "The default file system type for Fedora Server installs will be XFS running atop LVM for all partitions except /boot. The /boot partition will remain a non-LVM partition due to technological limitations of the bootloader." https://fedoraproject.org/wiki/Server/Technical_Specification#File_system However, this has not been implemented anywhere so I don't believe it actually happens, the default FS for Server installs is almost certainly still ext4. I believe what's needed to fix this is a new anaconda install class that inherits the main Fedora install class, matches on productVersion starting with "Fedora Server", that has a higher priority than the main Fedora install class so it overrides it (see pyanaconda/installclass.py around line 234), and that just sets defaultFS = "xfs" (and of course anything else we want to vary in Server that is set in the install class).
so this isn't as simple as writing a little derived class because the code in question is somewhat odd (or, as has been alleged, "a silly relic" and/or "Ye Olde Code(e)") and expects all install classes to be called, well, InstallClass. Obviously InstallClass can't derive from, well, InstallClass. It'd be easy enough to write a whole new install class that was just a copy-n-paste of the main Fedora one but with the changed default filesystem, but it'd also be dumb, so let's not do that. clumens has bottle in hand and is going to try and make the code better. I'm recognizing my limitations.
https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013013.html should fix up finding the install classes. I did a brief test creating a FedoraServerInstallClass with a different default fs type and higher priority, and it worked in a quick test. I did not deal with all the productName stuff, which is why it's not included in this patch.
I think the way it 'should' work is that the Server class (and any other product class) should have a higher priority than the generic fedora class, and be 'hidden' *unless* the productName matches to the level of the Product. That should produce correct behaviour (the product-specific class is used if a match on the product name is found, the generic fedora class is used if there isn't a Product-level match). I'll try and bash that togethr later if no-one else beats me to it.
anaconda-21.48.5-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/anaconda-21.48.5-1.fc21
I don't believe the update really fixes the bug, as it doesn't implement the product class (sorry, I didn't get around to it yet). The update probably shouldn't be set to close this bug.
Package anaconda-21.48.5-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-21.48.5-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10605/anaconda-21.48.5-1.fc21 then log in and leave karma (feedback).
Cleaning up some old bugs. This was fixed in Fedora 22 Alpha.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 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 this bug is closed as described in the policy above. 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.