Transferring my issue from Is it possible to find the "creator"/"owner" of a deployed file? · Issue #2433 · ostreedev/ostree · GitHub
Hi Silverbluers,
On one of my systems I have a /usr/etc/authselect/user-nsswitch.conf.bak file which I can’t make sense of. Is there a tool or log available that could help me pinpoint the creator/owner/source of it?
On Silverblue & Kinoite, 99% of the content in /usr comes from an RPM. Running:
rpm -qf /path/to/file
will give you the corresponding package.
Everything else that does not explicitly come from an RPM can come from:
/etc (and some other special places) moved by rpm-ostree to /usr.For your particular case, this is a probably a mix of a file generated by a scriptlet and then moved by rpm-ostree into /usr/etc which is a pristine copy of /etc as installed during the image build.
Thank you very much for the explanation @siosm
- A file generated, modified or created by RPM scriptlets that are run during the image build.
Let’s take the mysterious /usr/etc/authselect/user-nsswitch.conf.bak as an example.
~ ❯❯❯ rpm -qf /usr/etc/authselect/user-nsswitch.conf.bak
file /usr/etc/authselect/user-nsswitch.conf.bak is not owned by any package
If I get it right: A layered package can include/trigger a scriptlet which generates, modifies or creates a file that has no relation visible through rpm -qf. This brings up a follow-up question: Is a log of the image build available which would show the creation of this file?
A file from
/etc(and some other special places) moved by rpm-ostree to/usr.
Don’t wanna diverge from the initial question too much. This is a mechanism I’ve seen in practice a lot but that I have not fully understood yet. Is there documentation available to better understand when and for which files rpm-ostree is doing this transfer?
Yes. This is another case where we would very much appreciate to have a few scriptlets as possible doing weird things 
.
The local layering case should produce local logs in the journal (have not fully checked yet).
For the base image, logs for failed composes are available at: https://pagure.io/releng/failed-composes/issues. I don’t know where the logs from successful composes are 
.
Existing documentation that I know of:
These “.bak” files are usually placed there when it has been modified locally outside package upgrades. If we remove the “.bak”-extension, we can find the package it belongs to:
[eivind@lightpad ~]$ rpm -qf /usr/etc/authselect/user-nsswitch.conf
file /usr/etc/authselect/user-nsswitch.conf is not owned by any package
ok, so it was moved there, as @siosm pointed out, from /etc:
[eivind@lightpad ~]$ rpm -qf /etc/authselect/user-nsswitch.conf
authselect-libs-1.2.4-2.fc35.x86_64
And there we have it. It does not fully answer the question, though - how/when/by whom was it put there 
This would greatly enhance my ability to adminstrate an rpm-ostree managed system. I’ve been looking through the journal logs but have not yet found the fitting info to link a file to its creating layer.
Similar usecase:
Find the reason mesa-demos was installed. It’s not part of the base image and has not been requested - so it has to be a dependency/recommendation of a layered package - but which?
~ ❯❯❯ rpm -qa "mesa-demos" # to confirm its installation
mesa-demos-8.4.0-12.20210504git0f9e7d9.fc35.x86_64
~ ❯❯❯ rpm-ostree remove mesa-demos # to confirm it's really not explicitly requested
error: Package/capability 'mesa-demos' is not currently requested
~ ❯❯❯ rpm -q --whatrequires mesa-demos
no package requires mesa-demos
~ ❯❯❯ rpm -q --whatrecommends mesa-demos
no package recommends mesa-demos
Is this information lost or am I missing something here?
Installed on my Silverblue F34 as well, I didn’t install it and nothing requires/recommends it. Honestly wouldn’t have noticed it if @mershl was discussing it here. Wonder how many more are there now.
Just curious @mershl , do you have a Radeon graphics GPU? I do, perhaps the radeon layered packages I installed pulled it in?
Yes. Using an AMDGPU with mesa. But… let’s find a way to find the “proxy requester” without trial and error. There has to be a way to retrace the creation of a deployment.
Isn’t there an Anaconda log left as a result of the deployment of install? There is the diff command to see what is different between two deployments with rpm-ostree. But I’m not sure we could trace the steps, of course it should be in journalctl b-1 I would think.
What packages do you have overlayed? Packages can also indirectly require other package via path to files and thus pull them without having them explicitly listed in Requires & Recommends.
Packages can also indirectly require other package via path to files and thus pull them without having them explicitly listed in Requires & Recommends.
Is there a way to retrace this behaviour with the example mesa-demos?
What packages do you have overlayed?
Hi @siosm, thank you for your feedback. Don’t get me wrong. I try to find a way to solve this in a way so it can be used in any kind of these situations. Is it possible to find the culprit without trial & error or background knowledge on the packages?
Sure, I understand what you want to do, but sometimes it’s easier to figure out how to that when you already know the answer and what to look for. Anyway, let’s try:
$ for f in $(rpm -ql mesa-demos); do dnf repoquery --whatrequires $f; done
With a bruteforce method (iterating over all overlay packages, remove single overlay, print db diff, cleanup -p, repeat) I found the culprit overlay: goverlay (resolved to goverlay-0.6.3-1.fc34.x86_64).
827x Last metadata expiration check: 0:xx:yy ago on Mo 11 Okt 2021 16:31:36 CEST.
<no other results were printed>
Made a mistake here. The correct command should be (no dashes before whatrequires):
$ for f in $(rpm -ql mesa-demos); do dnf repoquery whatrequires $f; done
EDIT: We need the dashes. Weird that this does not show up.
Ahhh, Goverlay uses mesa-demos to show some previews while configuring the overlay. The recommendation makes sense.
Back to topic.
I would’ve expected this command to show the relation goverlay --recommends-> mesa-demos:
~ ❯❯❯ rpm -q --whatrecommends mesa-demos-8.4.0-9.20181118git1830dcb.fc34.x86_64
no package recommends mesa-demos-8.4.0-9.20181118git1830dcb.fc34.x86_64
~ ❯❯❯ rpm -q --whatrecommends mesa-demos
no package recommends mesa-demos
Let’s take the opposite direction:
~ ❯❯❯ rpm -q --recommends goverlay
git(x86-64)
mesa-demos(x86-64)
vkBasalt(x86-64)
vulkan-tools(x86-64)
Which brings up a “solution”:
~ ❯❯❯ rpm -q --whatrecommends "mesa-demos(x86-64)"
goverlay-0.6.3-1.fc34.x86_64
EDIT: I do not have a Fedora Workstation installation right now. Does Fedora Workstation show the same issue of using different identifiers for dnf/yum installed rpms?
I learned about it yesterday:
rpm -q --what<tab>
--whatconflicts --whatenhances --whatobsoletes --whatprovides --whatrecommends --whatrequires --whatsuggests --whatsupplements
And dnf also adds --whatdepends.
Just set up a fresh Fedora Workstation VM. dnf installed rpms act exactly the same in regards to the rpm -q commands.
What’s unfortunate is that the intuitive workflow only works in the “wrong” direction. Going back to the usecase: “Find the requested layered package which overlays mesa-demos via a hard (requires) or weak (recommends) dependency”
Users intuitive thought: Let’s check what requires or recommends mesa-demos:
$ rpm -q --whatrequires mesa-demos
no package requires mesa-demos
$ rpm -q --whatrecommends mesa-demos
no package recommends mesa-demos
→ User gives up as there does not seem to be a package that requires/recommends their package.
Going the opposite direction. Keep in mind: This requires that the user already knows that goverlay has a recommends relation to mesa-demos, which the user does not know at this point.
$ rpm -q --recommends goverlay
git(x86-64)
mesa-demos(x86-64)
vkBasalt(x86-64)
vulkan-tools(x86-64)
$ rpm -q --whatrecommends "mesa-demos(x86-64)"
goverlay-0.6.3-1.fc34.x86_64
rpm seems to switch between different identifiers… for an intuitive solution recommendations/requirements would have to be resolved to the actual package/package name (allowing rpm -q --whatrequires mesa-demos).
Or maybe there’s a trick/option to make the intuitive workflow work?