I am seeing this too. It is quite annoying.
`etckeeper-dnf5` adds hooks to call etckeeper for certain dnf commands. The only think I can think of is that bash-completion hooks into call dnf to assist with completion, and that either dnf changed to call the hooks that etckeeper bound itself to, or bash-completion changed so that completion now uses different syntax to call dnf.

I never experienced the issue before.

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

(In reply to Daniel Wang from comment #1)
> I am seeing this too. It is quite annoying.
> `etckeeper-dnf5` adds hooks to call etckeeper for certain dnf commands. The
> only think I can think of is that bash-completion hooks into call dnf to
> assist with completion, and that either dnf changed to call the hooks that
> etckeeper bound itself to, or bash-completion changed so that completion now
> uses different syntax to call dnf.
> 
> I never experienced the issue before.

It changed with DNF5. etckeeper's DNF integration got a complete rework at that time. (Because it had to; the Python bits of DNF it used to hook into are gone, so everything is triggered shell scripts now.)

With DNF5, etckeeper-dnf5 installs /etc/dnf/libdnf5-plugins/actions.d/etckeeper.actions which contains:

pre_base_setup:::raise_error=1:/usr/bin/sh -c /usr/bin/etckeeper\ pre-install\ \|\ /usr/bin/sed\ -e\ 's/^/log.INFO=/'
post_transaction::::/usr/bin/sh -c /usr/bin/etckeeper\ post-install\ \|\ /usr/bin/sed\ -e\ 's/^/log.INFO=/'

So, yeah, etckeeper's pre-install is hooked into every invocation of DNF, regardless whether the user is running as root or some other user. And pre-install attempts to redirect the output of some `etckeeper list-installed` commands into /var/cache/etckeeper/ files, which can't be done as a regular user.

So,

(1) etckeeper-dnf5 definitely shouldn't be configuring DNF to run etckeeper's pre-install EVERY time it starts up, for any reason, as any user.

(2) etckeeper's pre-install should probably have a permissions check before attempting the redirects into `/var/cache/`, though that's only really a problem because of (1) and the fact that it's not being triggered in preparation for an install transaction, which is when it's intended to be used.

Unfortunately, access to etckeeper's maintainers seems to be limited to the forums at https://etckeeper.branchable.com/ (no public issue tracker or code repository / pull request access), and they don't seem to be monitoring that forum too closely. 2 months ago I posted about a different issue unrelated to the DNF5 integration (it has to do with how they parse the output of an rpm command), and there's been no response:

https://etckeeper.branchable.com/forum/50vcs-commit_causes_error_messages_during_DNF_runs_on_RPM__47__DNF_systems/

Er, two corrections, the etckeeper repo is accessible at https://git.joeyh.name/index.cgi/etckeeper.git/ (though it's a self-hosted gitweb without any sort of forge-like pull request workflow), and the etckeeper-dnf5 actions config isn't currently part of the etckeeper distribution, it's being added by the Fedora packaging. So, that's nothing to do with the etckeeper devs, really.

thm (the Fedora maintainer) nevertheless posted to the forum discussion about DNF5 integration:

https://etckeeper.branchable.com/forum/RFE:_please_add_support_for_DNF_5/#comment-2173d2c3494d110d4fe932273e59218f

citing this bug, among others, and proposing that the pre-install hook be moved from pre_base_setup to goal_resolved to at least somewhat mitigate this issue.

But that was 10 months ago, there was (again) no response from any etckeeper developers, and no changes were made despite thm currently having total downstream control over the contents of /etc/dnf/libdnf5-plugins/actions.d/etckeeper.actions.

(It looks like the changes thm was proposing would also require complementary changes in etckeeper, so I guess without those being done or even discussed everything has maintained the unfortunate status quo.)

Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.