Re: [ANNOUNCE] util-linux v2.38-rc1

From: Masatake YAMATO
Date: Fri Feb 04 2022 - 13:03:49 EST


Hi,

As I commented on GitHub, I made a pull request for fixing this issue.
I found a bug in the test case, not in lsfd itself.

https://github.com/util-linux/util-linux/pull/1595
https://github.com/util-linux/util-linux/pull/1595/commits/abd93fcecfbb1a1fac7032fac9d2903c5d2d3a38

Masatake YAMATO

From: Masatake YAMATO <yamato@xxxxxxxxxx>
Subject: Re: [ANNOUNCE] util-linux v2.38-rc1
Date: Wed, 02 Feb 2022 23:21:06 +0900 (JST)

> Hi,
>
> thank you for testing lsfd.
>
> Could you tell me what kind of file system for /etc/passwd do you use for testing?
> When trying to reproduce the bug, could you applying the following change?
>
>
> diff --git a/tests/ts/lsfd/lsfd-functions.bash b/tests/ts/lsfd/lsfd-functions.bash
> index 597e48cf4..a81647ccb 100644
> --- a/tests/ts/lsfd/lsfd-functions.bash
> +++ b/tests/ts/lsfd/lsfd-functions.bash
> @@ -43,6 +43,13 @@ function lsfd_compare_dev {
> # if we use findmnt.
> local FINDMNT_MNTID_DEV=$("${FINDMNT}" --raw -n -o ID,MAJ:MIN | grep "^${MNTID}")
> echo 'FINDMNT[RUN]:' $?
> - [ "${MNTID} ${DEV}" == "${FINDMNT_MNTID_DEV}" ]
> - echo 'DEV[STR]:' $?
> + if [ "${MNTID} ${DEV}" == "${FINDMNT_MNTID_DEV}" ]; then
> + echo 'DEV[STR]:' 0
> + else
> + echo 'DEV[STR]:' 1
> + echo 'MNTID:' "${MNTID}"
> + echo 'DEV:' "${DEV}"
> + echo 'MNTID DEV:' "${MNTID} ${DEV}"
> + echo 'FINDMNT_MNTID_DEV:' "${FINDMNT_MNTID_DEV}"
> + fi
> }
>
>
> Masatake YAMATO
>
> From: Anatoly Pugachev <matorola@xxxxxxxxx>
> Subject: Re: [ANNOUNCE] util-linux v2.38-rc1
> Date: Wed, 2 Feb 2022 12:57:47 +0300
>
>> On Tue, Feb 1, 2022 at 11:48 PM Chris Hofstaedtler <zeha@xxxxxxxxxx> wrote:
>>>
>>> Hello,
>>>
>>> * Karel Zak <kzak@xxxxxxxxxx> [220131 16:15]:
>>> >
>>> > The util-linux release v2.38-rc1 is available at
>>> >
>>> > http://www.kernel.org/pub/linux/utils/util-linux/v2.38/
>>> >
>>> > Feedback and bug reports, as always, are welcomed.
>>>
>>> Thanks.
>>>
>>> Some lsfd tests appear to fail in a Debian sbuild build environment,
>>> in that they differ in the expected/actual values of DEV[STR] (see
>>> below). I did not find time to investigate this closer, but thought
>>> it would be best to report it sooner than later.
>>>
>>> Best,
>>> Chris
>>>
>>> ---snip---
>>>
>>> lsfd: read-only regular file ... FAILED (lsfd/mkfds-ro-regular-file)
>>> ========= script: /<<PKGBUILDDIR>>/tests/ts/lsfd/mkfds-ro-regular-file =================
>>> ================= OUTPUT =====================
>>> 1 ABC 3 r-- REG /etc/passwd 1
>>> 2 COMMAND,ASSOC,MODE,TYPE,NAME,POS: 0
>>> 3 PID[RUN]: 0
>>> 4 PID[STR]: 0
>>> 5 INODE[RUN]: 0
>>> 6 INODE[STR]: 0
>>> 7 UID[RUN]: 0
>>> 8 UID[STR]: 0
>>> 9 USER[RUN]: 0
>>> 10 USER[STR]: 0
>>> 11 SIZE[RUN]: 0
>>> 12 SIZE[STR]: 0
>>> 13 MNTID[RUN]: 0
>>> 14 DEV[RUN]: 0
>>> 15 FINDMNT[RUN]: 0
>>> 16 DEV[STR]: 1
>>> ================= EXPECTED ===================
>>> 1 ABC 3 r-- REG /etc/passwd 1
>>> 2 COMMAND,ASSOC,MODE,TYPE,NAME,POS: 0
>>> 3 PID[RUN]: 0
>>> 4 PID[STR]: 0
>>> 5 INODE[RUN]: 0
>>> 6 INODE[STR]: 0
>>> 7 UID[RUN]: 0
>>> 8 UID[STR]: 0
>>> 9 USER[RUN]: 0
>>> 10 USER[STR]: 0
>>> 11 SIZE[RUN]: 0
>>> 12 SIZE[STR]: 0
>>> 13 MNTID[RUN]: 0
>>> 14 DEV[RUN]: 0
>>> 15 FINDMNT[RUN]: 0
>>> 16 DEV[STR]: 0
>>> ================= O/E diff ===================
>>> --- /<<PKGBUILDDIR>>/tests/output/lsfd/mkfds-ro-regular-file 2022-01-31 19:12:43.802603811 +0000
>>> +++ /<<PKGBUILDDIR>>/tests/expected/lsfd/mkfds-ro-regular-file 2022-01-31 14:57:47.000000000 +0000
>>> @@ -13,4 +13,4 @@
>>> MNTID[RUN]: 0
>>> DEV[RUN]: 0
>>> FINDMNT[RUN]: 0
>>> -DEV[STR]: 1
>>> +DEV[STR]: 0
>>> ==============================================
>>
>> Chris,
>>
>> i had this error on my test system
>>
>> https://github.com/util-linux/util-linux/issues/1511
>>
>> but i can't reliably reproduce it now (on my current kernel 5.17.0-rc2
>> and on debian kernel 5.15.0-3-sparc64-smp )
>> Tested with the following command line (for current git util-linux sources):
>> $ for i in {1..100}; do tests/run.sh lsfd; done | grep FAILED
>>
>> ^^ no failed output
>>
>> I can reopen the issue above, so we could try to reproduce it.
>>
>