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

[Raphael Hertzog]

On Mon, 27 Oct 2008, Robert Millan wrote:
> On Thu, Oct 23, 2008 at 05:45:40PM +0200, Felix Zielcke wrote:
> > Attached is now an ugly patch which would display the grub-probe error
> > "Check your device.map" if it fails.
> > 
> > Else I had the idea to make an environment variable like
> > GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
> > grub_print_error() but then we would need to change grub-common and grub
> > package to fix this bug.
> > 
> > What do you think Robert?
> 
> Sounds like a good idea.  Except that the message in first hunk is not correct
> (it should say Cannot find a device for $1 or something like that).

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
- the installation will still fail and most users have no idea what
  device.map really is. If you go that route, you should at least give
  them the command-line to execute to regenerate the device.map

On the long term, the best would be to use UUID instead of partition names
to be able to reliably find the device name of the intended partition/and
hence drive. I think this is already done for grub2.

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 ?

Someone with a customized but working device.map wouldn't get it rewritten
but someone with a bad file would get it fixed.

> > +	GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null || \
> > +        (echo "Cannot find a GRUB drive for $1.  Check your device.map." && exit 1)

We would then have something like this:
GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null || \
 (grub-mkdevicemap --device-map=${device_map} --no-floppy >/dev/null 2>&1 || true; \
  GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map}  -t drive -d "$1")

If it fails, we regenerate the device.map and try again but this time we
won't hide any error so that if it fails again the user has a chance to
debug it but with the real error message instead.

Does that sound reasonable ?

I'll try that and post a patch if my test shows that it works.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/