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.

The 2008 Pricelessware CDs have recently been put together, and getting that word out is the reason for this post.  (The blogotubes’ search thingies pick up even my little corner of what I understand is some kind of sphere.)  I host the CD images, so you can download the Pricelessware CDs from this site or you can read more about them and see other download options at the Pricelessware site.

export PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] "

which results in a prompt that looks like this:

Ouch, that looks much better in the middle of a console than it does against the white background of my blog. Oh, well.

For root’s prompt, I use a bright yellow hash prompt that reminds me to be careful. I also don’t display the working directory; if I’m root I’ve already made sure I know where I am.

export "PS1=\[\033[01;31m\]\h\[\033[01;34m\] \W \[\033[01;33m\]\\$\[\033[00m\] "

Then I remembered seeing an install script at SlackBuilds.org for it.  Five minutes later, all was good.  I love that site.  While I’m plugging it, I’ll mention that I had a little trouble with their script for the backgammon game gnubg;  I got a version of gnubg without 3D board support.  Within minutes of posting a build log to their mailing list, the script maintainer got back to me, saying that I was missing the package that adds gl support for gtk and that he’d forgotten to list it as an optional dependency.  Again, five minutes later I had everything recompiled and working perfectly.  Those people are good!

Update: I gave up on the approach below and solved the problem by modifying the kdeeject script per comment 13 in this Gentoo bug report.  This seems a lot better than screwing with the device’s permissions.

The only actual problem I have, and it’s really just an annoyance, is with KDE’s option to “safely remove device” for USB drives. That option uses eject instead of just umount. That’s fine, as eject works on my USB drives as long as the user has enough permission.

The problem arises because of default udev rules that make the owner of the device root:disk, and the user isn’t in the disk group. eject calls umount, so the device is unmounted, and no harm is done. But eject exits with error code 1, so KDE throws up an error window (along with its lovely breaking glass sound).

Two solutions mentioned on the intertron are to patch the KDE component which handles “safely remove” or to modify a script KDE uses. The third solution, which I would like to use, is just to write a new udev rule to make sure the device is owned by root:plugdev (and of course the user should be in the plugdev group). I’ve done this for just the WD drive which has the problem, but a rule can be written to handle all removable storage. The rule has to be processed after the default udev rules handling block devices.

That’s a pretty good rundown of my understanding of the problem, but something is lacking in my understanding, because that solution doesn’t work under Slackware. It does work under Gentoo, where I had the same problem.

I’m in the plugdev group, and here are the drive’s permissions:

$ ls -l /dev/bigpassport
brw-rw---- 1 root plugdev 8, 17 2008-05-13 17:50 /dev/bigpassport

I still think it’s a permissions problem, since eject does work when run as root. Here’s the eject output, with the drive mounted first, for user:

$ eject -v bigpassport; echo "exit code $?"
eject: device name is `bigpassport'
eject: expanded name is `/dev/bigpassport'
eject: `/dev/bigpassport' is mounted at `/media/bigpassport'
eject: unmounting device `/dev/bigpassport' from `/media/bigpassport'
eject: `/dev/bigpassport' is not a multipartition device
eject: trying to eject `/dev/bigpassport' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/bigpassport' using SCSI commands
eject: SCSI eject failed
eject: trying to eject `/dev/bigpassport' using floppy eject command
eject: floppy eject command failed
eject: trying to eject `/dev/bigpassport' using tape offline command
eject: tape offline command failed
eject: unable to eject, last error: Invalid argument
exit code 1

And for root:

# eject -v bigpassport; echo exit code "$?"
eject: device name is `bigpassport'
eject: expanded name is `/dev/bigpassport'
eject: `/dev/bigpassport' is mounted at `/media/bigpassport'
eject: unmounting device `/dev/bigpassport' from `/media/bigpassport'
eject: `/dev/bigpassport' is not a multipartition device
eject: trying to eject `/dev/bigpassport' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/bigpassport' using SCSI commands
eject: SCSI eject succeeded
exit code 0

I have a Logitech wireless USB mouse. Mousewheel scrolling didn’t work out of the box, but changing the protocol to “IMPS/2″ and addingOption "ZAxisMapping" "4 5" fixed that.

I used GIMP to make a grub splash image. It looks pretty rough when stretched to fit the 20 inch monitor, but my rudimentary graphics skills aren’t up to making something pretty.  Anyway, it works with the grub from System Rescue CD.

Installing the driver for the HP 1020 went just as smoothly as before.

That’s enough tinkering with Slackware for today.  Now I’ll switch to installing the ridiculous number of Firefox extensions I use.

Now, of course, I’m kicking myself. I’ve just installed Slackware 12.1 and am beginning to put back into place the stuff I want or need. And this time I’m going to try to document a lot of it here, if only so I can find it again if I need it. There are some things I do to any GNU/Linux install, and I forget the details of how to do them — I’m hoping if I put them here, I can save myself some re-re-re-googling down the line.

So far, I’ve just installed it and the grub bootloader. The Slackware way is to use lilo instead of grub, but I really prefer grub. Slackware does provide a build of grub, but that’s not much use before Slack is bootable. I use System Rescue CD to install grub; it’s a Gentoo livecd with some good tools, and I’m most comfortable with Gentoo. The stage files grub needs aren’t in the cd’s /usr/share/, but it’s easy enough to copy them from /boot/. Then the grub commands I needed were just root (hd0,4) and then setup (hd0,4).

I couldn’t recall what parameters need to be passed to a Slack kernel, but it turned out that just using kernel (hd0,0)/boot/[kernelfilename] root=/dev/sda7 ro works ok. Later (much later), I’ll at least get framebuffer goodness and maybe a grubsplash. And compile a slimmer kernel — for now, I’m using the huge-smp one.

The desktop only has dial-up, and once again Slackware’s pppsetup works fine to get a connection. I also set up kppp without problems.

I’d forgotten how annoying KDE’s sound scheme is. I turned it all off immediately.

Next up: nVidia drivers and xorg config, udev rules for USB drives.