Linux

Moving to Arch Linux from Fedora

Chris Duckett details his move from Fedora to Arch Linux and learns that testing in a virtual machine is one thing, actually committing to change is another.

A little over seven weeks has passed since I wrote my thoughts on Fedora 17, and finally, those little paper cuts became too much.

At the end of my time with Fedora, I'm willing to concede that any blame for the rotten state that Fedora has fallen into, rests at the feet of Fedora's PreUpgrade tool, and at myself for having used it in the first place, with Fedora 15 and again with Fedora 16.

By speaking to other users and reading many forum posts, it's clear that, for the best Fedora experience, one really should do a fresh install of each new version of Fedora. My personal tastes consider re-installation of operating systems as an archaic practice that best belongs to the previous decade. Therefore, my choice for wanting to upgrade every six months, rather than reaching for the format-and-replace option, was, at least to me, completely obvious.

Unfortunately, Fedora and I currently have a difference of option on the matter.

But, if you are not as precious as I am about bi-annual re-installations, then Fedora is one of the better Linux distributions on offer.

So long Fedora

Once I accepted the reality that I would need to do a re-install to fix the bugs I had encountered with Fedora, the next question was to decide if Fedora was the best distro for me. Here, my Gentoo bias came into play. Was there a well-supported Linux system that was a rolling distribution and wasn't exclusively source-based? (I like Gentoo, but I'm not crazy enough to compile on a laptop that is used for work, and find myself on the bleeding edge of breakage and the associated lack of productivity.)

As the title gives away, the winner in this contest was Arch Linux, but I did look at Linux Mint Debian Edition, as well. I still had the LMDE virtual machine lying around from May, and I occasionally sparked it up to see how often the system was updated. It was rarely updated in my experience, and this counted against it.

Maybe next time I go on a search for a new operating system, I'll also peer into the world of the BSDs. When I do, PC-BSD will certainly be the first one I reach for, but for now, I wanted to stay with Linux.

The reasons why I choose Arch came down to an active community, excellent wiki. I was also sick of hearing about the awesomeness of the Arch User Repository (AUR), and wanted to try it for myself.

The move was on.

But before destruction arrived, I needed to backup as much as I could on my trusty backup drive.

Out came rsync. The prime reason for using rsync is that it will copy over the "hidden" files and folders where much of the per user config on Linux is kept. In Linux, hidden files and directories begin with a dot, such as the /home/[user]/.cache directory.

The command I used to backup almost everything was:

rsync -av /{bin,boot,etc,home,lib,lib64,opt,sbin,usr,var} /[path]/[to]/[backup]/[drive]/[folder]

Admittedly, I've gone a wee bit overboard on my selection of directories there, but when you have a terabyte size drive to backup to and /home/ is 80-90 per cent of the usage, I prefer to be ultra-safe than sorry.

While progressing through a process such as this, occasionally, a bolt of lightning will strike and a great plan to solve everything with appear. This happened when I stumbled on this discussion on resizing encrypted partitions inside a LVM2 volume. How hard could it be with all the instructions laid out? Very hard, indeed.

At this point, I was kind of glad that the resizing process was a spectacular failure — running Arch with a mounted encrypted drive full of user data sounds like a complete disaster waiting to happen.

Installing Arch

And, so, onto the installation of Arch.


Arch's recently fired curses-based installer.

I was making my way through the various stages of the installer (shown above) without a problem, until I hit stage 8: installation of the bootloader.

One of the first questions that the Arch installer asks is whether you'd prefer to use syslinux or grub as the bootloader, I selected grub. But it turns out that the selected bootloader is not actually installed until after the rest of the system has been downloaded and installed. Normally, this should normally not be an issue, but in the time between downloading my net-install iso version of the Arch installer and now, the powers that be at Arch central had deprecated grub and moved to grub2. Oops, this isn't good.

In a throwback to Gentoo installations of old, and an omen of Arch's future, the problem could be fixed by chrooting into the new Arch install and installing grub2 by hand. User error meant I forgot to run the grub-mkconfig step, which resulted in a new system that refused to boot into Arch on restart. One more chroot and a lot of yelling at oneself later, everything on that front was fine.

