YouCanToo
The suspense is unbearable any longer, what happened here? 
Old-Polack
I have been looking at this topic a number of times, since I have recently cleaned out 26 test installs I have a few spare partitions and want to look closer at trying to repeat your exercise.
Since it is a long time since I tried to make an rsync -av copy bootable. I know I did make an rsync -av copy bootable and it seemed to work, well it ran. I did not check closer and then many weeks later I thought I found a system that seemed to boot not from the partition I was expecting but from another one. (All history now, the system gone)
Next I ran mkinitrd from a chroot environment on the copied installation, to rebuild the initrd image of the default kernel, so it would use the proper new / partition and filesystem format when booting from its new home.
What happens if the quoted stage is left out? Would the new stanza you added to the menu list still boot, seemingly ok?
I think I am under the misapprehension that an OS rsync copy can be run just by changing fstab in the copy and then make a stanza in the menu.lst? 
Back when, that was all that was needed, but at some point mkinitrd was rewritten, and made more complicated. The initrd image used to just be a few modules that were loaded along with the kernel, and a script to locate boot parameters from files located on the designated / partition. Now it's an entire mini operating system environment. The older image searched the / partition for information at boot time. With the new images, mkinitrd does the searching at image creation time, and has all the information already stored within the image to accelerate the boot time. If the initrd image is not rebuilt, it will contain all the wrong location information from the original installation, and not contain the information it needs for the new/copied location.
If you don't do the mkinitrd step, you will likely boot the old installation's / partition.
