grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub.cfg and core.img getting out of sync


From: Pavel Roskin
Subject: Re: grub.cfg and core.img getting out of sync
Date: Thu, 13 Aug 2009 02:54:29 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]