Help avoiding grub on wrong hard drive

Readers Digest Version: ran updates of ubuntu x64 on media centre. New kernel cased grup-update to install itself on a hard drive of a mdadm raid array which caused the system to become unbootable and the raid unaccessable.

Basically I was running updates and with my 2 sata cards the onboard controller is recognized as sde-sdi. I got around this (I thought) with UUID in /etc/fstab. However when an update came down I was hoping the newer kernel would fix a problem I had been having so I installed it through apt. Upon rebooting my computer I got a grub error and I couldn't do anything to rescue the system. (super grub and live-cds failed to get grub to find any instances and grub-install refused to work)

Thinking this was related to brtfs on my root partition I thought I may have been hosed as I read that if the kernel in the rescue disk is old enough it may not handle the newer file system (and not knowing much about brtfs I assuming this to be the case)

I set about reinstalling the OS and upon booting directly after the install finished I suffered the EXACT SAME grub problem. disbling the raid allowed me to boot the OS, I then re-enabled the array and attempted to mount it only to find it had a bad super block.

This is when I put 2 and 2 together and realized grub was messing with the partition/first sectors of my raid array. After running xfs_repair over night I was able to restore my raid 5 array to working state and I seem to have been successful at getting rid of the problem

I guess my question is, aside from manually downloading the deb package for the kernel and then doing everything by hand, how can i avoid having grub over-write the first few sectors of my raid array?

IANAGE (I Am Not A Grub Expert ) But I have had to learn a thing or two about it out of necessity. Some of this was pretty recent when I upgraded my main box to use two RAIDed drives (using mdadm.)

I don't see where the kernel has anything to do with the problem you experienced. It seems to me it is either a problem within grub or the scripts that invoke it.

AFAIK it should be OK for grub to load itself onto the boot sector for any raided drives. Most partitioning programs will leave space for that unless you override the default for creating the first partition. My system has two drives (/dev/sd[ab]) and I have installed grub to both.

FWIW, the problem I ran into (and the fix) is documented here: http://ubuntuforums.org/showthread.php?t=1711681

I agree that it is not the kernel itself causing the problem but it is triggering it. Downloading through apt triggers grub to run (as well as depmod etc etc).