Fedora 19 — More changes

Fedora 19 was released on July 2, 2013.

Fedora is the Linux distribution used for wide release of relatively new technologies and might be considered the test bed for things that will later appear in Red Hat and CentOS distributions. Red Hat provides a great deal of support to the Fedora project, including developers and monetary.

I have been working and experimenting with Fedora 19 now for a couple weeks. I have installed it several times on a number of virtual machines and I now have installed it on my primary workstation and laptop.

There are more interesting changes in this release and a couple of them have cost me a bit of time while I experimented and located the causes of some issues. As with most new releases there is some good and a little bit not so good.


Fedora 18 introduced the new Anaconda installer and Fedora 19 adds a few improvements that make installation go even more smoothly. Most of the changes that affect me are in the Installation destination section.


The Installation Destination section is where you can specify which hard drives on which you want to install, and where you can customize the filesystem configuration if you so choose. This is where it gets a bit confusing. After selecting the Installation Destination, there is no apparent way to customize the partitioning.

First you need to make the selection of the disks on which you want to install Fedora 19 — the most likely disks are automatically selected — and then click on the Done button. The Installation options window as shown in the figure, below, is displayed. At this time you can choose Custom partitioning and create any partition scheme you need.

Fedora 19 custom partitioning options

Fedora 19 custom partitioning options

I seldom use the default filesystem configuration, so this is the portion of the installation on which I usually spend the most (human) time. Customized partitioning during the installation has always been time-consuming.


The Fedora first-boot sequence has been badly modified. This is the program that runs once on the first boot after an installation. It displays a “Welcome” screen, allows you to create a new, non-root user, set the date and time and activate NTP.

When installed with Fedora 19, it asks you to select a language, which is redundant in my opinion, because the language was already selected during the installation configuration. Although what may be taking place is a division between the language of installation and the default user language.

There is an option to connect to your cloud accounts such as Google.

You must also choose your location for a second time. Perhaps this is again a movement towards separation between installation configuration and operational configuration.

Then you get to create a new user. When using GNOME as the primary desktop, you are automatically logged in after creating the new user, and an “Introduction to GNOME” interactive tutorial is launched. This will probably be helpful for first-timers to Linux, and especially newcomers to GNOME.


One of my primary issues with the new Anaconda, starting with Fedora 18, is that one can no longer pick and choose from all possible packages to install. This means that no matter what I am able to install using the Anaconda installer, I still have to do some post-installation work to install all of the applications, services and utilities that I use on my various computers.

If you are in a large environment and use Puppet or some form of Kickstart installation, it is easy to deal with this, but for small environments where automated installations take huge amounts of resource just to create and configure properly, post-installation scripts are the way to go. My post-installation script is installed along with some other useful programs and configuration files using an RPM of my own creation.

I started working on the RPM and script several years ago and they have continually evolved as Fedora has evolved. The basic idea is that I can simply do a default installation with respect to the installed packages and package groups and then run my script post-install. Based on the type of tasks for which the host is intended, I can choose options that install desktop or server types of applications.


Some services have changed a bit in Fedora 19. These changes do not seem to be documented in such a way as to be obvious until one experiences a problem and begins to research it with Google.

Firewall redux

The new firewalld firewall daemon is still the default, but the IPTables firewall has been split into two component RPMs for Fedora 19. Only IPTables itself is installed by default while the systemd startup configuration for IPTables has been split out into the iptables-services RPM and is not installed by default.

What this means is that, if you want to use IPTables instead of firewalld, you must install the iptables-services RPM in order to configure IPTables to start automatically at boot time.


Apache changed in Fedora 18. I did not realize this until I tried to configure multiple virtual hosts using Apache and Fedora 18.

Apache works fine when used to support a single web site. When configuring virtual hosts, where multiple web sites are served by a single instance of Apache, the first web site works fine, while the second virtual host fails.

I have not yet tracked this down to either a code problem or a configuration problem, but I hope to do that soon. I will update this review with the results when I figure it out.


The MySQL database was obtained by Oracle when they purchased Sun Microsystems a few years ago. The folks that maintain MySQL have the same concerns about any directions that Oracle might take with MySQL that the developers for OpenOffice did. So the developers for MySQL have done the same thing that the developers for OpenOffice did a couple years ago with LibréOffice, they forked a new code base and are developing it now under the name of MariaDB.

MariaDB is intended to be a drop-in replacement for MySQL, including all library entrance points and down to the daemon names. This enables the maximum possible compatibility and continuity when upgrading from MySQL.

The developers of MariaDB have already made a few internal code changes that provide improved speeds, so like LibréOffice the pace of innovation and the quality and speed of fixes should improve.


After being switched from our long-time NIC naming conventions of ETH0, ETH1, etc., to more descriptive names like EM1 (Embedded Motherboard 1), P2P1 (PCI Bus 2, Port 1), and so on, there is now a new set of totally random-seeming and meaningless NIC names.

What do “enp0s25” and “enp0s29f7u2” mean—if anything? What kind of names are these and how do they relate to reality? The previous new naming convention was at least designed to make a connection between logical NIC names and the physical ports on the hardware. The new new naming convention is horrible as it does not seem to relate to anything.

There is a bug report on file at Red Hat that seems to cover this situation. It was reported by Lennart Poettering, the author of the systemd startup and daemon management system. There is a considerable amount of discussion and disagreement about this change so I don’t think anyone knows how this is going to play out in the long run.

My vote is to return to the old new method of naming that was meaningful.


After commenting on the bug for this issue, I received the following response in a couple hours.

— Comment #39 from  —
It’s even in the subject of this bug


If you don’t want to read that, just go straight to the examples:


And no, P2P1 is only slightly better than eth0, it has a lot of the same
issues that always arise when someone “invents” names by counting global
numbers upwards. Counters depend on overall system state, on cross-device
and sibling device dependencies, and are fragile and unpredictable when
things change in unexpected ways.

The new names will not win a price for being pretty, granted; but the logic is
so trivial, that it should be reasonable safe to assume that it works reliably
in all common cases.

There is zero system-state involved, not cross-device dependencies, no
enumeration order, no driver probing order, all device names are only composed
of the data of that one single device that i detected. And that was absolutely
worth the change so far.


All the usual applications are provided in the distribution ISO image, and many more are available from the RPMFusion repositories. All of the applications I use are provided and most have changed little.

The main difference I have noticed is that LibréOffice 4.X is supplied with Fedora 19, while 3.X was provided with Fedora 18.

LibréOffice 4.x now supports PageMaker files directly and one of my customers has a need for this. The documents I have tried work pretty well, but import into LibréOffice Draw. As a result any layers are lost and text does not flow around objects that are placed into a column. One other strangeness I noted, was that one text box was upside down upon import.  I was able to work around these issues fairly easily.


Once again Fedora is on the very leading edge of development. It is not quite the bleeding edge, but can be close. Many of the changes that have been introduced into Fedora over the past few releases have yet to make their way into Red Hat and CentOS. But they will.

There are issues that need to be resolved with naming of network interfaces and post-installation processing, as well as significant limitations in the flexibility of the relatively new Anaconda installation program. Hopefully these issues will be resolved quickly.

My experience with Fedora 19 is that it is stable and very usable for both desktop and server applications. I like Fedora and I will continue to use it in most circumstances.

Change happens, but one has to embrace change when computers are involved.

Getting Fedora 19

Fedora 19 can be downloaded from the Fedora Project. It is free of charge and free from onerous license terms. You can install it as many times on as many computers as you want and give it away to your friends.