The last time I redid this page is indicated below, when Arch was up to 0.5. I'm writing this at the end of 2004. Arch is up to 0.7, and my prediction at the end of this article has come true, it's taken off and become quite popular.

This article has been mentioned on their home page, but sigh--it used to be in the docs section, now, of course, being dated, it's in the reviews section. Although much the information is dated hopefully, some new Arch users can find things of value here, and if not, what the heck, it serves as a review. I think that its being moved is also an unspoken tribute to all the ArchLinux users who have put so much time and effort into creating some excellent documentation.

The rest of this page remains as written when Arch was at 0.5.

Arch is a binary, rather than source based, distribution. However, it's quite fast. The base installation is pretty small. It also seems quite stable. Upgrading from gcc-2.x to 3.2 was completely painless. It has a nice package management system that tracks those annoying dependencies quite well.

The documentation is still sparse, as it's relatively new--there is a forum, a mailing list, and even a bug report page but none are very busy. There's also an irc channel.

This purpose of this page is point out a few things that aren't covered in the documentation.

The installation is fairly straightforward--make your partitions if you haven't already, choose your mount points and then select packages. It is specifically suggested by the installer to only install the base at first.) Assuming you have a broadband connection, this is the way to go.

After the packages install, which only takes a few minutes, you then edit /etc/rc.conf and a few other files. I installed it on a box running Gentoo Linux, so I didn't install Lilo, figuring I'd use Gentoo's Grub to boot it.

If you do use Arch's lilo, note that the default configuration has Arch on partition two. If you overlook this, you get that good ole kernel panic on reboot--not only is it annoying but it makes you feel quite stupid for having told people not to do it and doing it yourself--err, at least uh, uh, that's what I hear. So, be sure to note the partitions when editing lilo.conf, obvious though that sounds (it becomes less obvious late at night.) Grub is also available now and seems to automagically choose the correct partition.

Arch uses a package management tool called pacman. It's simple and works quite well. Usually after an install, one wants to upgrade. You might want to first edit /etc/pacman.conf and, if you like, uncomment the section for unstable. This of course, depends upon how daring you are.

The first thing one wants to do after an install is make sure that they have the latest version of pacman so first run

This will upgrade pacman. It will also, at time of writing, replace your pacman.conf with a new one. There are ways around this, which I never remember. The only thing that affected me was that the new pacman.conf had put the # in front of the unstable lines, so I just go back in and remove them again.

The next step is to update the system with the latest packages, so now run

This will update the data base. It'll ask you if you want to upgrade most of the base packages. It will update the system to the most current packages and is surprisingly quick. The use of pacman is covered fairly well in the docs. If you have a broadband connection, you'll be using -Sy more than anything else.

Another important one is

This will search for packages--if you're not sure of a name for example, you can do pacman -Ss xfree and it will show you that what you want is xfree86. Next, we want to run abs, which will, among other things, give us a listing of packages divided by group. So, first we need cvsup.

After it's installed

This will download a list of available packages.

Abs are handy if you want to hack the configuration files. For example, I needed to add Japanese support to rxvt. Go into the abs file, find the application you're looking for, for example, /usr/abs/rxvt and it will have a PKGBUILD file in there. You can open that file, make your changes and then do

This will download the sources and configure the package. Once it's done, you simply add it with pacman. (My rxvt package with Japanese support is now in unofficial as rxvt_ja if anyone is interested).

(The package name would be something like rxvt-2.6.4.pkg.tar.gz) If the package is already installed instead of pacman -A you use

The next issue I ran into was ssh. It's covered in their faq. I'm used to using iptables, however, by default, arch uses /etc/hosts.deny and /etc/hosts.allow. I'd forgotten the syntax--haven't used it in awhile, but changing my /etc/hosts.deny to

let me ssh into the box from my home network (which is a 192.168.1.x network) which is sufficient for the moment. When I start doing more with it, I'll probably go back to iptables, but at this point, that does the trick.

Another one covered in the faq is that you will often find, if you do man something that there are a lot of garbage characters on the screen. To prevent this, in your .bashrc (or whatever--I use zsh so it's in my .zshrc) put

A couple of other small gotchas--although you'll see a kernel being installed during setup, there's no kernel in /usr/src/linux. I just downloaded the latest from kernel.org and did that. Looking on their forums, I see there's a way to add your config so that it can be done as a package, but I find this easier, at least for the moment. As of 0.5 you can custom configure your kernel during installation, but I usually just let it install the default one, which handles my fairly vanilla hardware without problems.

Note that if you do install a custom kernel, and don't pay attention during upgrades, it will be overwritten with any upgraded stock kernel. That is, if you do pacman -Syu and one of the packages is the kernel, it'll simply replace your custom kernel (and overwrite modules.conf).

The workaround is to go into /etc/pacman.conf. Find the line (which is commented out by default) about ignoring packages and put kernel in there. Err, it would help to uncomment it as well

As they are a new distribution, there are still many things that have no package. (However, every time I use an example, in two weeks, they make a package for it, so I've stopped giving an example.)

FreeBSD puts most things in /usr/local/bin. However, that's not part of the default path in arch (Actually, I don't even remember if there was
a /usr/local or if I had to create it.)

One issue that comes up from time to time is libstdc++-libc6.2-2.so.3. Some older programs seem to need that. There's a way of symlinking that sometimes works, but as I always mistype it, I've found it easier to simply grab libstdc and put it where the program is expecting to find it.

For those who need it, I have a bzipped file here.

On irc, it was suggested to me that I put any downloaded programs in /usr/bin rather than /usr/local/bin. As various programs such as fluxbox, ncftp and rxvt for example, go into /usr/local/bin by default, one has to either edit the makefile (which usually has /usr/local in the first few lines) to read /usr or, when there is a configuration file just do ./configure --prefix=/usr. (Although both fluxbox and rxvt are available as packages, I did both from source--fluxbox, because I like to add in the Gentoo patch that allows you to bind keystrokes to the RootMenu as mentioned on my fluxbox page and rxvt because I wanted to put in Japanese support. After some correspondence with the fluxbox package's maintainer, Arch is the only distro I know of besides Gentoo that now includes Mr. Kita's very handy RootMenu patch)

Arch, rather than using /usr/local uses /opt. I'm not a big fan of /opt, for no particular reason save perhaps, habits formed with Gentoo and FreeBSD, but it's easy enough to change. (If you're reading this and don't know how to change it, then I'm going to assume that you have no real reason to do so--as I said, it's simply a matter of taste, and I'm used to /usr/local/)

You might also want to edit your /etc/vimrc file--the default in there has some autoindenting that I didn't like as well as making a backup of anything you're working on. They have some if else statements there to decide, but as I was in a hurry, I just changed all instances of backup to nobackup and autoindent to noautoindent, which did the trick. (Or, you can simply rename the /etc/vimrc file to something else.)

It's worth mentioning that although Arch doesn't have the selection of packages that are found in say, Gentoo, they are almost always thoroughly tested and work quite well. OpenOffice, which seems to cause trouble in many distributions, for instance, although they're using the 1.1 beta went in and worked without a hitch.

It is fast becoming a distribution where everything "just works." For example, install mozilla-firebird and the flash plugin, go to a page using flash, and it's working. Java still requires a bit of tinkering however. This is covered in the forums. Assuming you have mozilla-firebird installed

cd
mkdir -p ~/.mozilla-firebird/plugins
cd ~/.mozilla-firebird/plugins
ln -s /opt/j2sdk/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so

Once that's done, java works perfectly. If, for some reason, flash isn't working then

ln -s /opt/mozilla/lib/mozilla/plugins/*               

will fix it.

There were a few glitches with one of the firefox and flashplugin upgrades. If flashplugin was installed first, then the firefox upgrade, it stopped working. Various solutions work, but I found that installing firefox first, then flash, solved the problem. When I did this, at first I got an error message from pacman, saying there was a conflict as /opt/mozilla-firefox/lib/mozilla/plugins already had libflashplayer.so and flashplayer.xpt. I removed those two files. It then installed and everything worked. Opera's a little bit harder at present. At time of writing, January 2004 there isn't a package for it. So, first download and install it from opera.com and install it. Then, go into opera's preferences. For the java path (under multimedia) use /opt/j2sdk/jre/lib/i386 and java should then work. For flash, assuming you've installed it under mozilla-firebird, first you need the package lesstif.

pacman -Sy lesstif

Then, copy over the plugin.

cp /opt/mozilla/lib/mozilla/plugins/* /usr/lib/opera/plugins/

(This is assuming you installed opera and went with the defaults. You can check the plugin path in their preferences section)

(Actually, with a recent flashplugin update, as of Feb. 20th, I had a different problem, flash simply wasn't working in opera's beta version. This one was solved when I posted the problem on the forums, though the opera beta isn't an Arch package. One possible cause, that missing stdc library (mentioned above) When I put it in /usr/lib, flash began working again in opera.

The last issue is sound. As I said, I compile my own kernel and put my sound card in there, as opposed to using a module--also, I always forget what the alias is supposed to be and get tired of looking it up to see if it's snd-slot, or whatever. (Module aliases are, as they are in many distros, in /etc/modules.conf). Arch uses devfs, so one also has to edit /etc/devfsd.conf. There are various suggestions (other folks simply do a chmod on /dev/dsp in /etc/rc.local) but I simply added these lines to devfsd.conf. (Again, you can check the forums for this and see how different people do it.)

REGISTER sound/.*  PERMISSIONS root.users 0660

This works for me. Others prefer to create a group called sndusers or audio, but I'm fairly lazy as you might have noticed. Another gotcha that I only noticed in 0.5 is that the updatedb command wasn't working. The problem's solution is mentioned on the the forums. As root or with root privilege

This fixed that problem for me.

none    /dev/pts    devpts     defaults   0   0

This was mentioned on their forums. I'm not sure if it applies to any other Linux distro that uses devfs, as I've only, at time of writing, put in 2.6 with Arch and Slack. (However, since then, a friend has mentioned that it does apply to other distros using devfs)

For those who are lazy, Arch now provides a 2.6 kernel.

pacman -Sy kernel26

Once the kernel is installed, you'll have to change your lilo or grub to point to vmlinuz26. (You'll note, after installing the kernel, that there will now be a vmlinuz and a vimlinuz26 in boot.)

Also, although not Arch specific, might as well mention the problems I had getting framebuffer to work with an LCD monitor. After a good deal of experimentation, on two machines, one with a Voodoo5 card and the other with a Matrox Millenium G400 I found the following settings work. Note that (again, after experimentation) I found that I was best off ignoring all the matrox and Voodoo options in the kernel. I also found that the video=matrox blah blah wasn't necessary.

These are the options I use in the 2.6 kernel to get a console screen that I consider reasonable, 1024x768 I believe.

In Device Drivers, go to Graphics. Choose Support for frame buffer devices and VESA VGA graphics support. Don't choose the 16-color graphics support.

Then, go to Console display driver support and from its menu choose

Video mode selection support
Framebuffer Console support
Select compiled-in fonts

Then choose the first two, VGA 8x8 and 8x16

Then, in your LILO or GRUB config files add

vga=791

to the proper line. Not sure where it is in LILO, in GRUB it's in the the kernel line, the one that reads something like kernel /boot/vmlinuz

There may be better ways to do it, but this is what worked for me.

Anyway, those are the gotchas that I had--yours of course, may be different.

Arch is a nice distro and it wouldn't surprise me if it took off in the way that Gentoo did.