Re: [PATCH] show an error instead of segfaulting on grub-probe -t partmap on a unsynced raid

[Robert Millan]

On Tue, Jul 29, 2008 at 10:20:29PM +0200, Felix Zielcke wrote:
> >#0  0x00000000004015f9 in probe_partmap (disk=0x0)
> >at /home/fz/grub/grub2-1.96+20080724/util/grub-probe.c:87
> >87   if (disk->partition == NULL)
> 
> 
> This is really a good way to get more into this coding and debugging C 
> stuff in general and especially, into grub2's code.
> 
> As far as I could find out now (more with trying it out then reading the 
> code) grub itself can handle a raid1
> with one missing device or an unsynced one.
> Here's a patch which print an error on "grub-probe -t partmap /" instead of 
> segfaulting.
> I have to find out why "grub-probe -t fs /" fails with one missing device 
> but succeeds with an unsynced one.
> First I thought I let it continue and just print out a warning, but there's 
> no grub_util_warn() and probable anyway better
> to reject installing grub on a not fully synced raid.
> 
> Please comment :)
> 
> 
> Index: util/grub-probe.c
> ===================================================================
> --- util/grub-probe.c   (Revision 1747)
> +++ util/grub-probe.c   (Arbeitskopie)
> @@ -179,6 +179,8 @@
>        list = dev->disk->dev->memberlist (dev->disk);
>       while (list)
>        {
> +         if (! list->disk)
> +           grub_util_error ("At least one underlying device for %s is 
> missing.",dev->disk->name);

We generate that list ourselves (I think in util/raid.c), so if one device
is linked in the list but just points to NULL that's our own fault, at least
up to the util/raid.c layer.

-- 
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."