As suggested in my preliminary report, I have now installed Fedora 18 for more thorough testing. I won’t be doing that again any time soon. I found this a very disappointing release.
My installation was on an older (2004 vintage) laptop with a 32 bit processor and around 1.2G of memory. That’s a machine that I have relegated to use for testing. Apart from being a tad slow by today’s standards, it actually does pretty well. In any case, the limitations of the test machine are unrelated to why I did not like Fedora 18.
The installer sucks
The Fedora folk have replaced their old installer with a new version. The new installer (called “anaconda”) is one of their bragging points at the Fedora Project site. Regrettably, it is nothing to brag about.
For installing, I used the 32bit DVD image. I wrote that to an 8G USB drive, with the “dd_rescue” command. Booting the USB proceeded without difficulty.
Network connection during install
One of the first few installer screens told me that a network connection is needed (for updates, etc). It listed “eth0” and “wlan0” as options. Since I normally use this computer with WiFi, I selected “wlan0”. The next screen asked for the network name (which I took to mean the SSID) and the network key. I started to type in the SSID, and some part of the installer crashed.
I rebooted the computer, and restarted the install. But, before restarting, I plugged in an ethernet cable so that I would not repeat that WiFi mishap. The screen prompting for a network never appeared. Presumably the installer was happy with the ethernet connection that it had found.
The partitioning section of the installer seemed a tad confusing, but not too bad. I managed to work my way through it. I chose to re-use the partitions where I had previously installed Mint 11. I made sure not to touch any of the partitions used for opensuse 12.3 Beta1, which is also installed on that machine. I selected expert partitioning, though I think the name was something else. What was slightly confusing, was that I had to specify formatting of one of those partitions before I could select it. I think it would have been less confusing if I had been able to select it first, and then specify that it be formatted. This was for my swap partition, and presumably the installer did not recognize that because I had use randomly encrypted swap with Mint.
I did not like the software selection part of install. I could choose a desktop (I selected KDE), and I could choose large software groups (I selected the development group – compilers, etc, and the multimedia group). There was no place where I could make selections at a finer level. I already knew, from testing their live image, that KDE came with konqueror as the browser. I would have liked to select firefox as an additional browser to install, but there was no option for that level of selection.
Booting setup section
Unfortunately, there was no installer section for specifying the details of booting. I would have liked to boot from the root partition (“/dev/sda2”), but there was no way to choose that.
It turned out that grub2 was installed in the MBR, which I did not want. When I installed Fedora 17 last year, I at least could specify where to install grub2. But that option was not available with Fedora 18.
When the installation was done, I had a system that could only boot Fedora 18. It could not boot the opensuse 12.3 Beta1 system also on the disk. That’s just wrong. That’s inexcusable. If grub had been installed on the root partition, that would not have been a problem. Of course, I know how to make opensuse accessible again, but this problem should never have been foisted on me.
I guess I should expand that a little. A windows installation on the same disk would still be bootable. Most likely my opensuse installation would also have been bootable if it were not in an encrypted LVM. However, because it is in an encrypted LVM, it was not recognized, and no boot entry was added for it. But this is still wrong. The primary partition “/dev/sda1” has a bootable flag. There should be an entry generated for chain-loading to boot any primary partition with a bootable flag. This blame for this is partly with the grub2 developers. But the Fedora developers could still have chosen to install on a partition boot record instead of on the MBR.
There’s actually a bug report for this. From reading the bug report, it looks as if the Fedora people have decided that this is not a bug. It that kind of “My way or the highway” attitude that persuades me not to bother with Fedora in the future.
The same grub2 is being used in opensuse 12.2, and the same discussion came up there. The grub2 developers think it should only be installed on the MBR. Fortunately, the opensuse people listened to what folk wanted, and they allowed us to select where to install grub2.
After making the software selection, the actual installing was uneventful. In my opinion, there was too little information provided on what the installer was doing.
The installed system
After the first reboot, I logged into the installed system. It was pretty much like the system that I had booted from the live image, though with some additional software (the development and multimedia groups that I had selected).
One of the first things that I did, after logging into the system, was to setup WiFi. Shortly after that, a notification appeared that there were 334 updates. That seems a lot, for only one week after the release date. But, never mind, I proceeded to try installing the updates.
The updater is Apper. It listed the updates available. I selected all. Then I found something else to do for a while, while it was working on the updates. I checked back after a while, and it seemed to be applying deltas (difference between the installed and new rpms). After a while longer, that stopped, and Apper seemed to be doing nothing. A “netstat” showed no open network connections, and a “ps” showed little activity. The indicator still said that there were 334 updates to install.
This was not a surprise. I had the same problem with Fedora 17. Apper could not handle such a large number of updates. So I rebooted, and then restarted the updater. This time, I selected around 64 updates to install, and told it to go ahead. After a while, it reported that it had installed those. It looked as if it did not download anything. Presumably the first update attempt, the one that ended in a hang, had already downloaded what was needed.
After that, I selected around another 64. This was a tad confusing, because Apper said that I had selected around 130. It had not reset its count from the first round, so what it was showing was the cumulative number. I proceeded to the install of those. Two more rounds of installing, and I was done. If it looks as if 4*64 is less than 334, that’s because Apper also does a dependency check, so adds some additional updates to the list with that. So four rounds total were sufficient.
While having to do four rounds of partial updates is poor performance, it is actually better than with Fedora 17. As I recall, with that earlier version, I had to reboot between each of the rounds of updating, and I did not need to do that with the Fedora 18 updater. So at least that has improved.
Restoring access to opensuse
After I had finished the updating, my next step was to restore access to the opensuse 12.3 Beta1 system that had become inaccessible due to the way the installer works. My plan was to run cryptsetup to make the encrypted LVM accessible. Then I would make the volumes within the LVM accessible. Then I would run “grub2-mkconfig” to rebuild the grub configuration. That should now find the opensuse system, and add menu entries to boot it.
Unfortunately, the LVM software was not installed. So I had to go to the software installer (again Apper), and install the lvm2 tools. That went without problems.
While I had the LVM volumes accessible, I mounted the one where I had saved a tar archive of the “/home” from my earlier Mint installation. I unpacked that, so that I would have some useful files and scripts available on the Fedora 18 installation.
I normally configure sshd to only allow publickey authentication. That’s more secure, and blocks ssh hacking attempts from the Internet. So I configured that restriction in “/etc/ssh/sshd_config”.
I later tried to login over the network from my usual desktop system. The login failed. Checking the logs, it turned out that SELinux was blocking publickey authentication. Note that “SELinux” is supposed to be “Security Enhanced Linux”. But here, it was weakening my security by not allowing publickey authentication.
Sure, the SELinux message does explain how to change this. Still, it looks like a poor decision was made by the developers.
I had a similar problem with ecryptfs. I installed ecryptfs-utils. After the next boot and login, I checked to see whether my ecryptfs private directory was mounted. It was not. But there was an SELinux message, telling me that the ecryptfs mount had been blocked. I could still use the command “ecryptfs-mount-private” to mount the directory, but the automatic mounting via PAM rules was being blocked.
I really like synaptiks, and I always use that with KDE on opensuse. It has a nice feature of disabling the touchpad if another mouse is plugged in. That’s better than permanently disabling, for it leaves the touchpad available if I don’t have another mouse.
Unfortunately, synaptiks was not part of the install. So I ran the software installer. It looks as if synaptiks is not in the repos either. I guess I will have to manage without.
Before testing Fedora 18, I had considered Fedora my next choice after opensuse. Not any longer. There is too much I don’t like about Fedora 18. The major problems are the installer, and the decision to force grub2 to the MBR. I could live with the other quirks — no operating system is perfect. But the installation and booting flaws put Fedora out of consideration for the present.
I will leave it on my disk for a while, until I am ready to try something else. So I’ll have a chance to explore some of the other parts that I have not commented on. It something important shows up, I’ll post again on that. But I won’t be expecting to review future Fedora releases, unless I hear that there have been significant improvements.