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

Re: d-i wheezy rc2 preparation, take 2



On Mon, Apr 08, 2013 at 02:51:07PM +0200, Cyril Brulebois wrote:
> Vincent McIntyre <vincent.mcintyre@csiro.au> (08/04/2013):
> > May I remind people about #696877 (when installing from USB stick,
> >  grub writes the MBR to the wrong device - the USB stick).
> > 
> > I think this problem has been around in some form or other in squeeze
> > (eg #666974) and possibly before and I really think it needs fixing.
> > It's going to need code changes (hopefully small) and possibly
> > translation changes.
> > 
> > I have looked into this myself but the grub-installer code is too
> > complex for me to debug, it needs someone more familiar with all the
> > corner cases in the code.
> 
> I very much know about this one, but thanks for making sure.
> 
> Yet, we lack the code currently, and nobody has stepped in to provide
> it, meaning rc2 will have an unfixed grub-installer.
> 
> In an ideal world, someone would submit a fix before r0, we could
> think about shipping an rc3 with it, and profit for r0.
> 
> Mraw,
> KiBi.

I have a possibly dumb question. In the 696877 discussion it is stated
that it's too hard to determine which mounted device the installer is on,
in the case that you are booting from USB (probably also applies to PXE
booting). So the suggested path is to provide code that shows the user a
list of possible disks/partitions to select from, at grub-install time.

My question - why not make it easier to detect where the installer is mounted?
There was mention of a heuristic with a special file/directory (.disk/info)
but why not just do it properly? What scheme would be acceptable?

It seems simple enough to put a well-named file that sits either in the root
of the installer's tree or possibly in the same location as the kernel image.
This could be used to contain the installer image's version/build date,
(which is a bit of a pain to report accurately at the moment)
or perhaps some cryptographic hash of an artifact unique to the installer.
This might require some small changes to the code that builds the installer
images but I doubt it would introduce any regressions since nothing would
depend on it yet.
This must have been canvassed before and rejected, but perhaps the reasons
that applied then have now gone away...


Reply to: