Re: Help with lvm2 tests.

On 10/28/25 12:29 PM, Pierre Labastie ([email protected] via blfs-dev Mailing 
List) wrote:
> 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)

I agree with all of that.  I had thought about dropping LVM2 completely, but I asked 
google:

"LVM2 is a logical volume manager for flexible storage management, while Btrfs is a 
modern filesystem with advanced features like copy-on-write (COW), snapshots, and 
compression. You can run Btrfs on top of LVM for a combination of both, but Btrfs 
also includes its own built-in volume management, which can simplify things for many 
users by handling multiple disks and resizing more easily. For a user who needs 
advanced features like instant snapshots, built-in RAID, and easier management across 
different disk sizes, Btrfs is often the better choice. If you need a simpler 
solution for managing partitions or want to use an older filesystem like ext4, LVM2 
is still a solid, flexible option."

On a new system I would suggest btrfs but LVM2 may be useful to some.

   -- Bruce

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