My guess is that message is coming from your BIOS, meaning that it isn't finding a MBR on the RAID drive. Are there any settings in the RAID Controller's BIOS that might be preventing booting?
Maybe try
The -v will tell you more about what LILO is doing.
Also try adding your image= section to the PATA drive's lilo.conf, run a regular `lilo` and then use that to bootstrap to the RAID. Once running on the RAID, run lilo there to update the RAID MBR, and THEN remove the PATA drive.
Getting your kernel onto any other boot device (USB or CD-ROM) might help and is good to have for recovery.
Wait, you `dd` the contents? Will that work? I don't think it will work unless the partitions are exactly identical, I mean down to the sector count (superblocks might end up in the wrong offset for the size of the partition). Try again with rsync -av which is how I've done this before.
Also, after you get your boot problems resolved, consider using LVM for your other partitions (other than /boot and /root) here's a How-I-Do-It:
/dev/sda1 about 128Meg, ext2 mounted on /boot
/dev/sda2 about 2x RAM, swapfs mounted as swap
/dev/sda3 about 5GB, ReiserFS mounted on root (/)
/dev/sda4 Remainer of Drive, LVM PV and then create a volume group with that. Then create logical volumes that can be easily resized on the fly. The volumes I create wouldn't consume all the free space; the plan is to grow the volumes that need it, only when the need it)
Code:
pvcreate /dev/sda4
vgcreate main /dev/sda4
lvcreate -L 4G -n usr main
mkreiserfs /dev/main/usr
Need more space on the resultant usr logical volume?
Code:
lvextend -L +1G /dev/main/usr
resize_reiserfs /dev/main/usr
which can be done on the fly. (And I have done a couple of times, on my primary production system runing an Oracle Database with 100+ users connected)
ReiserFS is a good choice because it is possible to shrink the partition, but you have to umount it first. JFS and XFS can't be shrunk, they have to be recreated to a smaller size.
Hope something in there helps.
._.