grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] lvm: Grub2 fails to detect LVM volumes due to an incorrect c


From: Michael Chang
Subject: Re: [PATCH] lvm: Grub2 fails to detect LVM volumes due to an incorrect computation of mda_end
Date: Thu, 16 May 2024 12:21:45 +0800

On Thu, May 16, 2024 at 12:04:21PM GMT, Michael Chang wrote:
> On Wed, May 08, 2024 at 05:48:15PM GMT, Daniel Kiper via Grub-devel wrote:
> > Adding Marta...
> > 
> > On Mon, May 06, 2024 at 03:18:45PM -0500, Glenn Washburn wrote:
> > > From: Rogier <rogier777@gmail.com>
> > >
> > > When handling a regular LVM volume, Grub can fail with the message:
> > > error: disk `lvmid/******-****-****-****-****-****-
> > > ****/******-****-****-****-****-****-******' not found.
> > >
> > > If the condition which triggers this exists, grub-probe will report the
> > > error mentioned above. Similarly, the grub boot code will fail to detect
> > > LVM volumes, resulting in a failure to boot off of LVM disks/partitions.
> > > The condition can be created on any LVM VG by an LVM configuration change,
> > > so any system with /boot on LVM can become unbootable at 'any' time (after
> > > any LVM configuration change).
> > >
> > > The problem is caused by an incorrect computation of mda_end in lvm.c, 
> > > when
> > > the metadata area wraps around. Apparently, this can start happening at
> > > around 220 metadata changes to the VG.
> 
> The number of times to commit a wrap actually depends on the size of the
> metadata area, how many LVs and VGs are connected to the PV and
> whichever would take part in the size of active raw metadata block
> within the area.
> 
> I managed to use the attached shell script to prepare a LVM disk where
> the metadata area is in wrapped state. It took about 100 cycles for me.

Hm. In each cycle, two changes (lvcreate/lvremove) are committed. Combined
with the initial 30 LVs commit, the total is very close to your 220
metadata changes.

Thanks,
Michael


> With that, I could see the error occurred, and with the patch, the
> problem is gone.
> 
> So, Feel free to add my: 
> 
> Tested-By: Michael Chang <mchang@suse.com>
> 
> Thanks,
> Michael
> 
> > >
> > > Fixes: 879c4a834 (lvm: Fix two more potential data-dependent alloc 
> > > overflows)
> > > Fixes: https://savannah.gnu.org/bugs/?61620
> > >
> > > Signed-off-by: Rogier <rogier777@gmail.com>
> > > Signed-off-by: Glenn Washburn <development@efficientek.com>
> > 
> > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> > 
> > Marta, may I ask you to test this patch?
> > 
> > > ---
> > > I have done no testing of this patch. I've only created a suitable patch
> > > for review. This seems like a fairly serious issue that might one day bite
> > > me, so I think it deserves a review.
> > >
> > > Glenn
> > > ---
> > >  grub-core/disk/lvm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
> > > index 794248540cd3..8535d5a5863a 100644
> > > --- a/grub-core/disk/lvm.c
> > > +++ b/grub-core/disk/lvm.c
> > > @@ -290,7 +290,7 @@ grub_lvm_detect (grub_disk_t disk,
> > >
> > >    p = q = (char *)ptr;
> > >
> > > -  if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, &ptr))
> > > +  if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), &ptr))
> > >      goto error_parsing_metadata;
> > >
> > >    mda_end = (char *)ptr;
> > 
> > Daniel
> > 
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel





reply via email to

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