action #156925
closedtest fails in toolbox
0%
Description
Observation¶
openQA test in scenario sle-micro-5.5-Default-Updates-x86_64-slem_containers@64bit fails in
toolbox
Test suite description¶
SLE Micro as container host tests (toolbox, podman, rootless podman, podman firewall, etc).
Reproducible¶
Fails since (at least) Build 20240307-1
Expected result¶
Last good: 20240306-1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Logs¶
- toolbox-toolbox_zypper_up.txt
(2/2) Installing: timezone-2024a-150000.75.28.1.x86_64 ........................................<63%>=========================[|]
error: unpacking of archive failed on file /usr/share/zoneinfo/Etc/UTC: cpio: rename failed - Device or resource busy
error: timezone-2024a-150000.75.28.1.x86_64: install failed
error: timezone-2023c-150000.75.23.1.x86_64: erase skipped
(2/2) Installing: timezone-2024a-150000.75.28.1.x86_64 ..................................................................[error]
Installation of timezone-2024a-150000.75.28.1.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.
Updated by mdati 10 months ago · Edited
it could be a BUG in toolbox image, being zypper not able to unlock the package (timezone) to upgrade
In toolbox x86, removing timezone then reinstalling it, that is, after zypper -n ref:
toolbox -r -- rpm -e --nodeps timezone
toolbox -r -- zypper in timezone
toolbox -r -- zypper up
the update proceeds.
Updated by mdati 9 months ago
Useful informations to mention here :
The toolbox should use the same time zone as the host, as by https://github.com/containers/toolbox/issues/70; however the UTC is generally the default for toolbox.
There are two separate mechanisms for changing the timezone data on a system:
- Setting the timezone via /etc/sysconfig/clock and linking /usr/share/zoneinfo/$TIMEZONE to /etc/localtime is the traditional one, used by YaST.
- Then also
timedatectl, the modern solution invented by systemd.
But in toolbox and in our case, the n.2 command is not present, therefore we'd find in the contaiiner:
/etc/localtime -> /usr/share/zoneinfo/UTC.
Updated by clanig 9 months ago
- Status changed from Workable to Resolved
This is fixed.
C.f.: https://openqa.suse.de/tests/13762233
and https://openqa.suse.de/tests/13764579
Updated by mdati 9 months ago · Edited
Until yesterday evening this issue still was present, https://openqa.suse.de/tests/13762334
While working on it, since last run today morning the test began to pass and issue suddenly disappeared, apparently without any change done: https://openqa.suse.de/tests/13762233
Checking status.
Updated by mdati 9 months ago
After further investigation and paused-and-debug https://openqa.suse.de/tests/13764963, noted that the issue timezone install failed disappeared because the toolbox image itself has been updated in the remote pull origin to have the last available package for timezone already installed, that today is timezone-2024a-150000.75.28.1.x86_64.
Therefore our test Update toolbox as rootfull user didn't execute any installation, being all updated already, therfore passed ok.
In this way, eventually future new package like timezone should be needed to install, the resource busy error will be raised again, thefere not resolved, only skipped and delayed.
Moreover the actual tests/microos/toolbox.pm test code provides a zypper update log toolbox_zypper_up.txt log (L#114) only when failed, otherwise none, so that when test pass we have NO information of what happened, unable to verify if installation was really ok or a false-positive occurred, like nothing done, instead.
Updated by mdati 9 months ago · Edited
PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18861
to make visible on console (test needle) the same content of toolbox_zypper_up.txt
Minimalistic update before to close ticket being issue no more present.
MERGED.