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.

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.

Well, after I learned the Slackware way to update the shared library cache, fillet’s ./configure still couldn’t find lua. Luckily, ./configure --help told me I could use --with-lua=[path] to point it to the right directory, and that seemed to work. Not so luckily, make failed, telling me that it cannot find -llualib.

Googling that error turned up very few hits, but ones with some clues. This thread made me think I might be able to get by with tweaking the makefile. Since I didn’t really know what I was doing, I wasn’t too surprised when monkeying with the makefile didn’t help.

Then I saw that Mike Frysinger of Gentoo had submitted some patches to fillet’s build system so that it would work better with newer luas. I thought maybe the fillet folks hadn’t put out a tarball since then, but checking the source I had (version 0.7.4), I found Frysinger’s patches included already. I still thought they might have clues to my troubles, so I stared at them for a while; this did nothing but give me a headache. I don’t understand much about the GNU build system, and I should stop pretending.

At this point, I was ready to give up, get some sleep, and post questions about what to do after some coffee in the morning. But as I was closing Firefox tabs, I saw I still had slacky.it open, and slacky it has Lua 5.0 for Slackware 12 as well as the Lua 5.1.2 I had grabbed. After downgrading Lua, compile of Fish Fillets went flawlessly, so I went to sleep happy.

I got it running more-or-less ok using this howto posting as a guide. Without GNOME, it’s very difficult and frustrating to tweak the Compiz settings. The configuration files live sensibly enough in ~/.compiz/options/, but what goes in them is nowhere documented on the Compiz website or anywhere else I can find. The only clue is that the options have the same names in these configuration files as they do in gconf. That’s great to know, and there are some screenshots of gconf around, but without actually having gconf it’s rather annoying to try to figure out how to tweak the settings.

I don’t much care about the wobbly windows effects, though I’ll keep them now that I’ve figured out how to damp their springiness. But I can’t seem to make windows snap to each other or to the edges of the screen. I can make the skydome work, but I cannot use my own image for it. I’m in this for a few of features of Compiz that make desktop navigation easier, mainly the Exposé-like thingy, but as long as I’m at it I’ll be bugged by eye-candy features I can’t make work as they should.

I guess I’ll end up tweaking Compiz until it’s the way I want it, but this would be so so much easier if there were just a freaking man page to look at. I have now looked at a multitude of web forums for various distros, none of which are very specific about which version of Compiz is being discussed. I hate web forums, but that’s another rant.

BTW, on my Gentoo laptop, I don’t use Compiz because the glx module it needs to work with the laptop’s Intel video chips won’t survive suspending to hard disk. So, to use Compiz, I’d have to restart X after suspending, which would do away with the time saved by suspending in the first place. I tried Komposé, but no matter how I configured it, I took an unacceptable performance hit.

The 1020 needs the foo2zjs driver written by Rick Richardson. It’s a little more complicated than most printer setups, because the 1020 doesn’t retain its firmware if it’s powered down; the firmware has to be reloaded each time. Mr. Richardson has put together a nice source package and great instructions that Just Work. On my laptop, I use Gentoo’s ebuild of foo2zjs even though he recommends against it. For Slackware, I compiled it and installed using his great instructions.

The source tarball comes with no configure script; you start by running make to compile foo2zjs. Then to get the firmware and some other needed stuff, he has provided a nice script. ./getweb 1020 grabbed what was needed from his website. After that, make install puts the object files where they need to be.

At this point, Mr. Richardson’s job should be done, but he’s gone a couple of extra miles. He’s written udev rules to load the firmware whenever the printer is plugged in, and he’s provided a script to put them into udev’s config directory. Not only that, he’s provided a script to restart the cups daemon so that it will see the new printer.

Thanks to his work, after downloading, it took me about three minutes to go from compiling to printing a test page.

The screenshot shows part of the basket. As you can see by the checkmark, I’ve already taken care of the aliases. Other features visible are the progress meter by “Claws stuff” and the links. It’s nice to be able to associate the links needed for a task together. Links to files can also be attached, as well as application launchers. There are many more features — no brief description can do it justice.

If you think you might want something to help you organize, well, just about anything, IMO you should check out BasKet’s web site and give it a try.

In the time it’s taken me to type this and learn how to put a screenshot in a blog entry, I could have knocked out most of the list. So, bye for now.

ps: I used the installation script included in the download from BasKet’s website, and it has a couple of quirks. It prompts for root password when what it actually needs is whatever password the current user would use with sudo. And for some reason, the script installs it to /usr/bin instead of /usr/local/bin.