Bug#345931: If the problem is that the user doesn't know ...

[Kapil Hari Paranjape]

Hello,

On Sat, 23 Sep 2006, Otavio Salvador wrote:
> Kapil Hari Paranjape <kapil at imsc.res.in> writes:
> 
> >> option C, we create a way to extract the version information from every
> >> grub file. So that the grub shell can check that its version matches
> >> the stage files and if not generate an ERROR message.
> >
> > Note that stage1 is a boot sector and so contains precious little
> > space for such version information. Implementing this option seems
> > quite difficult to me.
> 
> I'm not sure but I think we might try to include the version string at
> stage1 and match it when loading stage1.5 or even stage2. Would work,
> no?

I think that the problem that arose was that grub-shell "setup_func" 
of one version (say 0.97) would check for "stage1" and "stage2" without
checking that they belonged to the same version. So the matching
needs to done at installation time and not at run-time. (Though the
latter may be a good thing (TM) to do as well.)

Now there is certainly enough space in "stage2" or "stage1.5" for the
version number so we could check those but that still leaves the
problem of "stage1". (In fact "strings" shows that the version string
already appears in the binaries stage{2,1.5}).

Solution 1: We try to make room in "stage1" for the version number
and check all version numbers before installing. This may be
difficult given that "stage1" is only a boot-sector long and space is
"tight".

Solution 2: (Since "stage1" does not change a lot) we can usually
expect that "stage1" of an older version will be able to load the
current version of "stage2" or "stage1.5"; so we only check the
version numbers of the latter. However, this has some "future risks"
built in---when "stage1" is actually changed what do we do?

The solution that the patch implements is to just print a big fat warning to
the user that it is better to use "grub-install" unless they are sure
that they have the correct versions installed.

Considering the idea of a "feature freeze" for "grub" and a move to
try and consolidate "grub2" instead, I think this solution is simpler
to use than Solution 1 and 2.

Thanks and regards,

Kapil.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20060925/36564eef/attachment.pgp