[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] show an error instead of segfaulting on grub-probe -t partma
Re: [PATCH] show an error instead of segfaulting on grub-probe -t partmap on a unsynced raid
Wed, 30 Jul 2008 12:37:08 +0200
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
> 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
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.
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."