Bug#501306: update-grub fails silently with wrong device.map

[Robert Millan]

On Tue, Oct 28, 2008 at 09:13:30PM +0100, Raphael Hertzog wrote:
> On Tue, 28 Oct 2008, Robert Millan wrote:
> > On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
> > > 
> > > I have two concerns with this:
> > > - grub-probe can possibly fail in other circumstances and we will display
> > >   a misleading error message in those cases
> > 
> > grub-probe's messages aren't always appropiate for grub legacy's update-grub
> > (see #495909).  Besides, when "-t drive" fails it always means that device.map
> > is wrong.
> >
> > > But in the mean time for Grub 1, wouldn't the best solution simply be
> > > to regenerate the device.map in case of errors and try again ?
> > 
> > We tried this, and the solution was worse than the problem.  In the end it
> > had to be reverted.
> 
> Sorry but I don't understand how you concile the two sentences that you
> gave:
> - on one side you say that "-t drive" only fails when device.map is wrong
>   and you accept that we invite the user to regenerate it

s/regenerate/check/g.  When device.map is wrong, it doesn't necessarily mean
we have to regenerate it.  This could be our own fault, e.g. if
grub-mkdevicemap doesn't recognise a new device type.

> - on the other side you tell me that trying to regenerate it only when "-t
>   drive" fails has been tried and was worse than the problem
> 
> What do I miss ?

The behaviour is inconsistent with what users tend to reasonably expect, and
very confusing to those who aren't aware of it.  See for example #479056.
Also, it makes debugging a PITA.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."