On Wed, 2009-08-12 at 16:25 +0100, Colin Watson wrote: > I'm having persistent problems with grub.cfg and core.img getting out of > sync. The usual pattern is: > > * Some shiny new feature appears in core.img > * We extend grub-mkconfig to use it > * User runs update-grub but not grub-install (historically a perfectly > sane thing to do, and indeed basically standard practice) > * grub either falls over at boot or does something odd
The assumption is that grub.cfg should be able to deal with it. That's why it sets root before searching. > This just bit me again today, and if it bites me it's going to bite the > users of the packages I upload too. By our today's standards, it's a bug, so it should be reported in a detailed way. > Is there any way we can do better? One thing I was thinking of is that > Ubuntu's carried a patch to GRUB Legacy for some time that stores the > package version at the point when grub-install was last run in > /boot/grub/installed-version. If we did something like that, then > grub-mkconfig could carry a bit of conditional code that says "only use > this feature if the installed version of GRUB is at least <foo>". > grub-mkconfig would end up carrying a bit of bloat, but at least the > bloat is in /usr, and I'm assuming that at this point things are stable > enough that we won't be talking about *too* many changes. > > What do people think about this general approach? There is already a version hardcoded into the uncompressed part of core.img. See kern/i386/pc/startup.S. Unfortunately, there is no policy when the version should be updated. But I'm fine with a separate file in /boot/grub if we decide that the existing version in core.img cannot be used for that and we cannot keep grub.cfg backward compatible. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel