Re: Help with lvm2 tests.

Am 28.10.25 um 18:29 schrieb Pierre Labastie ([email protected]
via blfs-dev Mailing List):
> On Tue, 2025-10-28 at 17:12 +0100, Rainer Fiebig wrote:
>> Am 28.10.25 um 16:40 schrieb Bruce Dubbs ([email protected] via
>> blfs-dev Mailing List):
>>> On 10/28/25 2:01 AM, Pierre Labastie ([email protected] via
>>> blfs-dev Mailing List) wrote:
>>>> On Mon, 2025-10-27 at 20:09 -0500, Bruce Dubbs wrote:
>>>>> On 10/27/25 3:12 PM, Joe Locash ([email protected] via blfs-dev
>>>>> Mailing List) wrote:
>>>>>> On 10/27/25 3:36 PM, Bruce Dubbs
>>>>>> ([email protected] via
>>>>>> blfs-dev Mailing
>>>>>> List) wrote:
>>>>>>> I was trying to update to lvm2-LVM2.2.03.36 today but I got
>>>>>>> a lot
>>>>>>> of test errors
>>>>>>> that I can't figure out:
>>>>>>>
>>>>>>> # 443 tests: 6 passed, 236 skipped, 0 timed out, 0 warned,
>>>>>>> 201
>>>>>>> failed in 1:38.219
>>>>>>>
>>>>>>> Can I get someone else to check this out please.
>>>>>>>
>>>>>>>    -- Bruce
>>>>>>>
>>>>>>> Here is an example of the output for one failure:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> I see the same thing:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> ### 443 tests: 6 passed, 239 skipped, 0 timed out, 0 warned,
>>>>>> 198
>>>>>> failed  in  2:17.432
>>>>>
>>>>> I make a little progress.  I thought I has all the appropriate
>>>>> kernel
>>>>> configuration
>>>>> settings in place, but a review of the lvm2 page showed that I
>>>>> missed
>>>>> some.  I now have:
>>>>>
>>>>> ### 443 tests: 155 passed, 247 skipped, 0 timed out, 1 warned,
>>>>> 40
>>>>> failed   in 13:52.880
>>>>>
>>>>> And I loked some more and found that I didn't have all the
>>>>> mdadm
>>>>> kernel modules
>>>>> built.  Adding those I now have:
>>>>>
>>>>> ### 443 tests: 330 passed, 86 skipped, 0 timed out, 1 warned,
>>>>> 26
>>>>> failed   in 32:10.559
>>>>>
>>>>> The tests also seem to want reiserfs and scsi_debug modules.  I
>>>>> looked at the
>>>>> directory test/results and tried to look at the files there. 
>>>>> However
>>>>> there are 314K
>>>>> lines spread out over 445 files.  Trying to find the 26 failed
>>>>> files
>>>>> is not obvious.
>>>>>
>>>>> Overall I'm not sure how to address this in the book and am
>>>>> looking
>>>>> for ideas.
>>>>
>>>> We already make some provision in the book:
>>>> "The tests do not implement the “expected fail” possibility, and
>>>> a
>>>> small number of test failures is expected by upstream. More
>>>> failures
>>>> may happen because some kernel options are missing."
>>>> I guess 26 failures out of 360 or so is acceptable in this
>>>> context.
>>>
>>> Having 26 out of 443 tests or a little over 5 percent is an
>>> unusually
>>> large number for us.  In my first build having only 1% passed is
>>> totally
>>> unacceptable.
>>>
>>> I'm still thinking about how to reword the text about the tests.
>> As the tests are so complex and costly and require configuration-work
>> etc. that goes far beyond what's necessary for just building and
>> installing lvm2, it might make make sense to spell out clearly for
>> whom
>> and under what circumstances it might make sense to run them at all. 
>> I
>> for one didn't and have no regrets about it.
>>
> 
> Problem with tests is that they are so "upstream dependent". And also
> they often test portions of the package that are not needed on a
> desktop machine. LVM is one of those packages that wants to include all
> what can be done in a given domain. Not really the UNIX philosophy, do
> one thing and do it well. It tries to encompass almost all what can be
> done with disks (logical volumes, redundancy, raid, etc). Only a small
> fraction of the code is needed for desktop use. It is easier to move
> volumes around (resize, add, delete, etc) with LVM than with a
> partition manager, but btrfs allows almost the same things to be done.
> And if you need redundancy, I suggest you use some archive manager (on
> a NAS, for example) to save important data.
> 
> In any case, and for all tests (even the tool chain now), I'd say an
> average LFS'er doesn't need to run them, because LFS devs have done it,
> but:
> - they are useful to test that a package is correctly built (when
> building one that is not in the book, for example, or for developers of
> LFS who are never sure they have achieved a good build before testing)
> - they can show examples of how a package is used
> - they are (of course) useful for developers of packages, to prevent
> regressions and test functionalities
> - one important thing for users is also that they can pinpoint what is
> missing for full functionality of a package. For example showing that
> some feature is only available if some dependency is installed (either
> build or run time dependency)
For me the tests are a sort of quality-control.  So I do run the tests
for almost every package that I install, with few exceptions.  I also
keep the logs so that I can compare the results with previous builds.
But I skip the tests for gcc and lvm2 because the cost/benefit-ratio is
just too unfavourable for my use case.

> 
> But maybe this should be moved to another thread...
Not necessarily, as this is quite specifically about lvm2.  I think that
the majority of users will install lvm2 because it's recommended for
libblockdev and libblockdev is required for udisks which most will want
to have.  Thus sooner or later the user will have to make a decision
whether to run the tests for lvm2 or not.  And so I think that a few
words about the usefulness of those tests for a regular user could be
helpful in that respect - similar to what LFS says about the tests for gcc.

Rainer

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page