Posted by Tom Moertel
Wed, 31 Oct 2007 04:35:00 GMT
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.)
Posted in linux
Tags centro, fedora, hotsync, linux, palm, usb
6 comments
no trackbacks
Posted by Tom Moertel
Thu, 07 Jun 2007 04:43:00 GMT
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.
Posted in linux
Tags fedora7, linux
2 comments
no trackbacks
Posted by Tom Moertel
Wed, 09 Aug 2006 04:35:00 GMT
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!
Posted in linux, hardware, sysadmin
Tags fedora, halt, hardware, linux, nut, power, shutdown, ups
2 comments
no trackbacks
readers
