Hi, Since the update to rootfiles 9.x, the OCI image quay.io/fedora/fedora:rawhide no longer contains the root dot files, resulting in among other things, a default bash prompt instead of one printing the "user@hostname" prompt. It's working fine in Fedora <= 42 images which use rootfiles <= 8.x: rgeissler@ncerndobedev6097:~> docker run -t -i --rm --pull=always quay.io/fedora/fedora:rawhide sh -c 'ls -la /root && rpm -qa | grep rootfiles' rawhide: Pulling from fedora/fedora Digest: sha256:f48a335dfaeb458a06d7d8055943daa1e4727240a90a8f579c791d555fc046a2 Status: Image is up to date for quay.io/fedora/fedora:rawhide total 0 dr-xr-x--- 2 root root 6 Feb 6 00:00 . drwxr-xr-x 1 root root 6 Mar 30 14:06 .. rootfiles-9.0-3.fc43.noarch rgeissler@ncerndobedev6097:~> docker run -t -i --rm --pull=always quay.io/fedora/fedora:42 sh -c 'ls -la /root && rpm -qa | grep rootfiles' 42: Pulling from fedora/fedora Digest: sha256:d5604854caddcbed78c85aa43c812a1a4a1f485da03ce6aed5a37b4229a6278a Status: Image is up to date for quay.io/fedora/fedora:42 total 20 dr-xr-x--- 2 root root 91 Mar 30 08:46 . drwxr-xr-x 1 root root 6 Mar 30 14:06 .. -rw-r--r-- 1 root root 18 Jan 18 00:00 .bash_logout -rw-r--r-- 1 root root 141 Jan 18 00:00 .bash_profile -rw-r--r-- 1 root root 429 Jan 18 00:00 .bashrc -rw-r--r-- 1 root root 100 Jan 18 00:00 .cshrc -rw-r--r-- 1 root root 129 Jan 18 00:00 .tcshrc rootfiles-8.1-38.fc42.noarch Note that we have a very similar issue with the UBI 10 beta images (reported in the Red Hat case https://access.redhat.com/support/cases/#/case/04091542). Interestingly, the OCI image quay.io/centos/centos:stream10 doesn't suffer from this issue while there the rootfiles package was also updated recently to move to use tmpfiles.d Reproducible: Always
Note that you may adapt the kiwi scripts to run some "post command" in the generated container, something like this which installs systemd, run systemd-tmpfiles, then removes again systemd: rgeissler@ncerndobedev6097:~> docker run -t -i --rm quay.io/fedora/fedora:rawhide sh -c 'dnf install -y systemd && systemd-tmpfiles --create && ls -la /root && dnf --setopt protected_packages= remove -y systemd && dnf clean -y all' ... (snapped) [35/35] Installing diffutils-0:3.11-3.fc43.x86_64 100% | 2.1 MiB/s | 1.6 MiB | 00m01s Complete! total 20 dr-xr-x--- 1 root root 103 Mar 31 20:14 . drwxr-xr-x 1 root root 73 Mar 31 20:14 .. -rw-r--r-- 1 root root 18 Mar 10 00:00 .bash_logout -rw-r--r-- 1 root root 144 Mar 10 00:00 .bash_profile -rw-r--r-- 1 root root 575 Mar 10 00:00 .bashrc -rw-r--r-- 1 root root 100 Mar 10 00:00 .cshrc drwx------ 2 root root 6 Mar 31 20:14 .ssh -rw-r--r-- 1 root root 129 Mar 10 00:00 .tcshrc Package Arch Version Repository Size Removing: systemd x86_64 257.4-3.fc43 rawhide 12.0 MiB ... (snapped)
I'm not sure what else can be done at the rootfiles side if it relies on systemd-tmpfiles to create them, other than implementing a fallback mechanism to copy/install them there if some external macro is defined? The creation of the dot files through systemd-tmpfiles was introduced to fix: bz 2260104.
I think Valentin was involved in here (I saw him commenting in the pull request) and he is my container point of contact on Red Hat side since quite some time, I will ask him to have a look/explain me what was the initial issue with /root not being empty as I am not sure I understand.
Yes, there's a pretty deep conflict here centered around: - whether systemd is executed at runtime or not - bootc/ostree default of persisting /var vs container images not having persistent state by default In the short term, we can pretty safely change the build process for the app base images (i.e. the non-bootc ones) to run `systemd-tmpfiles --create --prefix=/root` or so. Although since the full systemd isn't installed there it'd need to be done via external invocation as part of a multi-stage build. (Or just do it manually, but that's uglier) > Interestingly, the OCI image quay.io/centos/centos:stream10 doesn't suffer from this issue It's because that image includes systemd, and it or something else is running systemd-tmpfiles as part of the build process. (Yes, we have somehow let the package set and build systems between Fedora, CentOS Stream and RHEL diverge which causes multiple issues)
The more I think about this though, the more I feel the real fix is in /bin/bash - it should read e.g. /usr/share/bash/rc or so by default if there's no ~/.bashrc.
For now the latest UBI 10 beta has this issue, and Red Hat will release RHEL 10 in time for the summit starting on 19th. So I guess this problem won't be fixed in time for the first official release ?
I was just told it's fixed in UBI 9 & 10, and indeed it is. However on fedora side, the image quay.io/fedora/fedora:rawhide still has the same problem. Is the change done on UBI side relevant for fedora as well ?
Note that UBI side, Red Hat engineers decided to use this workaround in their Dockerfiles: https://catalog.redhat.com/software/containers/ubi10/66f2a8d39bdbdc1b74e81460?container-tabs=dockerfile # Create files in /root (RHEL-84969) RUN systemd-tmpfiles --root=/mnt/rootfs --create /usr/lib/tmpfiles.d/rootfiles.conf I am not sure how this shall be fixed in Fedora:rawhide images.
*** Bug 2394283 has been marked as a duplicate of this bug. ***
This should have been fixed with https://pagure.io/fedora-kiwi-descriptions/pull-request/236. The image (43 and rawhide) in quay.io is updated.
Yep it works now on fedora side as well. Thanks !