All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] show an error instead of segfaulting on grub-probe -t partmap on a unsynced raid
Date: Wed, 30 Jul 2008 12:37:08 +0200	[thread overview]
Message-ID: <20080730103708.GA17771@thorin> (raw)
In-Reply-To: <D9B3B157382F47568EF6B303B6E162D2@fz>

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



  reply	other threads:[~2008-07-30 10:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-28 23:05 grub-probe crashes on a linux softraid 1 with one disk beginning to sync Felix Zielcke
2008-07-29 20:20 ` [PATCH] show an error instead of segfaulting on grub-probe -t partmap on a unsynced raid Felix Zielcke
2008-07-30 10:37   ` Robert Millan [this message]
2008-07-30 11:39     ` Felix Zielcke
2008-07-30 15:11       ` Felix Zielcke
2008-08-01 13:36         ` Robert Millan
2008-08-01 15:22           ` Felix Zielcke
2008-08-02 19:00             ` Felix Zielcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080730103708.GA17771@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.