The system is almost certainly POSTing. You're insistent that the problem is with the motherboard, while I would argue heavily against it. I realise you're very insistent that GRUB is not being run at all, but you really don't know that for certain -- there's a lot of x86 code that runs in the MBR and subsequent bootstraps before
anything is displayed on-screen. The same goes for any x86 bootloader (and this is where things like Sparc's PROM come in handy, too bad PC architecture sucks :P).
Three possibilities as I see them:
1) When you swapped drives, the previous drive was operating in either CHS, Large (ECHS), or possibly LBA addressing mode
-- while the new drive is operating in a different mode. This will throw all sorts of things for a loop, particularly bootloaders (as the drive geometry now appears different). The default which most BIOSes use -- "Auto" -- picks whichever the BIOS feels is best. This may be different for the 200GB drive than the 320GB drive. This is one of the many reasons IDE/PATA sucks.
I would suggest playing around with this setting in the BIOS. I would also suggest putting the 200GB drive back into the system and seeing what the kernel reports as drive geometry; if the BIOS shows a summary screen, it might also disclose what the addressing mode used is for that model of drive (this is pretty common). If not, try changing it in the BIOS (with the 200GB drive) and see if you can find the non-Auto mode which works reliably, then try that on the 320GB drive.
2) A problem with the bootloader installation on the new 320GB drive. Whatever you used to "duplicate the old to the new" may not have duplicated all the necessary bits. I am not extensively familiar with GRUB, but as I understand it changing any part of the underlying disk hardware requires one rewrite the bootloader (that's the MBR and all subsequent bootstraps). This is especially important if the drive addressing mode changes.
If you're using an MBR scheme then this would be LBA 0 and whatever subsequent boot stages that come after that (GRUB is a multi-stage bootloader and lives both within the MBR as well as subsequent LBAs).
If you're using a GPT scheme, GPT bootstraps are somewhat scattered -- usually LBA 0 is used for booting into the next bootstrap portion (which usually lives within the first 512KBytes of the drive) -- but the GPT table itself lives both around there as well
as at the end of the drive. See Wikipedia's article on GPT.
I would recommend you boot some CD/DVD-based distro (whichever you used to get into GRUB to begin with) and rewrite the GRUB bits from there. You may find that's all it takes -- and if that's the case, it's either (1) or (2) which occurred.
3) A combination of (1) and (2).
Remember: LBA-to-LBA copies do not guarantee that the system will be usable/bootable afterwards, just that you copied every LBA from X to Y. PATA's addressing mode stuff makes it difficult. This is why when upgrading boot drives, I often tell people to just reinstall the OS.--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.