Description of problem: As we move to bootable container images (bootc). We need to be able to do a simple system reset, this means we want file systems like /root to be empty at install time. If we want to add files to /root, it would be better to create these files if they did not exist.
I installed an rpm with this patch, deleted the files in /root and rebooted. The files reappeared after reboot. Ondrej PTAL
Hi Lokesh, thanks for testing, I've added Martin Osvald to the cc, as he now owns majority of the system files related packages. It would make sense to have him review and possibly make an update (It makes sense to me).
Thanks for the patch! Would it be possible for you to do a PR against https://src.fedoraproject.org/rpms/rootfiles ? It helps to better track possible needed changes through comments and allows for rebases due to mass rebuilds. The patch looks ok. So far I found only small problems like this one: ~~~ *** WARNING: ./usr/share/rootfiles/.bashrc is executable but has no shebang, removing executable bit *** WARNING: ./usr/share/rootfiles/.bash_profile is executable but has no shebang, removing executable bit *** WARNING: ./usr/share/rootfiles/.bash_logout is executable but has no shebang, removing executable bit *** WARNING: ./usr/share/rootfiles/.tcshrc is executable but has no shebang, removing executable bit *** WARNING: ./usr/share/rootfiles/.cshrc is executable but has no shebang, removing executable bit *** WARNING: ./%{_tmpfilesdir}/rootfiles.conf is executable but has no shebang, removing executable bit ~~~ Caused by removed/missing `install -m 644` option: Then it fails on scratch builds: ~~~ Processing files: rootfiles-9.0-1.fc40.noarch RPM build errors: error: File must begin with "/": %{_tmpfilesdir}/rootfiles.conf File must begin with "/": %{_tmpfilesdir}/rootfiles.conf Child return code was: 1 ~~~ due to missing undefined _tmpfilesdir macro: ~~~ BuildRequires: systemd-rpm-macros ~~~ Full log from scratch build: https://kojipkgs.fedoraproject.org//work/tasks/8876/112598876/build.log
Another problem I didn't mention in my previous comment is the resulting permissions on the root files after the package upgrade or their removal (and recreation after the machine reboots), the perms change from 644 to 700: ~~~ before: -rw-r--r--. 1 root root 18 Jan 25 19:00 .bash_logout -rw-r--r--. 1 root root 141 Feb 15 02:40 .bash_profile -rw-r--r--. 1 root root 429 Feb 15 02:12 .bashrc -rw-r--r--. 1 root root 100 Jan 25 19:00 .cshrc -rw-r--r--. 1 root root 129 Jan 25 19:00 .tcshrc after: -rwx------. 1 root root 18 Jan 25 19:00 .bash_logout -rwx------. 1 root root 141 Feb 15 02:40 .bash_profile -rwx------. 1 root root 429 Feb 15 02:12 .bashrc -rwx------. 1 root root 100 Jan 25 19:00 .cshrc -rwx------. 1 root root 129 Jan 25 19:00 .tcshrc ~~~ is there any reason you chose 700 instead of 644 in the rootfiles.conf? ~~~ # create initial /root directories shell content C /root/.bash_logout 700 root root - /usr/share/rootfiles/.bash_logout C /root/.bash_profile 700 root root - /usr/share/rootfiles/.bash_profile C /root/.bashrc 700 root root - /usr/share/rootfiles/.bashrc C /root/.cshrc 700 root root - /usr/share/rootfiles/.cshrc C /root/.tcshrc 700 root root - /usr/share/rootfiles/.tcshrc ~~~
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
Went ahead and did the PR for this: https://src.fedoraproject.org/rpms/rootfiles/pull-request/5 Fixed the mentioned issues and will do a few more tests, otherwise, it looks good to me.
Still seeing this in Rawhide and F40.
I am sorry for the delay here. I think I could merge the underlying PR right away without introducing any regression, but I wanted to test it first through a CI test I am currently working on that should cover filesystem-related pkgs and test them during ISO installation. I got burned by seemingly correct changes recently that broke the installations badly. Anyway, I expect to move this forward within a week or so.
> we use rootfiles Why do you use rootfiles?
(In reply to Colin Walters from comment #11) > Why do you use rootfiles? This looks like technical debt that has carried over from Fedora Atomic Host. The mainfiest of the Fedora IoT commit in osbuild was copied from the manifest in pungi (https://pagure.io/fedora-iot/ostree/c/e4dff0e6fb85568963701ced7e8ca97e88e5f74a?branch=main), which looks very similar to the manifest of Fedora Atomic Host at the time. The first introduction of `rootfiles` in the FAH manifest comes from https://pagure.io/fedora-atomic/c/36d18b490529fec91b74ca9b464adb73ef0ab462?branch=master My git archeology failed after that, as I can't find any reference in FCOS config or RHCOS config about when rootfiles disappeared from the manifests. I suspect we could probably safely drop it from the IoT manifest.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-69d5fe79fd