Tom Moertel's Weblog: Category linux

How to hotsync the Palm Centro with a Fedora 7 Linux desktop via USB

Tom Moertel — Wed, 31 Oct 2007 00:35:00 -0400

I just got a Palm Centro smartphone, and I love it. Getting it to sync with my Linux workstation, however, was tricky, so I’m posting this recipe in hopes that it might save you some time.

The “visor” kernel driver is supposed to make compatible Palm handhelds look like serial devices when attached via a USB cable. For me, it didn’t work. Instead, I had to blacklist the driver and then use libusb to talk to the Centro. Here’s the recipe:

First, blacklist the “visor” kernel driver:

# echo blacklist visor >> /etc/modprobe.conf
# modprobe -qr visor

Second, make sure libusb is installed:

# yum install libusb

Third, edit the system’s udev rules to make sure your user account can access the device files used to talk to the Centro. On my Fedora 7 setup, I found the right rule in /etc/udev/rules.d/50-udev.rules:

ACTION=="add", SUBSYSTEM=="usb_endpoint", \
ATTR{bEndpointAddress}=="?*", ATTRS{devnum}=="?*", ATTRS{busnum}=="?*", \
NAME="bus/usb/$attr{busnum}/$attr{devnum}_ep/$attr{bEndpointAddress}", \
MODE="0644", SYMLINK+="%k"

I edited the last line of the rule, changing the mode to 0664 and adding a GROUP key to assign the Centro devices to my exclusive user group:

MODE="0664", SYMLINK+="%k", GROUP="thor"

This change lets my account talk to the Centro without having to take on root privileges. (For bonus points you could set up a more-specific rule to match just your Centro. The rule above, as is, will actually match other devices, too.)

Fourth, tell udev to reload the rules:

# udevcontrol reload_rules

Finally, set up a Palm-device connection via gnome-pilot. Be sure to select USB for the Type and “usb:” from the Device drop-down list.

That’s it. If you’re lucky like me, you should now be ready to hotsync your Palm Centro!

Update: Even better, this handy HOWTO shows you to sync via Bluetooth, which is more convenient than hooking up a USB cable. I’m now using this method.

Update 2: If you want to use USB to hotsync your Centro, there is a method that’s more convenient than setting up udev rules. Just create a perms file for pam_console_apply that tells it to give the console user permission to access your Centro. To do so, create a file /etc/security/console.perms.d/60-libpisock.perms and put the following in it:

<libpisock>=/dev/usbdev* /dev/bus/usb/[0-9]*/[0-9]*
<console> 0644 <libpisock> 0644 root

That’s it. (You’ll still need to use libusb.)

My upgrade to Fedora 7: rocky start but great finish

Tom Moertel — Thu, 07 Jun 2007 00:43:00 -0400

Tonight I upgraded my main workstation from Fedora Core 6 to Fedora 7. The result is an impressively polished working environment. Everything is snappy and crisp. I love it. Kudos to the Fedora team!

Getting Fedora 7 to boot, however, took some doing.

After the upgrade, my workstation rebooted – and then hung. The problem was that the raid456 module wasn’t getting loaded by the kernel, and thus the kernel couldn’t detect my RAID-5 root filesystem, and thus Halt.

Interestingly, the corresponding error in the kernel boot log said that the module couldn’t be loaded because it existed:

error inserting /lib/raid456.ko: file exists

What’s the problem? The file is there, isn’t it? You just said so!

Booting into the install DVD’s rescue mode (very handy), I ran mkinitrd by hand to rebuild the initial disk image that primes the kernel with the modules it needs to boot the system. (An older version of mkinitrd would sometimes forget to add the raid456 module to the image, so I figured maybe that’s what the cryptic error message was hinting at.) I added the -v flag to the command line to see what was really going on and caught this interesting tidbit:

# kver=`uname -r`
# mkinitrd -v -f /boot/initrd-$kver.img $kver

...
Adding module ext3
Adding module xor
Adding module raid456
Adding module raid456   <<== FLAMIN' MONKEY EYES TIMES TWO!
Adding module scsi_mod
Adding module sd_mod
...

The raid456 module was, for some reason, being added to the image twice. That redundancy, I reasoned, is what caused the cryptic error message in the boot log. The module couldn’t be inserted because it already existed! That theory approximately made sense, so I ran with it.

Thus I had to edit the code for mkinitrd to prevent it from trying to add the module twice. Then I used my adjusted version of the tool to rebuild the initial disk image. Finally, I rebooted the system and – with fingers crossed for luck – entered the glorious world of Fedora 7.

Almost. Neither the nv nor the nouveau driver for X.Org X11 detected the true geometry of my Dell 2001FP monitor. So I had to slink back to the non-free nVidia driver to get my full resolution back.

Those two issues aside, the whole process was delightful.

And, now that I’m using Fedora 7, it’s rockin’. Just what my workstation needed.

New Fedora Core RPMS for CRAN packages arm, Matrix, lme4, car, coda, leaps, and mlmRev

Tom Moertel — Wed, 25 Apr 2007 14:07:00 -0400

Just a quick note for folks using the R statistics system on Fedora Linux. I have packaged for Fedora a bunch of R packages from the CRAN. (R packages have to be packaged again, as RPM packages, to integrate with Fedora Linux.)

