I’ve installed The Chakra Project‘s KDEmod version of KDE4. KDEmod has split packages for KDE, much like Gentoo does.  This appeals to be because there’s a lot of KDE stuff I never use and installing fewer packages means less downloading and upgrading on this dial-up machine.  I’ve installed the minimal set of packages to get a KDE desktop and I’m slowly adding stuff as I see what I want.  This is my first real experience with KDE4, so figuring out what it could do and then what I should install if I want to make it do that is problematic.  I’ve grabbed a Chakra livecd with the full KDE4 to help me figure it out.

With help from hal, the latest xorg stuff is reported to work without a config file for a lot of people.  After installing X, I tried that. X started, but with the wrong resolution, and the system froze with me staring at the lovely twm with clock and xterms.  Now that I think of it, it’s possible I hadn’t yet configured the hal daemon to run at boot, and maybe I forgot to start it.  But I didn’t check that at the time, I just ran nvidia-config.  This time I got a working X, but the wrong resolution again.

I saved the xorg.conf from nvidia-config and then copied my old xorg.conf over from the Slackware install.  That worked fine.  There were a few [EE] errors logged, all just from stuff that’s been deprecated.  After deleting the deprecated stuff from xorg.conf, everything is fine.

At some point, I did get hal all set up (at least I think there aren’t any problems with it), so I’ll try the xorg-without-xorg.conf thing again if I remember.   Update: I did try it again.  The resolution wasn’t right, but I copied the minimal default xorg.conf file from xorg’s log and changed the driver from nv to nvidia and everything worked. I guess I should mention that I have an nVidia 8600GT and an ordinary Logitech wired USB keyboard and wireless USB mouse. From running some xscreensaver hacks, it looks like accelleration is fine, and all of KDE4′s eye candy seems to work. (More on KDE4 later.)

Alsa config went without a hitch. I’m using the Intel HDA on my motherboard. I can’t recall which specific chipset it is, but alsa works fine without worrying about it.

The Arch wiki has good pages for xorg and for alsa, but I really only needed them to make sure I wasn’t forgetting something that would haunt me later.  At some point, I’ll go through the Arch wiki post-installation tips, which looks like a very good checklist of stuff I may want to set up.

I was surprised and happy to find that Arch makes uvesafb easy.  The mkinitcpio tool makes building a new initrd dead simple, and the generic Arch kernel already has uvesafb support.  Better yet, Arch’s klibc has been built against the kernel with support.  I guess the part in which I had to type “v86d” into its configuration file counts as the Arch approach.  I had to re-learn how to pass options to a loading module, but it’s not tough. There’s a slight difference in syntax for uvesafb’s mode option when loading it as a module; instead of mode=, it’s mode_option=. Here’s the set of options that works for me, in /etc/modprobe.d/uvesafb:

options uvesafb mode_option=1600x1200-32 scroll=ywrap mtrr=2

Hmm, I see the Arch-generated comments in that file recommend mode=, which is probably just an oversight due to a recent change in the kernel. The Arch wiki had it right, and of course it’s in the kernel documentation.

After rebooting to see that the framebuffer works, I followed Arch’s clear instructions on setting a console font, and it was all good.  The console font stuff works pretty much the same as in Slack and Gentoo, though the fonts are in a different location.

Then I noticed that the Arch repositories offer a graphical version of links as the links-g package.  I installed that, and now I can see pictures of Dick Cheney as I read the news.  Ain’t life grand?

So far, I’m very impressed with the Arch wiki. I’ve come across a couple of outdated pages, but they were clearly marked. Except for the dial-up without a dialer page I mentioned in my last post, everything I’ve found has worked.

The Arch installer worked fine, with a minor glitch.  The kernel on the Arch installer disk switched the names of my drives, so that what every other kernel calls /dev/sda was /dev/sdb and vice versa.  This caused it to set the root partition in grub incorrectly, but that was easy enough to fix by changing the line from root (hd1,7) to root (hd0,7).

The first hurdle was getting my dial-up connection to work.  The Arch install CD doesn’t contain a dialer app or even a tool to help configure ppp.  The Arch way to make dial-up work didn’t work for me, and there weren’t any helpful log messages to troubleshoot it.  I stuck with it for a day, tweaking it and referring to the ppp options Slackware’s dialer tool had set up for me.  Then I gave up and grabbed wvdial from the Arch repository.  After installing it and running wvdialconf, dial-up works.

Now with a connection to the net, I was ready to sync the package database with Arch’s current one(s) and update the system.  The list of downloads was about half a GiB, so I just generated a list of URLs and fed them to wget on a machine with a broadband connection; this is my plan whenever there’s a lot of downloading to be done.

Bringing the package files back to the Arch machine and then having pacman update the system went fine.  And then pacman wouldn’t work any more.  It turned out that the updating had overwritten a working configuration file with one that doesn’t work.  So I learned that pacman’s handling of new config files is very rudimentary compared to Gentoo’s portage system.  The error pacman gave was “unexpected error”, not much to go on.  Luckily, this Arch forum thread had the problem description and solution.

I’m going to try to document the process of setting up my Arch system as I go, with blog posts;  I’m going slowly, so maybe I can make myself do it.