Bugzilla – Bug 1212449
systemd-rpm-macros: setxattr failed: /var/lib/machines: Operation not supported
Last modified: 2023-11-24 16:41:43 UTC
There are a few openQA tests failing such as https://openqa.opensuse.org/tests/3360421 The problem seems to be at first an issue with ansible but when checking the logs more closely, we can find things as this: ``` # transactional-update -n pkg install ansible git-core python3-yamllint ansible-test sudo; echo RNKLS-$?- Checking for newer version. transactional-update 4.2.1 started Options: -n pkg install ansible git-core python3-yamllint ansible-test sudo Separate /var detected. 2023-06-16 07:31:05 tukit 4.2.1 started 2023-06-16 07:31:05 Options: -c2 open 2023-06-16 07:31:05 Using snapshot 2 as base for new snapshot 3. 2023-06-16 07:31:05 Syncing /etc of previous snapshot 1 as base into new snapshot "/.snapshots/3/snapshot" 2023-06-16 07:31:05 SELinux is enabled. Relabeled /var/lib/machines from system_u:object_r:unlabeled_t:s0 to system_u:object_r:systemd_machined_var_lib_t:s0 setxattr failed: /var/lib/machines: Operation not supported ID: 3 2023-06-16 07:31:06 Transaction completed. Calling zypper install Relabeled /var/lib/machines from system_u:object_r:unlabeled_t:s0 to system_u:object_r:systemd_machined_var_lib_t:s0 setxattr failed: /var/lib/machines: Operation not supported 2023-06-16 07:31:07 tukit 4.2.1 started 2023-06-16 07:31:07 Options: callext 3 zypper -R {} install -y --auto-agree-with-product-licenses ansible git-core python3-yamllint ansible-test sudo Relabeled /var/lib/machines from system_u:object_r:unlabeled_t:s0 to system_u:object_r:systemd_machined_var_lib_t:s0 setxattr failed: /var/lib/machines: Operation not supported 2023-06-16 07:31:07 Executing `zypper -R /tmp/transactional-update-gNvELc install -y --auto-agree-with-product-licenses ansible git-core python3-yamllint ansible-test sudo`: Loading repository data... Reading installed packages... 'sudo' is already installed. No update candidate for 'sudo-1.9.13p3-3.3.x86_64'. The highest available version is already installed. 'python3-yamllint' not found in package names. Trying capabilities. Resolving package dependencies... The following 17 NEW packages are going to be installed: ansible ansible-core ansible-test git-core libsha1detectcoll1 libyaml-0-2 python311-Jinja2 python311-MarkupSafe python311-PyYAML python311-distlib python311-filelock python311-packaging python311-pathspec python311-platformdirs python311-resolvelib python311-virtualenv python311-yamllint ``` In the last week Tumbleweed has gone under a large rebuild for the transition to Python3.11 This means the macros from the last change of systemd-rpm-macros have started to be used by picked up by all the packages and this issue has finally appeared.
To recap our findings: * ansible is not mis-behaving in the test, it's the messenger of 'something has gone wrong' * The test that runs before ansible is 'cockpit'; at that stage, running t-u still works without any error * the next run of t-u in the ansible test module reports > transactional-update 4.2.1 started > Options: -n pkg install ansible git-core python3-yamllint ansible-test sudo > Separate /var detected. > 2023-06-16 09:29:03 tukit 4.2.1 started > 2023-06-16 09:29:03 Options: -c2 open > 2023-06-16 09:29:03 Using snapshot 2 as base for new snapshot 3. > 2023-06-16 09:29:03 Syncing /etc of previous snapshot 1 as base into new snapshot "/.snapshots/3/snapshot" > 2023-06-16 09:29:03 SELinux is enabled. > Relabeled /var/lib/machines from system_u:object_r:unlabeled_t:s0 to system_u:object_r:systemd_machined_var_lib_t:s0 > setxattr failed: /var/lib/machines: Operation not supported > ID: 3 the 'ansible' part is totally irrelevant, even running t-u shell at this point reports the error; so the 'issue' must have appeared between installing cockpit and finishing the cockpit test. the going theory is: * installing cockpit triggered installation of systemd-container * systemd-container ships a tmpfiles.d, which was triggered right at install time (actual bug in the systemd/rpm macros) At this point, the attributes on /var/lib/machines are 'messed up' and selinux can't relabel it. A simple 'rmdir /var/lib/machines' (it's an empty directory until somebody uses systemd-nspawn) and rebooting recreates the directory properly including the selinux label.
OpenQA confirms the quick fixes from yesterday on systèmd and rpm-macros-systemd to be functional https://openqa.opensuse.org/tests/3363561
This is an autogenerated message for OBS integration: This bug (1212449) was mentioned in https://build.opensuse.org/request/show/1094372 Factory / systemd