2009-01-15

This script will save your life!

Or at least your data.

I have been unofficially sysadm'ing a bunch of HP DL380 running Linux over the past few years, and over the Christmas period, one of those, which had a complex mix of ReiserFS, SWAP and XFS partitions on a RAID5 Smart Array device (dev/cciss/c0d0), found nothing better than to start overwritting the MBR!

What this meant of course was, bye bye partition table, and, as you might guess, I didn't find the need to backup the partition data, thinking: "Heck it's RAID5 - what's the worse that can happen?"

ADVICE #1: If you're running a server in PROD, ALWAYS save a copy of the output of fdisk someplace safe!

Thus, there I was, with a non bootable server and a blank partition table, but with data I very much wanted to get back to. And the only tool I had at my disposal (through a remote console connection, because of course, the server had to be remote) was just a Slackware boot CD (because it detects cciss drives) running busybox.

ADVICE #2: If you have physical access to your server, and it's not using a nonstandard disk device, you can probably find a Linux rescue CD with gpart (but better use the latest Debian version, which is more up to date) that supports more partitions types, and will do a much better job. The script below is really if you are in a hurry or you have limited resources.

How difficult can it be to detect partitions with only a shell script then? Well not that difficult, as the script below will prove. But first let me be clear about what the script is meant to achieve:
  1. This script is meant to detect the POTENTIAL beginning of a partition only. It will tell you the first cylinder, but it will not tell you the size, so unless it's the last one on disk, you'll have to figure out where the next partition begins as well
  2. This script will detect primary partitions only. If you have extended partitions, you're on your own
  3. The script only detected EXT2/EXT3, ReiserFS, Swap (version 2) and XFS. It does not detect FAT or NTFS (because I had no use for it). However, if you know the Magic string and location of other partitions types, you should be able to easily modify the script to add them
  4. Not counting the comments, I kept the script short and basic, because you're most likely to have to type it in by hand, so shorter is better
  5. Be mindful that there are likely to be false positives
  6. And of course, while I succesfully tested this script and all the partitions types on various systems, I am not responsible for any damage occuring from using it.
OK, so below is the part you are interested in:
#!/bin/sh
#
# gpart.sh v1.1 - Linux partitions detection script
# Copyright (C) 2009 >NIL:
# Based in part on gpart (C) 1999-2001 Michail Brzitwa et al.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#

#
## Set your disk parameters below
#
device="/dev/sda"
cyl_start=1
# To find your max cyl_end, use fdisk or cfdisk
cyl_end=35697

#
## FS Magic length, string and offset
## Uncomment only one of the sections below
#

## XFS
#bs=4
#magic="XFSB"
#magic_offset=0x0

## ReiserFS
#bs=4
#magic="ReIs"
#magic_offset=0x10034

## Swap space (v2 only!)
#bs=4
#magic="ACE2"
#magic_offset=0x0FFC

## Ext2 / Ext3
bs=2
## OK, here I have to curse the EXT FileSystem devs for
## not chosing a *PROPER* ASCII Magic like everyone else,
## but using 0x53 0xEF instead as this contains i-umlaut
## Thank God for the -e option of echo, which translates
## a "\0###" sequence into the relevant octal character
magic=`echo -ne 'S\0357'`
magic_offset=0x0438

# on almost any recent disk, a cylinder is
# 255(tracks)*63(sectors/track)*512(bytes/sector) = 8225280
# If you're not sure, check what fdisk tells you
cyl_bytes=8225280
mbr_bytes=32256

#
## You shouldn't have to modify anything below this
#

# dd skips in multiples of bs, so we need to compute
# the cylinder size and magic_offset in bs blocks
cyl_blocks=$(($cyl_bytes / $bs))
mbr_blocks=$(($mbr_bytes / $bs))
magic_blocks=$(($magic_offset / $bs))

