How to modify initial ram disk file (initrd)

Basically, initial ram disk file is used to load some modules before mount the root file systems. ( Usually, modules are loaded after the root file system being mounted. ) Initial ram disk file is necessary when you need the SCSI, LVM, RAID modules to mount the root file system. In most case, you can use the following commands to create a "initrd" file,

• cd /lib/modules/
• depmod 2.6.16.13
• mkinitrd -v -f --with=aacraid --with=sd_mod --with=dm_mod initrd-2.6.16.13.img 2.6.16.13 ("dm_mod" is the LVM related module)

But sometimes, you still want to manually modify this "initrd" file. You can use the following commands to do this (I find out these commands from the Internet).

• cd /boot
• mkdir newinit
• cd newinit
• gunzip -c ../initrd-2.6.15-1.2054_FC5.img | cpio -idmv
• ls (you can find that this is a tiny file system, which is composed of directories, bin, dev, lib and etc. The "init" file contains the commands which will be executed)
• "modify ****"
• find . | cpio --quiet -c -o >../newinitrd
• cd .. (you are now in /boot)
• mv initrd-2.6.15-1.2054_FC5.img initrd-2.6.15-1.2054_FC5.bak (backup current initrd img file)
• gzip -9 < newinitrd > initrd-2.6.15-1.2054_FC5.img
• reboot

How to set up a two machine kernel debug environment

OK, this is a step by step instructions to teach you how to setup a two-machine kernel debugging environment. I use this environment to debug Xen kernel and Dom0 kernel, because the PDB method mentioned in Xen/Doc seems useless here. Ok, let's start:

Step 1, Hardware Requirements.

1. Two computers, but you don't need two monitors, because the output of the target machine will be transmitted to the Develop machine through the serial port. (Target machine is the one on which the debuggable kernel would run, and the develop machine is the one on which you do develop work, such as modifying the kernel source code and compiling kernel.)
2. A "null modem cable", which is used to connect the target machine and develop machine through their serial ports. You can find out the definition of "null modem cable" online. Basically, it is used to connect two serial ports without modem support. It seems it should be "cross-over" cable.
3. An ethernet to connect target machine and develop machine. This ethernet is used to transmit kernel and other image from develop to target machine. Sure, you can use serial cable to transmit these stuff, but I am afraid that would be much slower compared with ethernet. In my environment, I use a cross-over Type5 cable to connect my target machine and develop machine directly. Surely, a more complicated ethernet, which includes switch, would also work.

Step 2, Software Configuration.

1. Enable two serial ports in the BIOS. Now, serial ports are disabled by default in new computers.
2. Compile the kernel with flag "-g", which means this kernel is debuggable. In my experiment, I need to make both the Xen kernel and the Dom0 kernel debuggable. To make Xen kernel debuggable, I add "CFLAGS += -g" in the xen-unstable/xen/arch/x86/Rules.mk, and compile Xen using: make debugger=y. To make Dom0 kernel debuggable, I go to xen-unstable/linux-2.6.16.13-xen0/, type "make menuconfig", go to "kernel hacking" and turn on "Compile the kernel with frame pointers". Then, I modify the "Makefile" to make "CFLAGS_KERNEL = -g". After this, I can compile the kernel with "make".
3. Copy the debuggable kernel to the target machine. In my experiment, the xen kernel would be xen-unstable/xen/xen.gz and the Dom0 kernel would be xen-unstable/linux-2.6.16.13-xen0/vmlinuz. "xen.gz" would be 200+ K and the "vmlinuz" is 2.0+ M. Quite small. I use "scp" to cp these two kernels to the target machine, /boot/ directory. (Sure, you need to setup this ethernet environment to make it works. I just set my develop machine: IP 192.168.1.10 netmask 255.255.255.0 and set target machine: IP 192.168.1.11 netmask 255.255.255.0. Then it works.)
4. Setup the /etc/grub.conf on target machine. You need to tell the kernel to print out its debugging information to the serial port. Sure, in my experiment, I need to tell both the Xen kernel and the Dom0 kernel. My /etc/grub.conf looks like: title Xen 3.0 Debug/ XenLinux 2.6 Debug kernel /boot/xen-3.0-debug.gz dom0_mem=262144 com1=115200,8n1 console=com1,tty module /boot/vmlinuz-2.6.16.13-xen0-debug root=/dev/sda3 ro console=ttyS0 module /boot/initrd-2.6.16.13-xen0.img
5. On the target machine, "Assign a getty to the serial port so that you can log into it: In/etc/inittab: (for RHEL:) 7:2345:respawn:/sbin/mingetty ttyS0 DT115200 (SUSE 10.1:) S0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt102" This "getty" just allow the developers to login into the target machien, from the develop machine, through the serial cable ("specifying a login prompt to be started on the serial port"). "Also add the serial console as a secure tty: in /etc/securetty add 'ttyS0'", which permit root logins over serial console.
6. On the develop machine, I need a program to connect to the serial port. Here, I use "minicom". At first, you need to setup the "minicom" using "minicom -s". Go to the "Serial port setup" and make it looks like Fig 1. Then, save this as default, "Save setup as default". After this, go to "Exit", which will leave minicom listen to the serial port.
7. Reboot the target machine, and wait for the output on the minicom screen.
8. Notice: The command I used to test /dev/ttyS0 status: "stty -a -F /dev/ttyS0" or I can use "dmesg | grep -i ttyS0". 9. Good luck.