[arch-general] Bizarre grub drive number switch from (hd1, 5) to (hd2, 5) but no hd2 defined???

[David C. Rankin]

Guys,

	I have managed to get myself in a number of messes over the years, but usually
when I figure out what went wrong, I understand why. Here, I'm at a complete loss.

	I was going to preserve my existing kernel through update and I described in an
earlier email. (I'm still on kernel26-2.6.36.1) So I created a custom initramfs
and preserved the module tree and added the entries to grub menu.lst. This box
has always booted arch on (hd1,5) a device mapper array. (hd0) is another device
mapper array with an old suse install on it. However, after I made may changes
and went to reboot to test the custom initramfs, I got a grub 13 error for an
invalid executable??

	So I booted with the Arch 2010.05 install disk and chrooted my existing install
and looked at grub. When I did my grub > find /boot/grub/stage1, grub reported
stage1 on

(hd0,4)
(hd2,4)

WTF? I don't have an hd2 and what the heck happened to hd1??

[01:42 archangel:/boot/grub] # cat device.map
(hd0) /dev/mapper/nvidia_fdaacfde
(hd1) /dev/mapper/nvidia_baaccaja
(fd0) /dev/fd0

	So I decided to give booting to hd2 a try. So I reconfigured the suse menu.lst
file to call (hd2,5) to boot Arch, and I redid the Arch menu.lst to point
everything at (hd2,5) instead of (hd1,5) and rebooted. To my shock and surprise
- it booted just fine with all the drive number flipped from 1->2.

	This makes no sense whatsoever to me. How does my device.map still correctly
define my (hd0) and (hd1) arrays, but grub spontaneously require booting to
/dev/mapper/nvidia_baaccaja on (hd2). Damndist thing I've ever seen.

	It goes without saying, but I am at a complete loss as to 'what happened' and
'why it happened'. I can't even think of any way it 'could have happened'. All I
did was run mkinitcpio twice to create the custom initramfs that I would use to
preserve the existing kernel when I updated by running:

mkinitcpio -k 2.6.36-dcr \
-c /etc/mkinitcpio.conf \
-g /boot/kernel26-dcr.img

mkinitcpio -k 2.6.36-dcr \
-c /etc/mkinitcpio.conf \
-g /boot/kernel26-dcr-fallback.img \
-S autodetect

	And when I rebooted, I ended up in this mess. So what say the experts. Does
anybody see a way running mkinitcpio as I did above could cause the grub root to
change from hd1 to hd2? I don't see how it could happen. If that isn't the
culprit, does anybody have any other ideas on how this could have happened?

	Thanks for any insight you can give.


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com