Posted by Tom Moertel
Sun, 05 Jul 2009 16:42:00 GMT
It seems that every time I upgrade Fedora on one of my workstations,
anaconda somehow manages to screw up the bootloader configuration,
and when the upgrade is “complete” and the system reboots, I’m
left starting at a GRUB prompt. So this is a little note to myself
for how to fix the broken configuration. (If you find my note helpful, great, but if you try anything in it, you do so at your own risk.)
First, find out where GRUB thinks the /boot partition is:
grub> find /grub/grub.conf
find /grub/grub.conf
(hd0,0)
(hd1,0)
Here, GRUB found two potential /boot partitions, which is actually
correct because I keep /boot on a RAID-1 md device and GRUB is
finding the device’s underlying partitions.
Next, tell GRUB to use the desired /boot partition as its root device:
grub> root (hd0,0)
root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
Finally, tell GRUB to set itself up on the hard drive that contains the partition (which, for my workstations, is the correct place):
grub> setup (hd0)
That’s it, all done.
At this point, you can tell GRUB to “boot” using the configuration or “reboot” from scratch to test the configuration from a system restart.
Posted in linux
Tags fedora, grub, linux, note, self, sysadmin, to
1 comment
no trackbacks
Posted by Tom Moertel
Wed, 04 Feb 2009 04:45:00 GMT
After reading about the ordeal a paying customer went through attempting to
get Adobe to fix a simple
mistake, I
was reminded of why I lost my faith in proprietary software. After a
bad experience reinstalling
Win2k, it
dawned upon me that software vendors could waste my time, make me jump
through hoops, and sell me barely functional crap, and all I could do,
as a paying customer with a valid license, was take it.
This poor guy, for example, ordered a Mac OS X version of Flash CS3
and got sent a Windows version by mistake. Not his fault. But he’s
the guy who ended up wasting weeks fighting Adobe’s ineffective
customer support trying to get what he paid for in the first place.
This guy is a paying customer. He paid for that treatment.
Look, folks, the world of open source isn’t perfect, but it’s better
than that. Since dumping Windows for Linux, here’s how much
time I’ve wasted on stupid vendor hoop-jumping: None. Nada. Zero.
In the world of open source, you never have to worry about getting
stuck with the wrong version of software. That’s because you are
always free to download the right version. No need to ask for vendor
approval, fax in your “Letter of Destruction”, or wait for an
activation code. You just type in “yum install whatever”, the software installs, and you go back to work. That’s it.
Until I switched to the open-source lifestyle, I never realized how
much time (and blood and sweat) I had wasted on the side effects of
proprietary software. If you’re still in the proprietary world, take
a moment to consider how much time you have wasted and how much time
you will waste in the next few years on stupid vendor crap. Maybe
it’s time to stop jumping through hoops. Maybe it’s worth your while
to give open source a shot.
Go ahead, grab a Fedora Live
CD and test drive it for a few
days. What have you got to lose but a world of hurt?
Posted in rants
Tags adobe, fedora, freedom, linux, proprietary
22 comments
no trackbacks
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
4 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
Posted by Tom Moertel
Fri, 17 Feb 2006 07:23:00 GMT
Tonight while building a new workstation, I needed to update the BIOS
on the motherboard, a Tyan Tomcat
K8E. Tyan, however,
offers only floppy-based BIOS flashing software to do the job. Worse,
the software requires me to boot into DOS first, using a DOS boot
floppy that is neither provided nor lying around the office (I’m
a Linux guy).
One more thing: it turns out that my new floppy drive is junk.
Thus we arrive at tonight’s problem: If you do not have a floppy drive, how can you flash a motherboard’s BIOS when its manufacturer provides only a DOS-floppy-based BIOS flasher?
Fortunately, the problem can be solved. In case you ever need
the solution, here it is.
Disclaimer: This recipe worked fine for me, but might not for you. If you follow these instructions, you do so at your own risk and assume all responsibility for whatever happens, even if your computer catches on fire or your pants explode. You have been warned.
First, download a bootable floppy image from the FreeDOS
Project. The one you want is the 2.88-MB
ODIN image because it has
about 1.5 MB of free space, enough to hold the contents of the BIOS
flasher’s floppy.
Second, mount the floppy image so that you can edit it:
mkdir /tmp/image
mount -o loop /path/to/odin2880.img /tmp/image
Third, copy the BIOS flasher and associated files into the mounted
floppy image. I just unziped Tyan’s archive directly into
the image:
unzip /tmp/tyan_2865_301.zip -d /tmp/image
Fourth, unmount the image.
umount -d /tmp/image
Fifth, create a bootable CD-ROM from the floppy image.
cd /tmp
mkdir boot_cd
mv /path/to/odin2880.img boot_cd
mkisofs -o odin-cdrom.img -b odin2880.img -c boot.catalog boot_cd
cdrecord -v -eject odin-cdrom.img
Finally, reboot your PC using the CD-ROM and flash away! (Note: If FreeDOS asks, you don’t want to use extended memory or anything like that because BIOS flashers don’t like it. You want old 8086-style
unprotected memory.)
Update 2011-03-03. For a somewhat more up-to-date recipe that also lets you boot your
BIOS updater across the network see:
How to update your server’s BIOS across the network.
Update 2011-02-12. It looks like the link I gave to the ODIN image is now dead. Instead, try the BALDER image.
Posted in hardware, hacks
Tags freedos, hacks, linux, sysadmin
no comments
no trackbacks
