On Thu 2026-02-26 @ 06:50:30 PM, Mathieu Dubois-Briand wrote:
> On Wed Feb 25, 2026 at 8:49 AM CET, Trevor Woerner via lists.openembedded.org
> wrote:
> > This series of patches splits wic out from oe-core into its own
> > standalone utility. The wic utility will continue to be under The Yocto
> > Project umbrella, but will no longer be integrated into the project
> > as part of oe-core. The ultimate goal is to make wic a completely
> > independent tool, hosted on PyPI, with its own tests, development
> > roadmap, and releases.
> >
> > Some benefits include:
> > - relieving the oe-core maintainers from having to review wic patches
> > - allow the tool to be used outside of The Yocto Project
> > - provide more flexibility to explore other features, libraries,
> > mechanisms, etc
> >
> > These changes have been tested with oe-selftest as follows:
> > $ sudo .../layers/openembedded-core/scripts/runqemu-gen-tapdevs <my
> > numeric group id> 4
> > $ oe-selftest -v -r wic
> >
> > Previously, I had two separate patch sets for wic on oe-core: one
> > to create a standalone utility, and one to re-implement variable
> > sector-size handling. Both these were combined to create a combined "v5"
> > patch set.
> >
> > In v6 the major changes are:
> > - code cleanups to remove cases of "if sector_size and sector_size =
> > 512" in places where we can guarantee sector_size will exist
> > - cleanups to replace "getattr(var, 'sector_size', 512) or 512" since
> > the 3rd arg to getattr() is already setting a default if the variable
> > name is not found
> > - many comment and commit comment improvements
> > - error out if extraopts includes options to set the sector-size in wks
> > files
> > - patch 2 (add ufs class) was dropped
> > - patches 3 and 4 were reversed (move/save wks files before removing the
> > rest of wic from oe-core)
> >
> > For the patch sets up to and including v5:
> > For the standalone patch set:
> > v1: an RFC patchset was sent out, split up into small patches for easy
> > review
> > v2: add wic utility to list of native dependencies of
> > image_types_wic.bbclass
> > v3: squash all commits together to apply atomically
> > v4: (does not exist)
> > v5: rebase on latest master
> > split commits back out acknowledging any bisection that lands
> > between them will fail
> > combine with sector-size patch
> >
> > For the sector-size patch:
> > v1: initial patch set
> > v2: add Mark as co-author of ufs class
> > try to fix a build warning when not using wic
> > v3: actually fix warning when not using wic
> > v4: deprecate, but allow, WIC_SECTOR_SIZE to continue to be used to set
> > the sector-size both from config files and the environment
> > warn when both are used, but prefer cmdline value
> > change partition type of sample wks to gpt
> > v5: fix a bug where WIC_SECTOR_SIZE is not given anywhere
> > combine with standalone patch set
> >
>
> Hi Trevor,
>
> I have another one, a bit more tricky. Two errors:
>
> 2026-02-26 15:48:07,027 - oe-selftest - INFO -
> wic.ModifyTests.test_wic_cp_ext (subunit.RemotedTestCase)
> 2026-02-26 15:48:07,027 - oe-selftest - INFO - ... FAIL
> ...
> 2026-02-26 15:48:07,032 - oe-selftest - INFO - 9: 73/77 513/669 (24.92s) (0
> failed) (wic.ModifyTests.test_wic_cp_ext)
> 2026-02-26 15:48:07,032 - oe-selftest - INFO -
> testtools.testresult.real._StringException: Traceback (most recent call last):
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/wic.py",
> line 2127, in test_wic_cp_ext
> self.assertNotIn("Ext2 inode is not a directory", result.output,
> File "/usr/lib64/python3.12/unittest/case.py", line 1159, in assertNotIn
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib64/python3.12/unittest/case.py", line 715, in fail
> raise self.failureException(msg)
> AssertionError: 'Ext2 inode is not a directory' unexpectedly found in
> 'debugfs 1.47.3 (8-Jul-2025)\n-l: Ext2 inode is not a directory' : Regression
> detected (inode not a directory). Output:
> debugfs 1.47.3 (8-Jul-2025)
> -l: Ext2 inode is not a directory
> ...
> 2026-02-26 16:03:49,379 - oe-selftest - INFO - wic.Wic2.test_expand_mbr_image
> (subunit.RemotedTestCase)
> 2026-02-26 16:03:49,380 - oe-selftest - INFO - ... FAIL
> ...
> 2026-02-26 16:03:49,380 - oe-selftest - INFO - 11: 31/52 617/669 (80.30s) (0
> failed) (wic.Wic2.test_expand_mbr_image)
> 2026-02-26 16:03:49,380 - oe-selftest - INFO -
> testtools.testresult.real._StringException: Traceback (most recent call last):
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/layers/openembedded-core/meta/lib/oeqa/core/decorator/__init__.py",
> line 35, in wrapped_f
> return func(*args, **kwargs)
> ^^^^^^^^^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/wic.py",
> line 1830, in test_expand_mbr_image
> runCmd(cmd)
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/layers/openembedded-core/meta/lib/oeqa/utils/commands.py",
> line 214, in runCmd
> raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s"
> % (command, result.status, exc_output))
> AssertionError: Command 'wic write -n
> /srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native
> --expand 1:0
> /srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.wic
>
> /srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/deploy/images/qemux86-64/tmpwiadp9sz.wic.exp'
> returned non-zero exit status 1:
> [engine.py:589] INFO: copying unchanged partition 1
> [engine.py:602] INFO: resizing ext partition 2
> Traceback (most recent call last):
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/bin/wic",
> line 8, in <module>
> sys.exit(main())
> ~~~~^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/cli.py",
> line 631, in main
> return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage,
> subcommands)
>
> ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/help.py",
> line 83, in invoke_subcommand
> subcmd[0](args, usage)
> ~~~~~~~~~^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/cli.py",
> line 298, in wic_write_subcommand
> engine.wic_write(args, args.native_sysroot)
> ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/engine.py",
> line 686, in wic_write
> disk.write(args.target, args.expand)
> ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/engine.py",
> line 605, in write
> exec_cmd("{} -pf {}".format(self.e2fsck, partfname))
> ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/misc.py",
> line 116, in exec_cmd
> return _exec_cmd(cmd_and_args, as_shell)[1]
> ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/usr/lib/python3.14/site-packages/wic/misc.py",
> line 103, in _exec_cmd
> raise WicError("_exec_cmd: %s returned '%s' instead of 0\noutput: %s" % \
> (cmd_and_args, ret, out))
> wic.WicError: _exec_cmd:
> /srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2592824/tmp/work/x86-64-v3-poky-linux/wic-tools/1.0/recipe-sysroot-native/sbin/e2fsck
> -pf /tmp/wic-part2-44outsk3 returned '1' instead of 0
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3161
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3170
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3164
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3166
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3165
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3169
>
> Now the tricky part: this only seems happen on Fedora. I did test on
> various versions, and it looks like all version from 39 to 43 show the
> issue on the autobuilder. This was never seen in any oe-selftest-debian
> build.
>
> I tried another build without this series and I confirm the issue is
> gone.
>
> Can you have a look at what is wrong here?
Yes, thanks. The good news is I see these exact same errors on my home
machine, OpenSUSE Leap 16.0. That's why I sent the RFC set a while back
to try to determine if these were general issues or something specific
to my machine. When the RFC set passed I assumed it was a problem on my
machine and didn't go further trying to debug.
The first test fails for me at home without any of my patches, so
there's probably something funny going on there.
The second failure (e2fsck) is interesting. wic assumes that any
non-zero return value from any external command it invokes is a
failure. But in the case of e2fsck a zero means success and no fixups
were needed, and a return value of 1 means success but there were
fixes that were needed (and the filesystem is now clean) for example:
deleted/unused inodes, fixed refcounts. For some reason, when I (and
Fedora too it seems) create the image, it seems to be in need of some
e2fsck fixups even though the filesystem is completely new and never
mounted. It could be related to host kernel filesystem handling, the
filesystem type on which the image is created, or perhaps the type of
disk that is used. In my case I'm generating these images on an nvme
drive, maybe that's significant?
In both cases the fixes should be straight-forward, now that I know
they're general bugs and not something specific to my setup at home.
Thanks!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#232060):
https://lists.openembedded.org/g/openembedded-core/message/232060
Mute This Topic: https://lists.openembedded.org/mt/117991330/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