However, this wasn't the only issue I had with the installer.

The Arch installer used a curses-based UI that has a rather slow and involved package selection process, and if the installer encounters any issues with a package, such as a failing dependency on totem and sound-juicer, you have to start the lengthy package selection again.

If you haven't picked up on it by now, there's one thing to know about Arch: its documentation is very helpful, but there isn't any hand-holding. For instance, adding a non-root user is done on the command line once the system is up and going — it is not a task completed during installation.

Similarly, I intentionally selected installing only the GNOME packages and not any X server-related packages during the install — just to see what would happen. And true to my choices, the GNOME packages were present on my newly-installed system, but an X-server had to be added to the system to be able to make use of a GUI.

While these "quirks" with the installer aren't showstoppers and are things that an experienced Linux user should be fine dealing with, it's not something I'd recommend novices do.

Knowing what I do now, I would do the absolute minimum to get a working distribution up and going, and install the rest of the packages I needed later, via Arch's package manager pacman.

And it seemed that the Arch team were thinking the same way. Between downloading the Arch net-install media and writing this piece, the installer was completely stripped back into a series of scripts.

After this announcement, I did another install in a virtual machine to see what the differences were.

The worst part is needing to partition the disk on your own, but if you've used fdisk before, there is really no problems to encounter. Given my above problem with the curses UI, I don't mind the change of install process. It's slower, but there is less of a chance to be surprised by failing packages and synchronisation issues.

Using Arch

When a distribution treats you as an advanced user and leaves all the fiddly setting up and tuning of desktop environments to the user, it's going to look ugly out of the box. Arch is no exception.

Much of my time in post-installation has been dedicated to chasing the font dragon. After going through a plethora of packages, I finally settled on using the ttf-ms-win8 package alongside ttf-google-webfonts, and the standard open source collection of Deja Vu and Liberation fonts.

Once I had the fonts in a reasonable condition, Adobe dropped this little piece of brilliance on the world. Now my new machine looks as good, if not far better, than Fedora ever did.

Am I going over the top in my praise of Source Sans Pro? Perhaps I am, but compare the steps to install Source Sans Pro to either of the above mentioned ttf packages.

Since Adobe's font is new, I didn't bother searching for a package for it; I simply downloaded the font family and extracted it to ~/.fonts directory. That's all.

Trying to build ttf-google-webfonts involves syncing with a mercurial repository that is larger than a gigabyte in size. And that, syncing operation always failed for me at around the 50MB mark. To get my hands on Google's fonts, I used this repackaged version and extracted it into the ~/.fonts directory, as well.

To use ttf-ms-fonts, you need to a copy of the Windows 8 Release Preview iso, extract it with 7zip, mount an ~4GB file, extracted from within the iso with wimlib, and then proceed to move the relevant files into the build directory for the package's script. It's a large amount of work to gain a few font ttf files that, to my eye, don't look any better than Adobe's font.

This examination of installing font packages was also a good way to get up to speed with AUR (Arch User Repository).

The reason why Arch users rave about AUR is because it is unbelievably easy to use, and it is as good as they claim. To use AUR, you simply extract the tarball from an AUR package page, build the package with the makepkg command, and install the resultant archive with pacman -U [/path/to/package/file].

It's more involved than simply installing an rpm or deb file for other binary distributions, but it is nice to have a central place for extra packages — at the time of writing, there are over 38,000 packages in AUR.

In fact, it was an AUR package that I tested in a virtual machine that sealed the deal for my move to Arch: a port of Gentoo's etc-update utility for managing changes to configuration files during software updates.

There was a reason that I detailed by backup process of my Fedora install, earlier — because it worked.

By having rsync create a copy of my Fedora home directory within Arch, I easily ported over all my settings, open tabs and bookmarks for my web browsers, playlists and even the size of application windows. I had expected a rather large collection of errors and bugs to appear with this act of amazing laziness, but over a week in, I've had no problems whatsoever.

