grub2 writes to boot sector of all attached drives?

[suplero]

Re: grub2 writes to boot sector of all attached drives?

Thanks for the help again Qqmike,

running grub-emu I find:

sh:grub> ls
(host) (hd0) (hd0,8) (hd0,7) (hd0,6) (hd0,5) (hd0,3) (hd0,2) (hd0,1) (hd1) (hd1,3) (hd1,2) (hd1,1)

and from the partitions listed, it does seem that grub thinks the SATA drive is hd0, not the IDE drive I boot with Karmic.

This problem could be coming from the /boot/grub/device.map file mentioned in the grub updating.

For my system, that file contains:

cat /boot/grub/device.map

(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdg

Which to me implies that grub wants to write to hd0 from this file and that would be the problem. I think if I fixed it manually, the problem wouldn't return.

However, the follow-up question would be why it was written that way in the first place.

I'm not sure how often that file is written or updated, so really I would only be guessing, but the date on the file itself is 2009-09-07. I think my initial install was in July. I've only updated since then.

I installed Karmic on the IDE drive when it was the lone drive [sdg is the card reader -mostly ignored] so that would/should make it sda??

Then I added the SATA drive, and configured the bios to boot from the IDE drive. However, at this point the /boot/grub/device.map file may have been rewritten with the new devices - in the new order as well.

It may quite possibly be that there was a bug at that point that has been corrected, so it might be difficult to recreate anything, though I think I will try some stuff.

very puzzling indeed.

[Qqmike]

Re: grub2 writes to boot sector of all attached drives?

"Which to me implies that grub wants to write to hd0 from this file and that would be the problem. I think if I fixed it manually, the problem wouldn't return."

Yes, as root, you can freely edit device.map.
It's a strange little file, generated, I think, each time grub-install runs. In GRUB 2, as you may know, after grub-install runs, you are given the chance (in a text message at the command line) to correct device.map if you think it is wrong, then run grub-install again. GRUB, working inside Kubuntu, does its best to guess what the mappings in that file should be, and sometimes it guesses wrong. The device.map file is not used upon booting; it is only used upon installing Kubuntu, updating Kubuntu, etc. It is not important as far as booting goes, but you may have run into an example where it is important for updates (which classifies an an "installation" of Kubuntu). That's why the ls command is so important. In GRUB Legacy it was the geometry command. Those commands tell you how BIOS & GRUB are seeing your drives in (hdx,y) terms--very important for booting and for installing GRUB to MBRs and to partitions. Kubuntu/Linux OS MAY see your drives "differently" at times (different from the output of ls -- the (hdx,y)'s). And yes, you may be correct that removing drives and then replacing them could mix up the musical chairs. That's why I always advocate keeping all drives in their places, but before running any Kubuntu install routine, you should explore your drives yourself using ls (maybe from a Live Cd if necessary), just so YOU know what the right ((hdx,y)'s should be from BIOS's (and therefore also GRUB's) view. But, having said all this, as you can see, sometimes those sdan'x and sdbm's (as listed in device.map) ARE important to know, yet they are guesses that may be wrong.

So, bottom-line is that you may manually edit device.map. You can always restore the old one, or even try other permutations of the sdxn's.

In GRUB Legacy, it was well known that having a mixture of IDE and SATA drives could mess things up (as far as device naming was concerned). Don't know if that's true with GRUB 2 since it is so new. But even there, the ls command will get things straight in BIOS/GRUB terms (hdx,y). As for Linux's sdan terms, well, that's still a crap shoot. As we know, sda may not always be hd0, sdb may not always be hd1, and so on.

So, I agree with your take on this--try to play with device.map.