Comment # 11 on bug 1208822 from Petr Vorel

(In reply to WEI GAO from comment #10) 
> In my local env, the case will pass with mkfs.exfat installed, BUT in jeos
> env mkfs.exfat can not be installed(caused by can not install exfatprogs).

I'm sorry, it must be something else. The original report shows mkfs.exfat
installed via exfat-utils:

The following package is recommended, but will not be installed due to
conflicts or dependency issues:
  exfatprogs

The following 167 NEW packages are going to be installed:
  NetworkManager-dns-bind NetworkManager-dns-dnsmasq apparmor-utils attr
babeltrace bc bind bind-utils binutils cpp cpp12 ctags cyrus-sasl
cyrus-sasl-gssapi debuginfod-profile device-mapper dhcp dhcp-client dhcp-server
dnsmasq e2fsprogs ethtool evmctl exfat-utils
(note exfat-utils)
...

# fsconfig03; echo "### TEST cve-2022-0185 COMPLETE >>> $?."
...
tst_supported_fs_types.c:120: TINFO: FUSE does support exfat
tst_supported_fs_types.c:55: TINFO: mkfs.exfat does exist
...
tst_test.c:1634: TINFO: === Testing on btrfs ===
tst_test.c:1093: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
fsconfig03.c:72: TPASS: kernel seems to be fine on btrfs
tst_test.c:1634: TINFO: === Testing on exfat ===
tst_test.c:1093: TINFO: Formatting /dev/loop0 with exfat opts='' extra opts=''
fsconfig03.c:38: TBROK: fsopen() failed: ENODEV (19)

I also verified exfat-utils package locally:
rpm -qlp exfat-utils-1.4.0-1.2.x86_64.rpm
...
/usr/sbin/mkfs.exfat
...
=> it's not a problem of mkfs.exfat dependency.

Sometimes some kernel modules are missing, because we test with only
kernel-default-base package. But 1) we run with fuse 2) although exfat is
module (CONFIG_EXFAT_FS=m see
https://openqa.opensuse.org/tests/3172507#step/install_ltp/75), LTP confirmed
the support (thus module was loaded).

I searched in dmesg. The usual dmesg file in openQA don't contain dmesg output:
https://openqa.opensuse.org/tests/3172507/file/serial0.txt

Looking into another file, which contains dmesg
https://openqa.opensuse.org/tests/3172507/file/shutdown_ltp-dmesg.txt
is without "OpenQA::run_ltp.pm: Starting ..." mark in dmesg 
https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/63a66f99ef7b274c94ac546d3807c89e5a9a0a9c/tests/kernel/run_ltp.pm#L306-L318
which helps finding which dmesg part was caused by particular test (but test is
using virtio console).

There are errors in the end, but because the latest message is btrfs, it 
[ 1517.688092] operation not supported error, dev loop0, sector 98310 op
0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2
[ 1517.688196] operation not supported error, dev loop0, sector 115212 op
0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2
[ 1517.688300] operation not supported error, dev loop0, sector 131078 op
0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2
[ 1517.809762] BTRFS: device fsid ea5c84b6-3547-494d-a4b5-599c5c2e7ec3 devid 1
transid 6 /dev/loop0 scanned by mkfs.btrfs (13689)

=> It would help if you download JeOS image, start it locally with virt-manager
and watch dmesg. Or even start it with strace to see more.