From my usage so far, there are a number of titbits that deserve highlighting.

Users of mainstream Linux distributions should be aware that Arch makes use of an /etc/rc.conf file, and that services are controlled using the rc.d program — the regular Linux Standards Base Init Scripts will not be found here. Starting a daemon at boot time requires you to add it to an array in the rc.conf file.

If you want vim built with X support, the quickest way to get it is to replace vim with the GVim package. GVim comes with a command-line version, as well as its namesake GUI version.

NetworkManager continues to be unreliable; when using Fedora, I ran into issues with NetworkManager when trying to join some wireless access points. Using Arch, I ran into problems with NetworkManager and IPv6. Rather than nut out the solution to this problem, I once again replaced NetworkManager with wicd and continued on my merry way.

Flash is still a problem. But while Firefox behaves itself in Arch, it is Chrome's open-source cousin Chromium that is having issues with Flash. Continued problems with Flash is one of the reasons why I like to ditch Flash usage wherever possible.

One of the more annoying issues I had with Fedora was pausing from PulseAudio when media players changed tracks — the issue still occurs at times, but its frequency has diminished. This will deserve further probing at a later time.

A new home

The most rewarding part of this change of Linux distribution has been the lack of any severe interruption to workflows or productivity.

It seems faster, but I'm not convinced that that is actually true — I suspect it is a feeling of simply being impressed with a new distribution.

I haven't found myself yearning for a feature found in Fedora that is not provided by Arch in some fashion; full credit to both distributions for being as close to upstream as they are. If I had moved from Ubuntu, it would be quite a different experience, entirely.

Looking back, the operation that took the longest time in this entire distribution change was rsyncing my home directory from the USB backup drive to the laptop's hard drive — and that's to be expected when one is syncing large media files, several DVD-sized isos, and a dozen virtualbox vm instances. It did save a large amount of time in getting the new system to feel like the old one. No lists of GNOME extensions, bookmark export/import or media scanning was needed, because it all came across.

While Arch is not a distribution for newbies, provided that you can handle a dose of fdisk and chrooting, the new installation process isn't as scary as it would seem — if you follow the installation guide. Once up and running, the advantages of AUR will come into play, and you'll be glad to be using Arch.

I can see myself settling in for a long innings with Arch — it reminds me a lot of Gentoo, mixed with a little dose of sanity — and as a long-time Gentoo user, that's high praise.

View the entire installation process, both ways, in our Arch Linux installation gallery.

About

Some would say that it is a long way from software engineering to journalism, others would correctly argue that it is a mere 10 metres according to the floor plan.During his first five years with CBS Interactive, Chris started his journalistic advent...

2 comments
lsatenstein
lsatenstein

First and foremost, it is not always possible to do continuous upgrades, particularly without doing reboots. There are many instances where a new library or module is part of an upgrade, and the module is currently in use with the kernel and some other executables. I have not read anywhere where a kernel option permits dynamically changing from one critical module/library to another. There are other instances where an update to a program obsoletes a library, because a new library is installed to take it's place. And what about those programs you evaluated, decided not to keep, and un-installedt, leaving behind hidden files or even orphaned libraries. So, a clean install, keeping /home and /opt and some other critical setting files does wonders for a) cleaning up diskspace, (while we think that ext4 has no fragmentation, it eventually does begin to scatter modules and files around). b) Dead libraries. c) New code that could not be installed because older libraries could not be removed due to sharing conflicts. The con side of my argument is that Fedora is a distribution that supports previous releases for about 1.5 years. -- not a long time. For longer term support, you have several good choices. a) Centos -- Long term open support of RH linux b) Scientific Linux see Centos c) RedHat's Linux d) Debian and its non-ubuntu derivatives (Linux Mint, etc.) e) Ubuntu f) Other distributions.

zefficace
zefficace

I have tried a bunch of distros, but not a single one has come close to replacing Arch, after installing it 3 years ago. A 3 years old install, yet as fresh a day one, you can't beat that. If you stay out of the testing repo, you will be very stable too. A very good choice for the "capable-of-following-instructions" Linux user.