On Fri, Mar 29, 2024 at 03:39:44PM +0100, Oldřich Jedlička wrote: > The possibly checked LUKS area might be protected with OPAL HW encryption > and not yet fully unlocked, so try to detect nilfs2 at the beginning of the > area first and if that succeeds, detect it at the end of the area. This > prevents having read errors from the locked area. > > Signed-off-by: Oldřich Jedlička <[email protected]> > --- > libparted/fs/nilfs2/nilfs2.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/libparted/fs/nilfs2/nilfs2.c b/libparted/fs/nilfs2/nilfs2.c > index 6204542..40f8567 100644 > --- a/libparted/fs/nilfs2/nilfs2.c > +++ b/libparted/fs/nilfs2/nilfs2.c > @@ -118,11 +118,12 @@ nilfs2_probe (PedGeometry* geom) > > if (ped_geometry_read(geom, buf, 0, sectors)) > sb = (struct nilfs2_super_block*)(buf + 1024); > + if (!sb || !is_valid_nilfs_sb(sb)) > + return NULL; > + > if (ped_geometry_read(geom, buff2, sb2off, sectors2)) > sb2 = (struct nilfs2_super_block*)buff2; > - > - if ((!sb || !is_valid_nilfs_sb(sb)) && > - (!sb2 || !is_valid_nilfs_sb(sb2))) > + if (!sb2 || !is_valid_nilfs_sb(sb2)) > return NULL; > > /* reserve 4k bytes for secondary superblock */ > -- > 2.39.2 > >
Thanks for the patch! And thanks for looking into this, I hadn't had a chance to try to dig deeper. Could you update the commit message with a bit more background, most readers probably don't know what your situation is. You should also point out that this is a behavior change. Previously it would fail only if both locations were invalid. In practice I doubt this really matters since this is just a filesystem probe to populate the label. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
