[PATCH 1/1] Revert "kas-container: propagate timezone information into container"

6 views
Skip to first unread message

Felix Moessbauer

unread,
Jul 24, 2025, 10:45:37 AMJul 24
to kas-...@googlegroups.com, jan.k...@siemens.com, christi...@siemens.com, Felix Moessbauer
This reverts commit 37836639578ae4701380fae1d2c4b9830eea30f5.

Correctly setting the timezone information in the container is tricky,
as we cannot fully rely on the TZ variable (it is not exported into the
bitbake environment and not always set), but also not bind-mount the
/etc/timezone, as the target is a symlink. Both docker and podman mount
without the AT_SYMLINK_NOFOLLOW flag and by that, overwrite the symlinks
target (instead of the symlink itself). This breaks yocto builds which
rely on correct information in /usr/share/zoneinfo/*.

Other options like mounting to a staging dir have been considered, but
decided against due to the complexity and potential corner cases. At
least podman offers a --tz option, which users can use by adding it to
the --runtime-args. For docker, no such option exists.

Closes: #162
Xref: #157
Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
@jan: This fix should be considered in a 4.8.2 release, in case you plan
to create one.

docs/command-line/environment-variables.inc | 2 --
kas-container | 11 +----------
2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/docs/command-line/environment-variables.inc b/docs/command-line/environment-variables.inc
index 875f4b343..f12e0bee8 100644
--- a/docs/command-line/environment-variables.inc
+++ b/docs/command-line/environment-variables.inc
@@ -138,8 +138,6 @@ overwritten using the ``env`` section of the config file.
| ``TERM`` | The terminal options used in the `shell` plugin. |
| (C,K,E) | |
+--------------------------+--------------------------------------------------+
-| ``TZ`` (C) | Timezone settings. |
-+--------------------------+--------------------------------------------------+
| ``AWS_CONFIG_FILE`` | Path to the awscli configuration and credentials |
| |aws_cred| | files that are copied to the kas home dir. |
| (K,C) | |
diff --git a/kas-container b/kas-container
index e8735884d..ec493425e 100755
--- a/kas-container
+++ b/kas-container
@@ -687,18 +687,9 @@ if [ -n "${SSTATE_MIRRORS}" ]; then
set -- "$@" -e "SSTATE_MIRRORS=${SSTATE_MIRRORS}"
fi

-# propagate timezone information
-if [ -f "/etc/localtime" ]; then
- set -- "$@" -v "$(realpath -e "/etc/localtime")":/etc/localtime:ro
-fi
-if [ -f "/etc/timezone" ]; then
- set -- "$@" -v "$(realpath -e "/etc/timezone")":/etc/timezone:ro
-fi
-
for var in TERM KAS_DISTRO KAS_MACHINE KAS_TARGET KAS_TASK KAS_CLONE_DEPTH \
KAS_PREMIRRORS DISTRO_APT_PREMIRRORS BB_NUMBER_THREADS PARALLEL_MAKE \
- GIT_CREDENTIAL_USEHTTPPATH \
- TZ; do
+ GIT_CREDENTIAL_USEHTTPPATH; do
if [ -n "$(eval echo \$${var})" ]; then
set -- "$@" -e "${var}=$(eval echo \"\$${var}\")"
fi
--
2.50.0

Jan Kiszka

unread,
Jul 28, 2025, 1:03:15 PMJul 28
to Felix Moessbauer, kas-...@googlegroups.com, christi...@siemens.com
On 24.07.25 16:45, Felix Moessbauer wrote:
> This reverts commit 37836639578ae4701380fae1d2c4b9830eea30f5.
>
> Correctly setting the timezone information in the container is tricky,
> as we cannot fully rely on the TZ variable (it is not exported into the
> bitbake environment and not always set), but also not bind-mount the
> /etc/timezone, as the target is a symlink. Both docker and podman mount
> without the AT_SYMLINK_NOFOLLOW flag and by that, overwrite the symlinks
> target (instead of the symlink itself). This breaks yocto builds which
> rely on correct information in /usr/share/zoneinfo/*.
>
> Other options like mounting to a staging dir have been considered, but
> decided against due to the complexity and potential corner cases. At
> least podman offers a --tz option, which users can use by adding it to
> the --runtime-args. For docker, no such option exists.
>
> Closes: #162
> Xref: #157
> Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
> ---
> @jan: This fix should be considered in a 4.8.2 release, in case you plan
> to create one.

This does not answer what will be done to achieve the original goal of
37836639578ae4701380fae1d2c4b9830eea30f5. Why not construct what we need
in the entrypoint script?

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center
Reply all
Reply to author
Forward
0 new messages