2007-05-13

MY ASUS P5B Deluxe Linux (Slackware 11.0) settings

Putting this here so that, if I ever have to reinstall Slackware in a hurry (as happened the other day), I can quickly revert to them, but first I gotta give you a handful of disclaimers
1. Because of ASUS & intel's new lousy 4 pin CPU fan control and the fact that my (whatever model) Zallman cooler only provides a 3 pin connector, my PSU is plugged to the CPU fan control, my CPU Fan is plugged to FAN2 or FAN3, and my side case fan is plugged to FAN1 or something. In short, my setup is nonstandard, so if you use my sensors.conf on a regular setup, your Fan labels will be screwed up (but all the rest should be OK)
2. Likewise, my fancontrol file is only meant to work for my rig! If you use it and fry yours, instead of running pwmconfig as you should, tough luck!
3. Kernel 2.6.21 has disabled one of the P5B Deluxe network adapters (the 88E8056), because the driver is reported as broken.
To re-enable it, look for "broken" in drivers/net/sky2.c

Here goes nothing:
o /etc/sensors.conf for MY Asus P5B-Deluxe
# Winbond W83627DHG configuration
# This is for an Asus P5B Deluxe Edition
chip "w83627dhg-*"
# Temperatures
label temp1 "MB Temp"
set temp1_over 50.0
set temp1_hyst 45.0
label temp2 "CPU Temp"
set temp2_over 60.0
set temp2_hyst 50.0
compute temp2 @+10,@-10
ignore temp3
# Fans
label fan1 "Side Fan"
set fan1_min 1000
label fan2 "PSU Fan"
set fan2_min 1000
label fan5 "CPU Fan"
set fan5_min 1000
ignore fan3
ignore fan4
# Voltages
label in0 "Vcore"
set in0_min 1.32
set in0_max 1.60
label in1 "+12V"
compute in1 @*(66/10), @/(66/10)
set in1_min 12.0 * 0.95
set in1_max 12.0 * 1.05
label in2 "+3.3V"
set in2_min 3.3 * 0.95
set in2_max 3.3 * 1.05
label in5 "+5V"
compute in5 @*(32/10), @/(32/10)
set in5_min 5.0 * 0.95
set in5_max 5.0 * 1.05
ignore in3
ignore in4
ignore in6
ignore in7
ignore in8

o MY /etc/fancontrol
INTERVAL=5
FCTEMPS=hwmon0/device/pwm4=hwmon0/device/temp2_input
FCFANS= hwmon0/device/pwm4=hwmon0/device/fan5_input
MINTEMP=hwmon0/device/pwm4=0
MAXTEMP=hwmon0/device/pwm4=45
MINSTART=hwmon0/device/pwm4=30
MINSTOP=hwmon0/device/pwm4=100

o MY /etc/rc.d/rc.fancontrol
#!/bin/sh
#
# /etc/rc.d/rc.fancontrol
#

fancontrol_start() {
/usr/local/sbin/fancontrol | logger &
}

fancontrol_stop() {
killall fancontrol
}

fancontrol_restart() {
fancontrol_stop
sleep 5
fancontrol_start
}


case "$1" in
'start')
fancontrol_start
;;
'stop')
fancontrol_stop
;;
'restart')
fancontrol_restart
;;
*)
echo "usage $0 start|stop|restart" ;;
esac

o My /etc/rc.d/rc.local
#!/bin/sh
#
# /etc/rc.d/rc.local: Local system initialization script.
#
# Put any local startup commands in here. Also, if you have
# anything that needs to be run at shutdown time you can
# make an /etc/rc.d/rc.local_shutdown script and put those
# commands in there.

# Why can't Linus respect the BIOS settings dammit!
/usr/bin/setleds +num
# ICH8R Software RAID Volumes
echo Mounting RAID Volumes
dmraid -ay
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix1 /mnt/vista32
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix2 /mnt/vista64
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix3 /mnt/strider
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Secure1 /mnt/secure
# This is to use the nv framebuffer for X rather than nVidia's
# lousy driver (plus it will remove the bootup penguins)
/usr/sbin/fbset -depth 32
# Harware monitoring stuff
/usr/local/bin/sensors -s
echo Starting Fan Control
if [ -x /etc/rc.d/rc.fancontrol ]; then
. /etc/rc.d/rc.fancontrol start
fi

o /etc/rc.d/rc.local_shutdown
#!/bin/sh
#
# /etc/rc.d/rc.local_shutdown: Local system shutdown script.

if [ -x /etc/rc.d/rc.fancontrol ]; then
. /etc/rc.d/rc.fancontrol stop
fi

o And while I'm at it, my /etc/fstab...
/dev/sda4        /                xfs         defaults         1   1
/dev/sda1 /mnt/osx hfsplus rw 1 0
/dev/sda2 /mnt/winxp ntfs rw 1 0
/dev/sda3 /mnt/alfie ntfs rw 1 0
/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0

o ...as well as my ~/.profile
alias a=alias
a dir='ls -alFh'
a dim='ls -alFh | most'
a so='source ~/.profile'
a s='screen -D -R'

I think that's about it really

2007-05-10

A farewell to LILO (One bootloader to rule them all, part 2)

As mentioned previously, I set up a bunch of disks in a mixed RAID configuration on my new P5B Deluxe system, and merrily went on installing OS after OS.

