Tonight is quick tips night on darky’s web log.
The differences between the Asus A7M-266 and A7V-266-E seem to be:
A7M has AMD chipset, A7V has VIA.
A7V has more DIMM slots.
A7V may have more PCI slots. (I can’t remember; count them.)
A7V (at least the particular model mentioned above) has four IDE channels on-board: two regular ATA/100 (I think) and two channels that are attached to an on-board Promise chipset which can apparently be run in either Ultra/100 or FastTrak/100 (RAID) mode. Check jumper on motherboard for details.
I got lots of “hdX: lost interrupt” messages when booting the RH8
install CD in my new machine with three Highpoint Technologies HPT302
cards, otherwise known as the Rocket133 cards. Apparently the
solution to this is to go get the latest Rocket133 drivers from
Highpoint. Get
the non-open source ones, follow the instructions in the enclosed
PDF. You basically have to supply parameters like hdX=noprobe to
the kernel from SYSLINUX to keep the kernel from toying with the
HPT302 controllers. Then you use their drivers disk. If you want to
upgrade the kernel in RH8.0 (or other versions, probably) go get the
open source drivers from the page above and follow the directions for
building them. Note that the open source drivers aren’t really open
source, but kind of a wrapper for some library they provide only as a
binary. The result of this, when using it with RH8.0, is that the
driver won’t load because their library was compiled with GCC 2, but
the RH kernel was compiled with GCC 3. Easiest thing to do: vi -b
hpt302lib.o, %s/gcc2_compiled/gcc3_compiled/g, :wq, then
build the driver. When you’ve got a working driver for your new
kernel, install it in
/lib/modules/KERNEL-VERSION/kernel/drivers/scsi/ and don’t forget
to mkinitrd if you need it. I’ll take this time to mention that I
have no idea if the GCC 2/GCC 3 thing I did above is a good idea at
all — I suspect strongly it isn’t — but so far it’s working for me.
Hooray for binary drivers!
Much to my dismay, you apparently can resize a RAID 5 device; i.e.,
expand my new RAID 5 pr0n array. You need
raidreconf. While
the author warns that it’s untested, and I am forced to concur
(backup!), I will say that I have not read of any tales of
raidreconf screwing up disks, and I have read at least a handful
of success stories. Google for yourself if you don’t trust me. (I
wouldn’t.)
Originally, to provide for expandability of my array in the future, I
was going to seal it in LVM and call it a day. I was pleased to learn
that RH8 ships with LVM. Then I found out that LVM doesn’t do RAID
5. Indeed, LVM leaves that up to the MD layer. At the time I was
under the impression that there was no way to resize an MD (software
RAID 5, specifically) device. So I found EVMS.
It looked cool, but was very ambiguous about whether it allowed for
resizing of a RAID 5 array. Then I went and found that the EVMS
people, after not being included in 2.5 before the feature freeze,
have kind of abandoned most of their kernel work from the sound of
it. Instead they seem to be focusing on some integration work with
the facilities that did make it in to 2.5 (LVM2, which seems to be
more of a wrapper around something called DM, or “device manager”).
So EVMS would require me to turn off the MD stuff in the kernel (per
their documentation, not sure if this is strictly true though), a
kernel rebuild with some stuff that may or may not be stable (probably
stable), and still might leave me without being able to do what I
want? Nah. Not if I can find something better. That’s when I found
raidreconf. Usenet and Google saves all.
I spent most of the day today setting up my new file server. It might
do more than just serve files in the future, but for now it’s just got
5x120GB drives, 3xHPT302 cards, and a willingness to serve. (Pun
intended.) I’m going to seal up the software RAID 5 device in an LVM
VG, so just in case things don’t work out with raidreconf for some
reason in the future, I can still make another separate RAID 5 array
and (theoretically) just extend the VG. Maximum VG size seems to be
2TB. Bummer? BTW, there is a utility that apparently only exists in
LVM2 called pvresize (physical volume resize) which I’d need to
use if I actually used raidreconf to extend a RAID device that was
part of a VG. However, from posts made by the person whom I believe
to be the author of pvresize, that migration from LVM1 to LVM2 is
smooth, and additionally pvresize can supposedly be built for and
work with LVM1. Hooray.
Another debate I’m presently having with the configuration of this box is whether to use ordered or writeback journal mode in ext3. I might try both and play with bonnie a bit to see if there’s some huge difference, but I suspect I won’t notice one in day-to-day use and will end up in ordered mode. Right now, though, the MD device decided it needs to resync, so I’m leaving it to its business. Maybe bonnie++ in the morning.
Worked on getting RT set up last night. It went pretty much as they described, except for that horrible problem with HTML::Mason (or with that version of HTML::Mason and RT, at least; I’m not at all convinced the problem is HTML::Mason’s). I’m using MySQL to back it, though it supposedly works with both PostgreSQL and Oracle as well. This is part of our evaluation of ticketing systems to be used at work, but I suspect we’re going to end up staying with RT unless it’s found unsuitable… or if something more suitable/featureful with a similarly clean code base and agreeable license (free) is found. (RT supposedly has a very clean design and is easily extendable/modifiable. I’ve seen some evidence of this in users writing add-ons and such, I think.)