If you are searching for peculiar problems, try this thing: having a Boot Camp partition in a Mac, install Linux in it, and make it boot both natively and inside VMWare Fusion.
Long time ago, I used to have just that, and it worked perfectly. I even mounted the HFS+ partition from Linux and EXT2 partition from Mac.
Some days ago I tried the trick again with Ubuntu 10.04 and it didn't work. I tried almost everything I could think of. The nearest hit was [1] but the recipe didn't work either: once I fixed the boot for one mode, it ceased to work for the other.
The solution I found was to use Super Grub Disk for booting inside VM. I downloaded the ISO and configured the virtual machine to boot from CD (that is, from CD image). In the Super Grub Disk menu, I select "detect any OS" and it magically finds the GRUB configuration in Boot Camp partition.
In my case, I chose to keep the "original" GRUB installed on /dev/sda3 as the native one. I could have done the opposite choice, but then I'd need a real CD or USB stick to boot Linux in native mode. (A really paranoid guy might choose not to install GRUB at all, and always boot from CD, both in native and virtual modes.)
Since this "dual boot" configuration is a sure source of future problems (e.g. if GRUB package is updated from within the VM, in the course of a typical software update), it seems to be a good idea to burn a real ISO with Super Grub Disk and have it around, should the native bootloading is spoiled again.
I am not sure what is the problem that prevents GRUB from working in both environments. It just seems that, even though the VM partition is bound to the "raw" disk partition, VM exports the disk in a slightly different way to the bootloader. Perhaps it adds a fake MBR to create the illusion of a whole disk, honestly I don't know. It used to work with GRUB1, and no longer works with GRUB2. (I have seen another recipe that suggested installing an old version of Ubuntu and then upgrade to more recent, in order to keep the old bootloader.)
[1] http://communities.vmware.com/message/1524729
