Adios Fedora

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.

Partitioning

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.

Software selection

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.

Installing

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).

Software updating

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.

SELinux

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.

Synaptiks

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.

Overall opinion

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.

Advertisements

Tags: , , ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

11 responses to “Adios Fedora”

  1. Cae says :

    Hi, you touched on a topic of grub2 that I’ve come across but do not quite understand. Hope you can spare the time to share a litte more in detail.

    What is the effect if I have Windows (/dev/sda1), Debian (/dev/sda2) and wanted to install say Fedora/openSUSE into /dev/sda3 while

    Case 1 – installing grub2 into the MBR
    Case 2 – installing grub2 into the root partiion (/dev/sda3).

    In each case, will grub2 automatically recognise Windows and Debian and then add a menu item for Windows and Debian so that I can select them during reboot?

    Or there is a need to manually configure grub2 in anyone of the above Case?

    Thanks in advance for the help.

    Like

    • Neil Rickert says :

      In each case, will grub2 automatically recognise Windows and Debian and then add a menu item for Windows and Debian so that I can select them during reboot?

      Yes, that should happen in either case. That is, it should happen unless the root partition of your debian system is encrypted, in which case it will fail to create a menu entry to boot debian.

      Like

  2. Cae says :

    Quote: “But the Fedora developers could still have chosen to install on a partition boot record instead of on the MBR.”

    In this case, I do not understand the difference Fedora installing its grub2 into the MBR or root partition.

    Case 1 : If Fedora install its grub2 into MBR, your openSUSE cannot boot because grub2 does not recognise it since it’s encrypted.

    Case 2 : If Fedora install its grub2 into the root partition, it still would not recognise openSUSE since it’s encrypted, right? Or will Fedora’s grub2 be not activated (since it’s in root partition?) and your openSUSE’s grub2 will still be working?

    Like

    • Neil Rickert says :

      In case 2, I would use the grub2 installed with opensuse for booting both systems. Flipping which partition is active controls which will be the primary booter. And, of course, I want the primary booting to be handled by my primary system, not by a temporarily installed test system.

      Like

      • Cae says :

        Correct me if I am wrong,

        installing grub2 into a root partition basically makes it inactive, though with all its grub2 configuration properly done from its OS (in this case, Fedora) perspecitve.

        The grub2 in the MBR (in this case, openSUSE) will still be utilised for booting.

        On second thought, I actually don’t think I am correct. Your openSUSE’s grub2 is also on it’s own root partition right? The answers lies in the “Flipping which partition is active controls”…. how is it done?

        Like

        • Neil Rickert says :

          Grub2 for opensuse is installed on “/dev/sda1” which is really “/boot” (the root file system is encrypted, so installing there doesn’t work).

          When I install opensuse, there’s an option to not touch the active flag. I don’t think Fedora ever offered that. When I tested Fedora 17 last year, it did flip the active flag to make itself the primary booter. But it is easy to run “fdisk” and change that back.

          I think I’ll do a post on grub2 later today.

          Like

          • Cae says :

            Thanks for the patience, will read your next article in detail.

            By the way, have tried Fedora previously and had decided “Adios Fedora” some time ago.

            Like

  3. Steven Roy says :

    Synaptiks might not be in the default repo, but people who use fedora generally add the RPMFusion repos in order to access common software that doesn’t meet the inclusion criteria for the main repo. Also, why not just use yum? I have used Fedora for over a decade now and have never used the gui for updates. To be honest, one of the main reasons I stick to Fedora and Arch is that I like the cli package management tools that are available for them… Anywho, if you ever try it again, add the RPMFusion.org repos (free and nonfree).

    Like

    • Neil Rickert says :

      Thanks. I did not know about RPMFusion.

      I have used “yum” a couple of times, now that another commenter has mentioned it.

      I have not yet deleted Fedora 18, and I am still updating it. But I may ditch it when early versions of opensuse 13.1 become available for testing.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: