Booting OS Installed on Different Physical Drive in LILO

Booting an OS installed on other physical hard drive could be daunting at times.
However, one LILO keyword could prove very helpful:

master-boot

This keyword means (taken straight from LILO's repertoire):

'master-boot This flag (LILO version 22.5) indicates a DOS/Windows/OS2 or other system which will only boot from BIOS device 0x80, the "C:" drive, or BIOS device 0, the A: drive. When this flag is specified, if this drive is not assigned device code 0x80 or 0 by the BIOS, then the chain loader will dynamically swap the device code actually assigned with device code 0x80 or 0 to make this drive appear to be the first hard or floppy drive, "C:" or "A:".'


In my setup, the default boot drive is sda1 while M$ Windoze XP SP2 is installed on hda1. It seems to be M$ Windoze XP SP2 cannot boot unless its drive appear to be the first hard drive. This is the relevant excerpt from my /etc/lilo.conf:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/sda
#compact        # faster, but won't work on all systems.
lba32
...
# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda1
  label = Slamd64-12.1
  read-only  # Partitions should be mounted read-only for checking
...
# Linux bootable partition config ends

# Windows bootable partition config begins
other = /dev/hda1
  label = Windows
  table = /dev/hda
  master-boot
# Windows bootable partition config ends

That's it. You should be able to boot from Windoze or other "insane" OS from other hard drive with LILO.

Traversing "Huge" Source Code Efficiently

It's inevitable that as a software developer, you will encounter such an enormous amount of code and tasked to modify it to siut the goal that you (or the project manager) have set. Of course, you will ask, why don't use Ctags or something like that? Yeah, of course I use Ctags, but sometimes it's just not fine-grained enough or simply refer to the wrong definition of variables or functions and moreover it can't handle assembly source code reliably.

I have made two bash scripts to cope with this problem. The first script helps you in finding a word (usually function names or symbols in assembler source code):

#!/bin/bash
#
# Script to find a word in an subversion checkout
#
#

SEARCH_PATH=""
WORD=""

if [ $# -ne 2  ]; then
 echo "Usage: $(basename $0) path_to_search  word"
 exit 1;
fi 

SEARCH_PATH=$1
WORD=$2

 find ${SEARCH_PATH} -type f -name '*' -exec grep -nH "\<${WORD}\>" \{} \; | awk '$0 !~ /\.svn/ {print}'

The second script is used to find a string:

#!/bin/bash
#
# Script to find a string in an subversion checkout
#
#

SEARCH_PATH=""
WORD=""

if [ $# -ne 2  ]; then
 echo "Usage: $(basename $0) path_to_search  word"
 exit 1;
fi 

SEARCH_PATH=$1
WORD=$2


 find ${SEARCH_PATH} -type f -name '*' -exec grep -nH "${WORD}" \{} \; | awk '$0 !~ /\.svn/ {print}'

What you need to run both of the previous scripts are find, grep, awk and a bash compatible shell.

Another trick is to search where the symbol/function-name in the compiled object file. More on that later.