Is it possible to find the "creator"/"owner" of a deployed file?

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?

1 Like

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:

  • A file included or created from the config. See workstation-ostree-config.
  • A file generated, modified or created by RPM scriptlets that are run during the image build.
  • A file 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.

1 Like

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 :slight_smile:.

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: Issues - releng/failed-composes - Pagure.io. I don’t know where the logs from successful composes are :confused:.

Existing documentation that I know of:

1 Like

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 :slightly_smiling_face:

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.

https://src.fedoraproject.org/rpms/goverlay/blob/rawhide/f/goverlay.spec#_26

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?

1 Like

I learned about it yesterday:

rpm -q --what<tab>
--whatconflicts    --whatenhances     --whatobsoletes    --whatprovides     --whatrecommends   --whatrequires     --whatsuggests     --whatsupplements

And dnf also adds --whatdepends.

1 Like

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?