for i in $(seq $cyl_start $cyl_end); do
if [ $i == 1 ]; then
# For the first cylinder, we need to skip the MBR as well
skip=$(($magic_blocks + $mbr_blocks))
else
skip=$(($(($i-1)) * $cyl_blocks + $magic_blocks))
fi
# Look for the magic block
header=`dd if=$device bs=$bs count=1 skip=$skip 2>/dev/null`
if [ "$header" = "$magic" ]; then
echo "MATCH: cylinder $i ($header)"
fi
done

2008-12-17

Incoming packet was garbled on decryption (putty)

For some reason, I decided to install openssh on openWRT (Kamikaze), and I have been getting "Incoming packet was garbled on decryption" in putty. This seems to be a ongoing issue linked to the encryption cyphers used by openSSH on low resources systems.

The solution: In the Connection -> SSH menu of putty, make sure 3DES is at the top, and the problem will go away

2008-08-12

mmc driver for openwrt, part deux

Went over the MMC configuration for my openWRT router yesterday, as I wanted to relinquish the use of the SES button by the driver (GPIO4) to use it instead as a toggle button for the Wifi, and use GPIO5 for DO.
As I did just that, I also "fixed" the MMC driver to stop the Power LED from blinking every time the SD card was accessed.
The way I did that was to use the following config.h:
#define SD_CS_POWER 0x82
And the modify the spi.c to have:
static inline void mmc_spi_cs_high(void) {
port_state |= SD_CS_POWER;
(...)
Also, as I am now using GPIOs #2,3,5,7, I had to add a line
echo "0xac" > /proc/diag/gpiomask
in one of the init scripts.

For /etc/hotplug.d/button/01-radio-toggle, I am currently using the following, but I might change that to just turn the radio on/off:
if [ "$BUTTON" = "ses" ] ; then
if [ "$ACTION" = "pressed" ] ; then
WIFI_RADIOSTATUS=$(wlc radio)
# touch /tmp/$WIFI_RADIOSTATUS
case "$WIFI_RADIOSTATUS" in
0|"")
uci set wireless.wl0.disabled=0
uci commit wireless
wifi
wlc radio 1
echo f > /proc/diag/led/wlan
;;
1)
uci set wireless.wl0.disabled=1
uci commit wireless
wifi
wlc radio 0
echo 0 > /proc/diag/led/wlan
;;
esac
fi
fi

Despite the non-quite-thought-through use of the GPIOs in the default MMC driver, I'm beginning to think openWRT is the best invention since sliced bread!

2008-08-10

Installing unsigned drivers on Vista 64

OK, if you ended up here, it's probably because you've been trying to install an unsigned driver (eg. XBCD Xbox Gamepad, PSPLinkUSB), and found out about the requirement for all drivers to be signed in Vista 64.

Now, you shouldn't rush with the first article you found on the web that tells you how to disable signed drivers in Vista altogether. The MUCH smarter way is to run Vista 64 in test mode instead, and self sign your drivers. And to be clear, NO, this does NOT require you to recompile the drivers! You can just pick up the drivers you got from someone and sign them away. Of course, one could comment on yet another of Microsoft's stupid "we don't trust our users" decisions of having to enable the test mode to have users install their self signed drivers. A MUCH SMARTER way would have been to do that outside of the test mode as well. After all, if a user went as far as installing their own root certificate, it's probably that it should be trusted.

Anyway, the procedure is as follows (and it is described in much more details here):

1. Get Vista to boot in test mode always with the command:
bcdedit.exe /store C:\Boot\BCD /set testsigning yes
(And there again, I have to curse Microsoft for NOT indicating with bcdedit /? that you can use the /store option to specify your store, and having to spend HOURS trying to figure out why I was getting the following error which is apparently expected, if you boot multiple OSes and don't let Microsoft take over your boot record:
The boot configuration data store could not be opened.
The system cannot find the file specified.
)

After you enter that command, you MUST reboot Vista.

Note: Once Test Mode is enabled, you will get the Windows Version as well as "Test Mode" displayed over the background image. If you're bothered by this, what on earth are you doing with your computer? Staring at the background?

2. Download the necessary DDK SelfSign files, which I am CONVENIENTLY providing to you HERE, as Microsoft is also an ass there - People shouldn't have to download 2.7 GB to gain access to 700 KB worth of files!
Extract them to the directory where you have your driver

3. Let's say you want to install the PSPLinkusb driver. First you want to generate your own root certificate for that driver with:
makecert -$ individual -r -pe -ss "Self Signed Drivers" -n CN="Self Signed Drivers" selfsign.cer
4. Then you install the certificate you just created to the trusted root directory:
certmgr /add selfsign.cer /s /r localMachine root
(NB: if you have UAC on, you will need to run this command in a "run as administrator" command prompt)

5. Finally, you sign EACH .sys file using the certificate:
signtool sign /v /s "Self Signed Drivers" /n "Self Signed Drivers" libusb0.sys
signtool sign /v /s "Self Signed Drivers" /n "Self Signed Drivers" libusb0_x64.sys
Voila! Now you can install these drivers and get on with your life.

For completion, I am providing below the result of a successful certification for the libusb drivers:
E:\Program Files (x86)\OpenOCD\0.2.0\drivers\ft2232>makecert -$ individual -r -pe -ss "Self Signed Drivers" -n CN="Self Signed Drivers" selfsign.cer
Succeeded

E:\Program Files (x86)\OpenOCD\0.2.0\drivers\ft2232>certmgr /add selfsign.cer /s /r localMachine root
CertMgr Succeeded

E:\Program Files (x86)\OpenOCD\0.2.0\drivers\ft2232>signtool sign /v /s "Self Signed Drivers" /n "Self Signed Drivers" libusb0.sys
The following certificate was selected:
Issued to: Self Signed Drivers
Issued by: Self Signed Drivers
Expires: 2040.01.01 00:59:59
SHA1 hash: E0CEAD6474EFD1BF0F6D47501FF3F069C20FD7C7

Done Adding Additional Store

Attempting to sign: libusb0.sys
Successfully signed: libusb0.sys

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

E:\Program Files (x86)\OpenOCD\0.2.0\drivers\ft2232>signtool sign /v /s "Self Signed Drivers" /n "Self Signed Drivers" libusb0_x64.sys
The following certificate was selected:
Issued to: Self Signed Drivers
Issued by: Self Signed Drivers
Expires: 2040.01.01 00:59:59
SHA1 hash: E0CEAD6474EFD1BF0F6D47501FF3F069C20FD7C7

Done Adding Additional Store

Attempting to sign: libusb0_x64.sys
Successfully signed: libusb0_x64.sys

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

E:\Program Files (x86)\OpenOCD\0.2.0\drivers\ft2232>

2008-08-04

No more "Access Denied" for your files on Vista

Should really be in techno rant, because Vista's "security" is done completely backwards, but here we go. If you try to move/copy/delete/rename the file or directory C:\access_denied, this is what you need to do to recover access:

Open an admin command prompt and issue the following:
takeown /f C:\access_denied
icacls C:\access_denied /grant <username>:F
For what is worth, this is how you manage to delete the files from the infamous C:\Windows\System32\DriverStore\FileRepository, to stop Windows from being a BLEEPING BLEEP with the BLEEPING drivers. I'm gonna have the final say about WHICH driver I want to get installed dammit!

2008-07-17

Script to convert Unix time to a human readable date

unixtime:
#!/bin/sh
date -d @$1

2008-07-10

adding a 2GB SD card on a WRT54G with openWRT

It's been documented to death, so I'm not gonna bother telling you how exactly I did it. Just make sure you use the optimised mmc.o driver from http://forum.openwrt.org/viewtopic.php?id=9653.

I will however document the errors you can get when there's something wrong with your soldering, as I can attest that, if it doesn't work, it doesn't come from the card or the code, it comes from lousy soldering.

o [FATAL] mmc_card_init: invalid response from card: 03 found, waiting for 01

There is a short between your CLK line (usually GPIO3) and your DI line (usually GPIO2)
This can happen if your connection to the white LED is also touching the amber LED. TRIPLE check that your solder points are clean between the 2 front LEDs


o [WARN] mmc_init: impossible to get card indentification info for reason code: 01
o [FATAL] mmc_init: got an error when trying to get card configuration registers: 02


This one's a lot trickier. Just make sure you have the gpio tool at hand, and watch the amber LED closely. By default, it should be completely off. Then issue "gpio disable 3" and then "gpio enable 3". If you can now see a small residual light on the LED, that didn't exist before, then your LED is screwed and therefore your CLK is screwed.
Always make sure that your "enabled" voltages on GPIO are 0V and stay 0V.

I ended up removing the Amber LED (after a test using GPIO5 confirming that I had indeed an issue with GPIO3) and now everything works like a charm.

Oh, and if you're running in mixed mode (root fs still using the onboard flash), chroot is your friend to install packages on the card with ipkg.

2007-12-07

Opening ports for remote access on ZyXEL DSL modem

I have to do this once in a while, then completely forget how it's done, and one year later, I spend 1 hour trying to figure it out again. Well, at least on the Prestige 660RU-T1 it's fairly easy from the web interface: NAT -> SUA Only and add something like:

Start Port No. End Port No. IP Address
1All ports All ports
2

Oh and just in case you wonder, the only mode of authentication allowed from the outside is private key, so good luck trying to break in!

2007-11-06

Disable hibernation in Vista

This can come handy if you have 4 GB RAM and plan to image your partition, as the last thing you want to archive is hiberfil.sys. From a command prompt, simply type:
powercfg -H off
and watch your hiberfil.sys turn to oblivion...

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...

2007-03-30

Yay! MacOS in 1680x1050 at last!

As I mentioned earlier, I am using an MSI 7950 GT with 512 MB on my new rig, and 512 MB have been well known to be incompatible with Titan/Natit and others.
That is, until gotoh figured out that the issue was in the nVidia BIOS itself.
A simple mod/reflash is all that's needed now to get a 512 MB GeForce card to be detected successfully in JasOS. Well, actually, that's was the easy part. The rest, if you're not that familiar with OS-X might be a bit confusing (and threads of more than 25 pages sure do not help!).
Here's how I did proceed to get Natit installed and my card recognised (on an existing installation of Jas OS 10.4.8):
  1. Flashed my Graphics Card following these steps
  2. Downloaded the Natit_Dual_v0.2 package from this page (which got automatically extracted by Stuffit on the Desktop)
  3. Copied over the content to /System/Library/Extensions with the command:
    sudo cp -R Desktop/Natit.kext /System/Library/Extensions
  4. Fired up "System Profiler" in "Utilities" (which you can access with Finder) and found that the Device ID for my Graphics Card was 0x0295
  5. Edited Natit.kext/Contents/Info.plist and change the IOPCIMatch section string to 0x029510de...
  6. in /System/Library/Extensions:
    sudo chown -R root:wheel Natit*
  7. in /System/Library
    sudo rm -rf Extensions.mkext Extensions.kextcache
  8. Rebooted and that was it!

2007-03-28

UltraEdit 32 Explorer Integration in Vista

Looks like Vista broke the integration of UltraEdit in the shell (even with latest version 13.00), without whom life is not worth living. Seriously, not being able to Edit/HexEdit ANY file with a right click really makes life unbearable.

Thankfully, other people have figured out how to do it, and it's really simple:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\UltraEdit 32]
@="UltraEdit"

