Wednesday, December 3, 2014

CentOS 7 Installer Woes

When I first switched to Fedora from the Ubuntu/Debian world, it gave me such a happy feeling. The installer was the best I'd ever used. It was simple and straight forward, and yet didn't make it nearly impossible to do anything remotely outside the box (ala Ubuntu).
Disk encryption was simple to do. It wasn't some scary forbidden thing, deliberately hidden away somewhere on an alternative install image. Everything felt professional, and well thought out. Not the "work in progress" feel you get with some other distros. Despite all the "Fedora is bleeding edge" hype, I actually found it to be less buggy than Ubuntu, including LTS. And when there was a bug, the folks on Redhat's Bugzilla were usually quick to find a solution.

That was Fedora 17. But it seems like they just couldn't resist the urge to fix something that wasn't broken. If you can get past the installer, though, it's still a great system (unless you use Gnome Shell IMHO).

I really can't think of anything nice to say about the installer. You'd think they would have fixed it before the RHEL 7 release. It's pretty much impossible to install to an existing LVM on LUKS setup. You can unlock the crypt, but it can't find the LVM. Your only option is to rsync all your data to another disk, and start over.

With the direction the rest of the Linux desktop world seems to be going, I find myself liking Archlinux more and more. The installation may take a little more time, but you know exactly what's going on. And you can set up the partitions however you choose.

A GUI should make a task easier and more intuitive, not less. Its purpose is to provide an interface to the CLI that requires less spell checking and manpage reading. Not to abstract it into some clever new paradigm that only the developer understands. That's how the Fedora/RHEL installer used to be. Now it's followed Gnome Shell into the "like a tablet, but not a tablet" abyss.

1 comment:

  1. Full ack.

    Example: If you want to use a http:// source, it tries to download the metadata. If you then switch to partitioning and back to the hub, the "Installation Source" and "Software Selection" buttons are greyed out. Installation Source shows "Setting up installation source" You must wait a long time, until the buttons are enabled again. You do not know if it is doing anything until you recognize that it still downloads the metadata.

    Another example:

    You start the install process by selecting the timezone, right? Oh, there is the ntp switch. But wait, you can't enable ntp, yet. You need to go back to the Hub, go to network, configure network and enable, then go back to the timezone settings and now you need to enable the preconfigured ntp servers and afterwards, you can switch on NTP. If you forget to switch on NTP after you enabled the ntp servers, you get an invalid anaconda-ks.cfg file, as --nontp and the ntpservers are configured in the kickstart file.

    Not to mention disk partitioning. This REALLY sucks.
    Not to mention the text mode installer. Anaconda 1 was way better.

    All in all, the installer fails in the most important thing: Guiding users through the installation. The Hub-thing is a very bad idea in my opinion. Dependencies between the functional settings (see above with the ntp settings) in a parallel-approach does not work. Wizard-like guiding as in Anaconda 1 was a much better approach. Also, the kickstart file generated does not hold any partitioning info (at least in my tries).

    ReplyDelete