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