[HKEY_CLASSES_ROOT\*\shell\UltraEdit 32\command
@="\"C:\\Program Files\\IDM Computer Solutions\\UltraEdit-32\\uedit32.exe\" \"%1\""


(NB:If you create these keys manually, @ is the "(Default)" key in Regedit, and both keys are String values. Of course, quotes don't need to be escaped then)

2007-03-22

The horror! The horror! (Hiding Vista partitions from one another)

I'll cut to the chase. As you know, Vista's new bootloader is complate PITA, because it aims at taking control of all bootloading activities without asking (how rude!), and in typical Microsoft arrogance style, it thinks it can do a better job than you (how inconsiderate!).

Therefore, if you have any combination of XP, Vista, etc... that can be detected, you're pretty much screwed because Vista will insist on unifying the booting of all Windowses for you, which you might think is nice... until the day you remove the OS on which the bootloader is installed, and you realize that you can NO LONGER BOOT THE OTHERS. Don't believe me? Try that little experiment:
Install Vista. Then install another Vista on a different partition. The boot block for the second Vista will be written on the first partition. Now format the first Vista and do your darnedest to boot the second Vista. No way Jose: There's no boot block on that second partition and it will never boot. Well, if you don't mind me saying, that's a really gay way of operating a system.

So there's no way I'm gonna let that happen when I want to have a SINGLE bootloader under my COMPLETE CONTROL!

And it is a little know secret that, despite insisting on being ZE bootloader, Vista will happily receive the boot from another botoloader, as long as it has been installed on a machine where it thinks it is the only Windows OS, which is why it's a good advice to install Vista first, or unplug disks where you might have other Windowses installed. Unfortunately, that method of hiding Vista from Vista (I deem it likely that Vista is horrified from looking at itself in the mirror, hence the title) will not work in our case, where we want to have both Vista32 and Vista64 installed on the same disk. Oh, and you can try to change the partition type of the first Vista you installed, that won't work either. Windows is apparently able to detect itself regardless of the partition type We'll need much more powerful Maßnahmen gegen die Gewalt this time round.

Our solution then: Change the partition type AND fill the Windows partition bootblock with zeros. This is where we open our Swiss Army Knife of anything advanced: Linux.
Whatever you do, you should always install Linux before doing anything else (and be able to boot into it from a CD, floppy, whatever, even if the MBR is erased). Please chant with me now my brothers and sisters: "There is no salvation in the computing world but in Linux".

In my case, Linux is installed on HDD1 and the Vistas go to partition 1 & 2 of the RAID0 ICH8R array (HDD 2&3). You will need to have dmraid setup in Linux to access the ICH8R RAID partitions, but I'll post on that later. So the course of operations is:
  1. Unplug HDD1 and install Vista32 on the first partition of the RAID0 unit. I even let Vista do my partitioning on this drive. Probably not the best idea (cfdisk seems to have problems with how Vista partitioned the drive, but fdisk is fine and see nice primary partitions there). I tend to use the Vista partitioner when I don't really care because in Vista, Megabytes are Megabytes, and not these lousy 1000^2 Megabites cfdisk and others insist on using. Thus, when I enter 45056 MB for the size, I do get a 44 GB partition exactly
    While I'm at it, one piece of free advice. Don't reset your machine on Vista's first boot because you want to reinstall your bootloader or something. If Vista's first boot is interrupted, it will not be able to resume, so make sure that you can actually logon to Vista before you switch to doing something else.
  2. Re-plug HDD1 and boot Linux. Fire up dmraid (dmraid -ay) to gain access to your RAID partitions.
  3. Create a BACKUP of the Vista bootblock on RAID partition 1:
    dd if=/dev/mapper/isw_fhbagdjeh_Twix1 of=/backup/vista32 count=16
    Note 1: The reason I use 16 blocks (16 x 512 bytes) is because the BOOTSECT.BAK backup copy of the original drive bootblock done by Vista on installation is 8 KB big. If it's good enough for Vista, it's good enough for me
    Note 2: The reason my RAID0 array is called Twix has everything to do with the French rebranding of the famous caramel bar from "Raider" to "Twix" a few years ago
    Needless to say, if you ever lose that backup copy of your bootblock, you're screwed
  4. Now we'll ERASE the backed up bootblock with:
    dd if=/dev/zero of=/dev/mapper/isw_fhbagdjeh_Twix1 count=16
    This makes sure that sneaky Windows will not be able to recognize this partition as one of its siblings
  5. fire up fdisk (fdisk /dev/mapper/isw_fhbagdjeh_Twix) and unactivate the first partition, change its type to 'af' (how ironic, this is a MacOS partition type!) and activate the second partition (if the partition on which you plan to install Vista is not set as active/bootable, Vista will refuse to install!)
  6. Unplug HDD1 and install Vista64. Vista will see the first partition alright, but not recognize it, so it will install a second bootloader on the second partition, which is what you want
  7. Re-plug HDD1, boot Linux, issue the dmraid command, and restore the Vista32 boot record:
    dd if=/backup/vista32 of=/dev/mapper/isw_fhbagdjeh_Twix1 count=16
    Fire up fdisk again, and restore the first partition type to '7' (NTFS) and activate it (so that the 2 first partitions are marqued as bootable/active
  8. Use the bootloader of your choice to boot these 2 Vistas independently from one another and be freed from Microsoft's Vista bootloader tie in. One more step into our "One bootloader to rule them all" brainwa^H^H^H^H^H^H^H program...

2007-03-21

One bootloader to rule them all, part 1

So, I bought myself an ASUS P5B Deluxe the other day, with all the good stuff that goes with it (Core 2 Duo E6400, 2 GB CAS 4 RAM, MSI GeForce 7950GX2 512 MB with passive cooling, etc.) and I also added 2 more of these relatively cheap Seagate 7200.10 ST3320620AS SATA II 298.1 GB drives (Hell will freeze over before I recognize that 1 GB is anything else but 1024^3 bytes!) to my existing one which brought my total to 3 of these units.

By the way, my tip to all Seagate 7200.10 drives owners: REMOVE THE HDD JUMPER IF YOU HAVE A SATA II MOTHERBOARD! With the jumper on, transfers are limited to SATA 1 speeds, which will effectively max the drive out to 1.5 Gbps. Without the jumper, you can reach the theoretical SATA II speed of 3.0 Gbps, so that's probably a wise thing to do... even if I doubt any hardware out there, and especially these disks, are able to max out SATA 1 speeds.


The Goal

Have OS-X (Jas OS 10.4.8 or later) plus Windows XP SP2 plus Vista 32 bit plus Vista 64 bit plus Linux (Slackware 11.0) as well as a hefty faaaaast partition installed in a mixed RAID (ICH8R Software RAID) configuration.

A lot of people will tell you that using the RAID0 ICHXR solution is stupid, that you will gain almost no performance, that it's too risky, and so on and so forth. Don't believe a word of it. I've been running a RAID0 array for my main OS and hefty 400 GB partition for the last 2 years, and I have been satisfied enough by this experience that I want to carry it over on my new machine. Preliminary tests show that I can effectively do a non RAID to RAID0 disk to disk copy at close to 70 MB/s (effective mean speed) on my new machine, while the earlier tests I remember with a non RAID0 destination were closer to 35 MB/s, so anybody who tells you that RAID0 doesn't bring anything is a fool.

How is this going to work in practice? Well, first of all, OSX will probably not be too happy on a RAID drive (won't know how to boot) and Linux is not that happy either. Sure, you can make it boot with dmraid and all, but as soon as your MBR is erased (and it WILL be erased), you won't have dmraid support on your boot CD so it's going to be a pain to reinstall. Yeah, I know you can use a bootdisk, and I even created my own custom Slackware boot/install CDs with custom kernel (that's how bender.rpc1.org was installed by the way), but I have become much lazier over the years, and I want to use the default Slackware boot CDs because it's convenient.

Therefeore, we're gonna keep on disk in AHCI (or so was the plan) to have OS-X, Linux, XP and other stuff for which we dont' care too much about perf, while we install the Vista's on the 2 other disks in RAID0 array.


"Good news, everyone!"

Now, here comes the pleasant surprise: Contrary to what was the case in the past, and which was one of the major reasons of my being pissed at these lousy software RAID implementations that could come close to Linux's md, it is NOW possible (at least with ICH8R on an ASUS P5B Deluxe) to create a mixed RAID configurations on the same disk array.
For instance, you can create BOTH a RAID0 unit for speed as well as a RAID1 unit for security with only 2 Disks. This really solves one of the major gripes I had with ICHR, because I want speed for most of my data (which is expandable), but I also want security for the limited set of my data which is not. In the past ICHR iterations, apart from buying 4 disks, you really didn't have a choice. With the latest one, you can have the cake and eat it too.

Now there is a limit to all good things (expect on Linux), and you can only create two raid units on the same array. But as long as I can have a big RAID0 drive and a small RAID1 drive on the same disks, I'm fine with that, so not a problem.

Here's how my current partitioning is done then:
o Disk 0 (non RAID, P5B SATA controller 0): 4 primaries, with OS-X as part 1 (40 GB), WinXP as part 2 (40 GB) and Linux as the last partition (~8 GB). The 3rd partition is used for data
o Disk 1 & 2 (on P5B SATA controllers 1 & 4): One 588 GB RAID0 unit/disk and one 4.1 GB RAID1 unit/disk. The RAID0 unit is partitioned as follows: 44 GB primary for Vista 32, 44 GB primary for Vista 64 and 500 GB for "Strider", my hefty faaaaast data drive (I would of course have preferred 512 GB for the latter, for binary beauty, but I don't think I want to go under 40 GB for a Vista installation.)

Booting all of these OSes will be the tricky part though, which I will detail in the upcoming "Farewell to LILO" post as well as probably part 2 of this post.


"Bad news, nobody..."

And now for the unpleasant surprise (can't have it all). I already had Linux, OS-X and XP installed on the first non RAID HDD (in AHCI mode), and even though I am now in RAID mode instead of AHCI in the P5B Deluxe BIOS, the HDD is in non RAID mode and should still be seen as AHCI (there are 3 modes on the P5B: IDE, RAID or AHCI). Except that intel, in their great wisdom, seem to have decided that, when in RAID mode, non RAID disks should be set as IDE or something, instead of AHCI, which means that WinXP won't boot (nothing that a good driver/reinstall won't fix) but more worrying, that OS-X is now unable to see its own drive as well...

Well, this is bad news because there is no patch for JaS OS 10.4.8 to be compatible with whatever mode ICH8R defines the drives as (and using JMicron as primary SATA controller is not really an option, regardless of whether it is compatible with JaS or not).

So I currently have to switch back from RAID to AHCI in the BIOS to be able to boot OS-X. Darn! The goal is to have "one bootloader to rule them all", not "one bootloader plus manual BIOS conf to rule them all"...


Sidenote

For those who might wonder why I didn't go for what would be considered as the more "sensible" approach of installing Vista(s) on a RAID1 partition, the answer, apart from the obvious hit in performance, is very simple: I tried just that, and then, after installing some updates, Windows refused to shut down for some reason, so I had to it reset. Once I rebooted, the RAID bios detected that my RAID1 array was out of sync and that it needed to be rebuilt. But when I did that in Windows, using the Intel Matrix Storage tools, I realized that this would take forever (about 1% per 30 secs or so on a 44 GB drive). Considering how stable Vista is on shutdown/reboot operations (I'm not even talking of sleep, which, as everybody knows, is simply dreadful and does not work), and how often I am likely to hit the reset button to show that OS who is the master, I'm not going to waste my life in degraded performance mode, having to wait for my array to be rebuilt. This is only the reason why I went for a small RAID1 partition by all standards. I can afford a couple minutes to rebuild a 4 GB drive, but 1 hour for a 40+ one, no way!

2007-03-03

You might remember me...

Hi, I'm hacker >NIL: ("redirect 'slash' nil").

You might remember me for such hacks as "Pioneer DVR-108 v1.18 RPC-1 + 12xRip + nx4all" or "The Matshita UJDA autopatcher", and events such as "Why the hell is rpc1.org down again?!?"...

On this not-so-regularly updated blog, I purport to present you with the unglamorous vicissitudes of managing to make computers, and all things computer related, achieve what you want.

And so, without further ado ...