Our CI Dunfell builds started failing during image creation with pseudo
aborts like:
path mismatch [2 links]: ino 123107550 db
'/.../build/tmp-glibc/work/mymachine-oe-linux/myimage/1.0-r2/oe-rootfs-repo/mymachine/mypackage-dbg_1.0-r7_mymachine.ipk'
req '/.../build/mymachine-root/usr/bin'.
Inode 123107550 is the second of the two paths.
We're using the latest pseudo (b988b0a6b8afd8d459bc9a2528e834f63a3d59b2)
because we ran into problems sharing sstate cache between different build
OS versions prior to oe-core:d7e87a5851d717da047f552be394d5712efa0402.
The mismatches started happening just after we took
oe-core:9463be2292b942a1072eea88881b9644e55aadb9 (as
b04d7a7aed5b05e8561029c5e570206ac9b9fa4e for Dunfell):
index 459d872b4a..244f5bb8ff 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -180,6 +180,8 @@ LINGUAS_INSTALL ?= "${@" ".join(map(lambda s:
"locale-base-%s" % s, d.getVar('IM
# aren't yet available.
PSEUDO_PASSWD = "${IMAGE_ROOTFS}:${STAGING_DIR_NATIVE}"
+PSEUDO_IGNORE_PATHS .=
",${WORKDIR}/intercept_scripts,${WORKDIR}/oe-rootfs-repo"
+
I was able to reproduce a similar problem by commenting out the above
PSEUDO_IGNORE_PATHS line, building and image, putting it back and forcing
do_rootfs for the image to run again without any intervening cleaning. It
didn't happen every time though.
I believe that the pseudo database was populated with many paths in
oe-rootfs-repo before this change. After the change, the files in
oe-rootfs-repo were replaced which freed up their inodes, but because the
paths were ignored the database wasn't updated. Those inodes were
then used for files and directories in during rootfs creation. Pseudo
incorrectly believed that these inodes were already associated with files
it knew about based on the out-of-date database records.
Cleaning the work directory makes the problem go away because that deletes
the pseudo databases.
Does the above make sense as an explanation for these errors? If so, is
there a good way to avoid these errors?
Could pseudo check whether mismatched paths are now ignored and if so not
treat the mismatch as fatal?
Should changing PSEUDO_IGNORE_PATHS cause all tasks for the recipe to be
re-run so that the out-of-date database is removed?
Even if it's not worth employing some technical measure, perhaps this is
worth mentioning as a potential false alarm at
https://wiki.yoctoproject.org/wiki/Pseudo_Abort ?
Thanks.
Mike.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154617):
https://lists.openembedded.org/g/openembedded-core/message/154617
Mute This Topic: https://lists.openembedded.org/mt/84766871/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
