Hello all,
sorry, wall of text incoming.
tl;dr:
If recipes install directories with `install -d path/to/dir`, how is the
default mode determined? What can cause it suddenly (that is, without updating
metalayers or similar) to change from 755 to 700?
full version:
our CI is throwing "Transaction check errors" of the following form:
```
file /etc conflicts between attempted installs of
redactedone-appconfig-1.0-r0.aarch64 and modemmanager-1.12.12-r0.aarch64
file /etc conflicts between attempted installs of
tegra-configs-udev-32.4.3-r0.armv8a_tegra and
redactedone-appconfig-1.0-r0.aarch64
file /usr conflicts between attempted installs of
redactedtwo-scripts-1.0-r0.aarch64 and nvidia-docker-2.2.2-r0.aarch64
file /usr/bin conflicts between attempted installs of
redactedtwo-scripts-1.0-r0.aarch64 and nvidia-docker-2.2.2-r0.aarch64
file /usr conflicts between attempted installs of iptables-dev-1.8.4-r0.aarch64
and redactedtwo-scripts-1.0-r0.aarch64
file /usr/bin conflicts between attempted installs of
systemd-1:244.5-r0.aarch64 and redactedtwo-scripts-1.0-r0.aarch64
```
I examined/unpacked the .rpms in tmp/work/deploy/rpm/aarch64 and really, they
do differ in the mode bits for /etc, /usr and /usr/bin. While these dirs have a
mode of 755 in poky/oe packages, they have a mode of 700 in our packages. The
puzzling thing is that this issue has arised only recently with a totally
independent change in some recipe not mentioned above. The change consisted of
changing the URI of a tarball we fetch from AWS S3 and using sha256 instead md5
for checksumming the file.
At first, this issue appeared somewhat reproducible, but I think that was just
coincedence. Perhaps there is some cache poisoning at play here. Now builds are
also failling which don't have this "bad" commit. Tests are still going on. I'm
now testing if deleting the tmp dir changes anything.
So this mail is rather about: Do you know anything which can point me into the
right direction? The recipes in question all install the directories with
`install -d ${D}/somedir`. I changed some recipes to have `-m 0755` as well,
and one build did indeed succeed then, but then builds started to fail with the
same symptoms but other packages being the culprit, that is, having the dirs
with 700.
I heard the default mode of files/dirs in unix is set with umask, but I have no
idea how to check if/how Yocto is fiddling with that.
Also, sometimes we have these errors: They seem to go away with cleaning the
tmp dir, while the errors above persist. But the sample size is very small so
that might be a wrong lead.
```
INFO - NOTE: Running task 12010 of 12044
(/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs)
INFO - NOTE: recipe our-image-1.0-r0: task do_rootfs: Started
ERROR - ERROR: Task
(/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs)
failed with exit code '134'
INFO - NOTE: Tasks Summary: Attempted 12034 tasks of which 12001 didn't
need to be rerun and 1 failed.
INFO -
INFO - Summary: 1 task failed:
INFO -
/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs
ERROR - Command "/opt/buildagent/work/77acccee8c88a2cf/build$
/opt/buildagent/work/77acccee8c88a2cf/poky/bitbake/bin/bitbake -c build
our-image" failed
--- Error summary ---
ERROR: Task
(/opt/buildagent/work/77acccee8c88a2cf/meta-nellie/recipes-nellie/images/our-image.bb:do_rootfs)
failed with exit code '134'
```
Google said exit code 134 means the process received a SIGABRT, but... I'm
quite sure no-one sent one.
Thank you all,
regards,
Manuel
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55315): https://lists.yoctoproject.org/g/yocto/message/55315
Mute This Topic: https://lists.yoctoproject.org/mt/86985521/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