The point of this exercise was to have my main OS (probably Vista 32) as well as a near half-a-terabyte partition set in RAID 0 mode, for speed, while some other stuff, for which disk performance is not that critical (OS-X, XP, Linux, more space), would reside quietly on a 3rd non raid disk. And while I'm at it, I would also setup a RAID 1 partition, as the Intel ICH8R "controller" of the P5B is now nice enough to allow you to create both a RAID0 and RAID1 drive out of the same 2 disks RAID array.

Which leaves us with the obvious problem of booting that lot, a capital problem indeed ( especially now that Vista is being such an ass about its boot loader). As an aside, I would like to point out that this is what happens when a company has a near monopoly with regards to installed OS base: They will obviously do their darnedest to prevent ANY other OS from eating even the smallest part of their market share. And I could comment on OS-X too. What is wrong with a standard partition scheme that you will recognize once you get your hand forced anyway (but not any sooner)? Why are you not happy with a big fat bootable primary partition with af type setup for you with Linux's fdisk?
And much much worse, how comes the partitions OS-X creates end up on the exact same block as the start of the next partition (have a look at your fdisk results in Linux - What the hell?)? I might talk about that later on, because this headache resulted in recently losing both a fresh install of XP along with a data partition and, what's worse, my Linux system. As the old proverb go, "Install XP, lose your data"...

So, considering that I have now done this operation twice, let me give you the long awaited heads up on the one bootloader to rule them all...


Accessing the ICH RAID disks under Linux

o Compile kernel with device mapper
o Pick up the latest devmapper package from ftp://sources.redhat.com/pub/dm/
o Pick and compile dmraid
o dmraid -ay (if dmraid complains about missing kernel options, add them!)
o dmraid -s (Yay!) or ls /dev/mapper

And while you're at it, you can add something similar to this at the end of your /etc/rc.d/rc.local file (Slackware)
echo mounting RAID Volumes
dmraid -ay
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix1 /mnt/vista32
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix2 /mnt/vista64
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix3 /mnt/strider
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Secure1 /mnt/secure

Becomes simple enough... when you've done that twice.


So long LILO, and thanks for all the flawless boots...

One word if you stubbornly try to get LILO to boot one of the RAID0 partition as I did: Agh!!!

Fatal: Sorry, don't know how to handle device 0xfd02 => compile with latest source, as it will compile with devmapper (device-mapper or LVM2) if library is present. Look for -DDEVMAPPER when compiling.
OK then, added devmapper option, make all, make install and...
"Fatal : device mapper : only linear boot device supported"

Enought with this. I'm sure the LILO devs will add it some day, but for now grub it is then.


Pub grub?

GNU's versions: WTF? Pick up 1.95 and... configure: error: LZO library version 1.02 or later is required
OK then, http://www.oberhumer.com/opensource/lzo/download/ to eventually realize: You should NOT grub 1.95. It's really grub 2.0 and too spanking new to be of any use. Instead, pick up grub 0.97 and live happily ever after!

Now, some of you might see some mention of a grub 0.97 dmraid patch, but because I'm actually using the 3rd non RAID disk (actually 1st one on my system) to install the bootloader, as well as ultimately boot, patching grub is unnecessary. I guess it would be necessary if we were to use our RAID0 as the boot disk. I'll have to try RAID5 one day, just for kicks :D

So, without further adieu to LILO, and with thanks to the Gentoo users:
grub --device-map=/dev/null
# My actual non-RAID boot disk
grub> device (hd0) /dev/sda
# The RAID0 array where the Vista's reside
grub> device (hd1) /dev/mapper/isw_fhbagdjeh_Twix
# Let's first add Linux, so that we can then edit the menu.lst
# My Linux is on /dev/sda4, hence hd0,3 with zero based indexes
grub> root (hd0,3)
Filesystem type is xfs, partition type 0x83
grub> setup (hd0,3)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/xfs_stage1_5" exists... yes
Running "embed /boot/grub/xfs_stage1_5 (hd0,3)"... failed (this is not fatal)
Running "embed /boot/grub/xfs_stage1_5 (hd0,3)"... failed (this is not fatal)
Running "install /boot/grub/stage1 (hd0,3) /boot/grub/stage2 p /boot/grub/menu
.lst "... succeeded
Done.
grub> quit
At this stage, you wanna check your /boot/grub/device.map file. If you don't see the /dev/mapper entry for (hd1) as expected, you will have to add it manually.

From then on, you can go on creating your /boot/grub/menu.lst, which might eventually look something like this:
default 2
timeout 3

title Slackware Linux 11.0
kernel (hd0,3)/boot/vmlinuz root=/dev/sda4

title Slackware Linux 11.0 (Rescue)
kernel (hd0,3)/boot/vmlinuz.rescue root=/dev/sda4

title Vista (32 bit)
rootnoverify (hd1,0)
chainloader +1

title Vista (64 bit)
rootnoverify (hd1,1)
chainloader +1

title Windows XP
rootnoverify (hd0,1)
chainloader +1

title MacOS 10.4.8
rootnoverify (hd0,0)
chainloader +1

Parting words

And thus, I will be leaving with a "so long old Friend..." Since 1995, there haven't been much of a PC installed by yours truly which didn't display the unmistakable red greetings, and I had become such an expert at writing a /etc/lilo.conf, I could have done it blindfolded.
Still, I gotta give it to the GNU guys... Their solution to the booting problem is deceivingly elegant. I'm especially impressed with the "modify menu.lst on the fly" aspect of things and the fact that dmraid "just" works...