Re: debug parallel root checks

[Ruediger Meier <sweet_f_a@gmx.de>]

On Friday 09 March 2018, Karel Zak wrote:
> On Fri, Mar 09, 2018 at 04:06:08PM +0100, Ruediger Meier wrote:
> > On Friday 09 March 2018, Ruediger Meier wrote:
> > > Hi,
> > >
> > > Our parallel root checks look already nice on the first view.
> > > On the second view they fail the stress test, at least on my
> > > system.
> >
> > Just an arbitrary example. Sometimes I get this failure
> >
> > $ cat  tests/diff/mount/uuid
> > --- /tmp/ul2/tests/expected/mount/uuid  2018-03-09
> > 11:04:54.992654305 +0100 +++ /tmp/ul2/tests/output/mount/uuid   
> > 2018-03-09 15:55:00.168028810 +0100 @@ -1 +1,2 @@
> > -Success
> > +mount: /tmp/ul2/tests/output/mount/uuid-mnt: can't find
> > UUID="f102445a-f6f3-4657-bc58-81ff164fc0d9". +A) Cannot find
> > /dev/loop10 in /proc/mounts
> >
> >
> > So mount can't find that UUID although it was found before by
> > ts_uuid_by_devname, i.e. by blkid(1).
> >
> > What could be the problem:
> >    - another test thread removed the UUID
> >    - invalid blkid cache
> >    - a bug?
>
> We do not use blkid cache, it should be based on udev symmlinks. The
> symlinks are not ready yet. I guess sleep() or so fixed the problem.

I've found now a really stpuid bug which fixes already a lot.

-----------
 tests: fix grep expressions for devices

ts_is_mounted "/dev/loop1" returned true if /dev/loop17 was
mounted. A very annoying source of sporadic failures since
many years. This issue became more visible since running the
checks in parallel, which increases the probability to get
bigger loop device numbers.

https://github.com/karelzak/util-linux/pull/594/commits/5a33a0cdb069b3e86c044eb4f80d0c2104c558b2
-----------

Can't believe that I haven't noticed this bug a few years
earlier ... Now I'm able to run that test loop endless and
collect all tests which still have instabilities.

cu,
Rudi