My initial goal was to package arm, which contains tools for working with various regression models. (This package accompanies Andrew Gelman and Jennifer Hill’s wonderful book Data Analysis Using Regression and Multilevel/Hierarchical Models.) Packaging “arm,” however, quickly snowballed into packaging a bunch of prerequisites. Thankfully, I have now completed that task and can share the fruits of my labor with you.

All in all, to install “arm,” you will need the following RPMs:

R-arm-1.0-2
R-car-1.2-1
R-lme4-0.9975-1
R-Matrix-0.9975-1
R-R2WinBUGS-2.0-1

The following RPMs are optional (but you will need them if you want to rebuild the RPMs):

R-coda-0.10-1
R-leaps-2.7-1
R-mlmRev-0.995-1

You can download the packages from the RPMs section of the Community Projects site. Better yet, you can use Yum to download them for you. Just add the moertel-community Yum repository to your /etc/yum.repos.d directory (see RPMs for the recipe) and then use the following command:

$ sudo yum install R-arm

Yum will automatically resolve dependencies and install the required packages. If you want any of the optional packages, add them after “R-arm” on the command line.

I have built the packages for Fedora Core 6 on the x86_64 architecture, but the RPM specs are available if you want to rebuild the packages for other architectures. (See the instructions for rebuilding RPMs for help.)

Caveat: I’m not sure that the R-R2WinBUGS package is fully functional. It depends on BRugs, which doesn’t yet build on the Linux platform. To get around this problem, I made R-R2WinBUGS’s dependency on BRugs weak; the first package no longer requires the second to install.

How to make sure your servers come back up after an extended power outage

Tom Moertel — Wed, 09 Aug 2006 00:35:00 -0400

If an extended power outage drains your UPS, and your servers are forced to shut down, will they automatically start up again when the power is eventually restored? It’s a good question, especially if your servers are in some distant, unattended server room. Unless you’ve tested your servers, don’t assume that the answer is Yes.

Many servers offer a BIOS configuration option that forces them to automatically power on when they receive line voltage. If your servers have this option, just set it and you’re done.

Unfortunately, some servers, including a Dell PowerEdge 1600SC that I’m using, lack this configuration option. When these servers turn themselves off as the final step of a UPS-controlled shutdown, they don’t start up again when the power is restored. Because they were shut down before the power was cut off, they think they are supposed to remain off when the power is restored. That is, they remember their on/off status across power outages.

Fortunately, there is a way to make sure these servers automatically power on: shut them down without powering them off; halt them instead. That way, when the UPS finally cuts off the supply voltage, the servers will still be in their “on” state, and they will remember this state across the outage. Later, when the power is restored, the servers will automatically restore their pre-outage state and power up.

With Fedora Core Linux and Network UPS Tools, it’s not difficult to make sure the servers are halted instead of powered off, but the implementation isn’t obvious. To spare you the digging, here are the important bits.

When the power fails and the UPS-monitoring software decides that the batteries are almost depleted, it will initiate a server shutdown using the command defined in the /etc/ups/upsmon.conf file. The default command is this:
```
SHUTDOWNCMD "/sbin/shutdown -h +0" 
```
The shutdown command will tell the init process to enter runlevel 0, which is the prepare-to-halt-the-system runlevel.
The init process will stop all of the running services in an orderly fashion, and then, as the last step, invoke the final script in the shutdown process: /etc/rc.d/rc0.d/S01halt.
The final lines of the S01halt script will power off the server. Unless, that is, the file /halt is present, in which case the script will halt the server instead.

Thus the trick is to make sure that the /halt file does exist. The trick turns out to be easy to pull off; just redefine the shutdown command in /etc/ups/upsmon.conf:

SHUTDOWNCMD "/bin/touch /halt; /sbin/shutdown -h +0"

And that’s all there is to it!

Linux just works

Tom Moertel — Wed, 02 Nov 2005 11:50:00 -0500

Sam Ruby writes about his overall experience with Ubuntu Linux in contrast with Microsoft Windows in It Just Works:

Convenience. Security. Predictability. More options. Less hassle. I like that.

That’s exactly why I switched to Linux, too.

In April 2004, my main Win2k workstation’s hard drive failed. When the replacement hard drive arrived, I tried to reinstall Win2k from the original installation CD. I failed. The CD, from 1999, contained an out-of-date version of Win2k that no longer could recognize my computer’s hardware. But, because of Microsoft’s licensing terms, I was required to reinstall from that CD (the one tied to my CD Key and Certificate of Authenticity).

I kept a log of the re-installation process, and it’s not pretty. I wasted five hours trying to re-install Win2k before giving up.

Then I installed Fedora Core Linux. It took about thirty minutes, was painless, and mostly occurred automatically – while I was walking my dog. It just worked.

Today, I am writing this post on the very same workstation, happily running Fedora Core Linux 4. It just works. And I love it.

I don’t miss Windows. And I certainly don’t miss having to jump through licensing-scheme hoops. Instead, I can focus on getting my work done.

It’s a great feeling, being able to do my work on my own terms. I don’t think I’ll ever go back.