grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Bug fix for LVM


From: Robert Millan
Subject: Re: [PATCH] Bug fix for LVM
Date: Sat, 18 Jul 2009 22:05:29 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Jul 18, 2009 at 09:59:55PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Sat, Jul 18, 2009 at 9:43 PM, Bean<address@hidden> wrote:
> > On Sun, Jul 19, 2009 at 3:11 AM, Robert Millan<address@hidden> wrote:
> >> On Sat, Jul 18, 2009 at 10:11:19PM +0800, Bean wrote:
> >>>      }
> >>>
> >>>    grub_raid_rescan ();
> >>> +  grub_lvm_fini ();
> >>> +  grub_lvm_init ();
> >>
> >> This is aside from this patch, but I don't see the purpose of this
> >> grub_raid_rescan() function.  It's in raid.mod but only used by
> >> grub-fstest, so at least it should be #ifdef'ed out, but looking at
> >> what it does, it seems very ad-hoc.  It basically amounts to the
> >> same you're doing with grub_lvm_fini() and grub_lvm_init().  Could
> >> you fix this while at it?
> >
> > This is required. As raid and lvm scan device in init function, but
> > grub-fstest uses loopback device, which hasn't been setup in
> > grub_init_all. This code rescan raid and lvm, otherwise there won't be
> > available.
> >
> This situation isn't strictly speaking restricted to grub-fstest then.
> One would sensibly want to loopmount lvm image in grub shell. Is there
> a way to do it cleanly?

I think a good long-term solution is to move the scan function from
grub_raid_init() to wheereever appropiate to make the scan happen
dynamically everytime e.g. the iterate() function is called.  However,
doing this efficiently needs some work.

-- 
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 via email to

[Prev in Thread] Current Thread [Next in Thread]