I have exactly the same problem (2.6.38 boots, but 2.6.39 does not). My installation has used grub2 since 2.6.34.

Let me make sure I understand what you mean by "updating grub resolve the problem".

Do you mean:

A. You ran 'update-grub' to refresh grub2's view of disks and partitions.

OR

B. You replaced the installed instance of grub2 with a newer instance of grub2.

Hopefully you do not mean interpretation B. because that would imply a very serious problem. So long as a particular kernel image satisfies all the basic driver requirements (fs, scsi, raid, etc.) it should have no dependencies on the version of the boot tool used. Such extraneous dependencies would destroy its usefulness as a multiboot tool. Worst case is if each OS had a dependency on a different version of the boot tool. How are you going to boot? Install the boot tool in every partition and boot a sequence of OS until you get to the one you want?? I'm exaggerating, but you see my point, this becomes a serious problem long before the worst case is reached.

Ben gave the only valid example of how an install of grub2 might solve this problem, but I don't think it's applicable in this case because grub2 did not change significantly between 2.6.38 and 2.6.39. Heck, it didn't change much from the days of 2.6.34 till 2.6.39. Something connected with 2.6.39 is botched. Either the make targets that use older .config files (i.e. 'make oldconfig') or the 2.6.39 source code itself is faulty. There are far too many people with up-to-date grub2 multiboot systems that are seeing this exact same problem.

I will eventually get to the bottom of this, but it would be nice if the Debian folks could provide an answer before then. It would save many of us a lot of time and aggravation.
Thanks.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to