This bug is NOT a duplicate.  

I would like to concur with  Jeremy LaCroix in that kernel updates should not be changing (hdx,y) values when adding a new kernel.  I am inserting my log of setting up a system with mixed pata/sata.  

My question is "Will the kernel update honor the contents of my device.map file or will it ERRONEOUSLY do a BIOS probe and screw up my Windows disk?".

==============================================
 I am setting up a mixed IDE/SATA system.  There will be three disks, IDE0 is 100% Windows, SATA0 is 100% U8.04, SATA1 is 100% U7.04.   I am setting this up with SATA0 as the BIOS boot drive with a menu.list to choose from.  The menu.list specifies (hd0) as boot.

First I set up the SATA drives.
Here is the status after setting up with just the two sata disks and booted into SATA0:

root@voyager:# cd /boot/grub
root@voyager:/boot/grub# cat device.map 
(hd0)	/dev/sda
(hd1)	/dev/sdb
...and all is good to go.

After adding the IDE0 disk, the SATA drives are changed to:

root@voyager:/boot/grub# fdisk -l|grep Disk
Disk /dev/sda: 120.0 GB, 120034123776 bytes   <---------IDE0 100% Windows
Disk identifier: 0xc8e067c5
Disk /dev/sdb: 500.1 GB, 500107862016 bytes   <---------SATA0 U8.04 BIOS boot drive, was sda
Disk identifier: 0x94759475
Disk /dev/sdc: 500.1 GB, 500107862016 bytes   <---------SATA1 U7.04 , was sdb
Disk identifier: 0x00027610
root@voyager:/boot/grub# 

...I modified U8.04 device.map 

root@voyager:/boot/grub# cat device.map 
#@# per fdisk -l and hardware: ide0=sda Windows, sata0=sdb U8.04, sata1=sdc U7.04
#@# the boot/root drive in menu.list is hd0=sata0=sdb U8.04
(hd2)	/dev/sda 
(hd0)	/dev/sdb 
(hd1)	/dev/sdc 
root@voyager:/boot/grub# 

The hope is that when there is a kernel upgrade, that the device.map file will control which disk's MBR gets updated.  I would like for the update to be applied to (hd0)=sata0=sdb, not IDE0.

Let's see what happens if I go:
root@voyager:/boot/grub# grub
Probing devices to guess BIOS drives. This may take a long time.

       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> root (hd0,0)
root (hd0,0)
grub> setup (hd0)
setup (hd0)

Error 17: Cannot mount selected partition
grub> find /boot/grub/stage1
find /boot/grub/stage1
 (hd1,0)
 (hd2,0)
grub> 

BULLBUTTER!!!!!!!!!!!!!!!!!

Why is grub IGNORING my device.map?  Clearly I have mapped (hd0)	/dev/sdb.  It is obvious to me that grub is looking at (hd0)	as /dev/sda.  grrrrr!

To continue, I quit grub and rename device.map, and then run grub again:
root@voyager:/boot/grub# grub
Probing devices to guess BIOS drives. This may take a long time.

       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> 

....and then it hits me like a brick.  Grub is probing BIOS! grrrrr!  There is no complaint about the non-existing device.map.

Why doesn't grub report the results of the BIOS probe?
Why is there a device.map file?  I do a man grub and find:
 --device-map=FILE
              use the device map file FILE

OH! Lets try grub again:

root@voyager:/boot/grub# grub --device-map=/boot/grub/device.map

       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> find /boot/grub/stage1
find /boot/grub/stage1
 (hd0,0)
 (hd1,0)
grub> 
 Wow!!!!! and then:

grub> root (hd0,0)
root (hd0,0)
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub> 

Now to reboot:..........................

Hey! It worked.  

In closing, I have two questions:
1. Can grub report the results of the BIOS probe?

2. Which disk is going to have its MBR updated on the next kernel upgrade?  IOW, will the upgrade honor the device.map file or will it do its own BIOS probe?  If the update fubars my IDE0=100% Windows MBR, it is going to be Grrrrrrrr time again!

Respectfully;
John Gelm