On Fedora 40 etckeeper commit pending changes prior to any dnf package install and commit again changes following the installation. I've updated from Fedora 40 to 41. Since the update this behavior does work anymore. It's like etckeeper is not called by dnf. Dnf log does show anything regarding an etckeeper plugins. I don't know if it is due to the switch to dnf5 or not. Packages etckeeeper-dnf and python3-dnf are installed. I've tried reinstall the package but it changes nothing. Reproducible: Always Steps to Reproduce: 1. Install etckeeper and its dependancies 2. Create a file with random content in /etc 3. Install any package with dnf Actual Results: You won't see any commit in the git repository of /etc Expected Results: See 2 commits in the git repository with the following messages : - saving uncommitted changes in /etc prior to dnf run - committing changes in /etc made by "-bash" After the update to fedora 41, I've noticed 2 files were still in /var/cache/etckeeper/ : - packagelist.fmt - packagelist.pre-install During my tests I've tried to keep them or removed them but nothing changes.
This is due to Fedora switching to dnf5 for Fedora 41 - the etckeeper dnf plugin is not ported yet. It just came up in the ELN meeting (we're discussing what porting work is needed to make everything DNF5 compatible for the upcoming CentOS Stream 11 / RHEL 11) so I'll get a tracking bug created for Fedora to drive this.
Reported upstream: https://etckeeper.branchable.com/forum/RFE:_please_add_support_for_DNF_5/
I tried to use Actions plugin[1] to run etckeeper via pre and post installation hooks like this: ``` # cat /etc/dnf/libdnf5-plugins/actions.d/etckeeper.actions pre_transaction::::etckeeper pre-install post_transaction::::etckeeper post-install ``` It seems to work, but but when `etckeeper pre-install` fails (with non zero return code), there is no way propagate this error to prevent dnf to continue and start the transaction. This is a problem eg. when you use AVOID_COMMIT_BEFORE_INSTALL=1. So if you use AVOID_COMMIT_BEFORE_INSTALL=0, you can try that etckeeper.actions approach as a workaround until there is a proper libdnf5 plugin. When I have a minimal working libdnf5 plugin, I will share it here. That said, I'm also considering reaching out to the maintainers of the actions plugin, as if they will be ok with extending error handling, etckeeper dnf5 integration could be implemented in a simple 2 line config file which the upstream could easily accept. [1] https://dnf5.readthedocs.io/en/latest/libdnf5_plugins/actions.8.html
(In reply to Martin B. from comment #3) > reaching out to the maintainers of the actions > plugin, as if they will be ok with extending error handling, etckeeper dnf5 > integration could be implemented in a simple 2 line config file which the > upstream could easily accept. https://github.com/rpm-software-management/dnf5/issues/2023
With https://github.com/rpm-software-management/dnf5/issues/2023 implemented (since dnf5 5.2.11.0, Actions plugin version 1.4), it's possible to create a proper etckeeper plugin using Actions plugin config file. I'm proposing it upstream here: https://etckeeper.branchable.com/forum/RFE:_please_add_support_for_DNF_5/#comment-1b321f85ebaa5a57fa04a00c50c8f63e When it will reach fedora, we will need to create a new subpackage etckeeper-dnf5 which will provide etckeeper.actions file as /etc/dnf/libdnf5-plugins/actions.d/etckeeper.actions
FEDORA-2025-ad7345b037 (etckeeper-1.18.22-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-ad7345b037
FEDORA-2025-ad7345b037 (etckeeper-1.18.22-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Thanks for looking into this! I created the new dnf5 subpackge in rawhide. The proposed action file does not work though, as, in the current implementation of the actions plugin, output lines of the executed action need to follow a certain output format. Therefore, I propose (and will implement in rawhide first) this action file: # to be placed in /etc/dnf/libdnf5-plugins/actions.d # requires dnf5 5.2.11.0 or later 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=/' It will prepend log.INFO= to any output line produced by etckeeper. Seems to work in my first tests. Feel free to test and propose other solutions :)
FEDORA-2025-2d4bfb5e0d (etckeeper-1.18.22-3.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-2d4bfb5e0d
FEDORA-2025-24499503a9 (etckeeper-1.18.22-3.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-24499503a9
FEDORA-2025-2d4bfb5e0d has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-2d4bfb5e0d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-2d4bfb5e0d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-24499503a9 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-24499503a9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-24499503a9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
With this new version of the package I see this, which has never happened before: $ dnf check-upgrade /etc/etckeeper/pre-install.d/10packagelist: line 4: /var/cache/etckeeper/packagelist.pre-install: Permission denied /etc/etckeeper/pre-install.d/10packagelist: line 5: /var/cache/etckeeper/packagelist.fmt: Permission denied this is the same for 2 different systems. One of them also shows this when I run this: $ sudo dnf upgrade etckeeper warning: hardlinked files could cause problems with git: ./hosts ./sysconfig/networking/profiles/default/hosts ./sysconfig/networking/profiles/default/ifcfg-em1 ./sysconfig/networking/devices/ifcfg-em1 hosts sysconfig/networking/devices/ifcfg-em1 sysconfig/networking/profiles/default/hosts sysconfig/networking/profiles/default/ifcfg-em1 This message has never appeared before, although I will say I was unaware of these hardlinked files and perhaps they should not be there. etckeeper has always been reliable and worked as far as I can tell. This update is the first problem I've noticed with it in some years.
The previous comment should also say I have these packages installed: etckeeper-dnf-1.18.22-3.fc42.noarch etckeeper-1.18.22-3.fc42.noarch etckeeper-dnf5-1.18.22-3.fc42.noarch
FEDORA-2025-24499503a9 (etckeeper-1.18.22-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-2d4bfb5e0d (etckeeper-1.18.22-3.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Brian Morrison from comment #13) > With this new version of the package I see this, which has never happened > before: > > $ dnf check-upgrade > /etc/etckeeper/pre-install.d/10packagelist: line 4: > /var/cache/etckeeper/packagelist.pre-install: Permission denied > /etc/etckeeper/pre-install.d/10packagelist: line 5: > /var/cache/etckeeper/packagelist.fmt: Permission denied > > this is the same for 2 different systems. One of them also shows this when I > run this: This problem is new to me. I suspect that you are running check-upgrade as non-root? Need to investigate if and what can be done about this. > $ sudo dnf upgrade > > etckeeper warning: hardlinked files could cause problems with git: > ./hosts > ./sysconfig/networking/profiles/default/hosts > ./sysconfig/networking/profiles/default/ifcfg-em1 > ./sysconfig/networking/devices/ifcfg-em1 > hosts > sysconfig/networking/devices/ifcfg-em1 > sysconfig/networking/profiles/default/hosts > sysconfig/networking/profiles/default/ifcfg-em1 > > This message has never appeared before, although I will say I was unaware of > these hardlinked files and perhaps they should not be there. As far as I know this warning was always there, but maybe it was swallowed somewhere... It comes from the etckeeper itself, and the README mentions it: https://etckeeper.branchable.com/README/ section VCS limitations. See also https://bugzilla.redhat.com/show_bug.cgi?id=684548 As a side note: maybe switching to NetworkManager could be an option? ;) > etckeeper has always been reliable and worked as far as I can tell. This > update is the first problem I've noticed with it in some years. Sorry about that. I am maintaining it in Fedora since 2010 or so. Current changes are induced by the switch to DNF5, which we cannot ignore... (Or, if we did, everything would look nice, but etckeeper simply wouldn't do its job).
If I run: sudo dnf check-upgrade then the permission denied problem goes away. I think this is expected as: $ ls -ld /var/cache/etckeeper/ drwxr-xr-x. 1 root root 76 Jul 24 10:44 /var/cache/etckeeper/ which means only root can write to this directory. I will look into the hardlink problem, the system in question has been upgraded continuously from whatever Fedora Core version was current in 2007, so it doesn't surprise me that some odd things have crept in over the years.
The problem iwt h(In reply to Thomas Moschny from comment #17) > (In reply to Brian Morrison from comment #13) > > With this new version of the package I see this, which has never happened > > before: > > > > $ dnf check-upgrade > > /etc/etckeeper/pre-install.d/10packagelist: line 4: > > /var/cache/etckeeper/packagelist.pre-install: Permission denied > > /etc/etckeeper/pre-install.d/10packagelist: line 5: > > /var/cache/etckeeper/packagelist.fmt: Permission denied > > > > this is the same for 2 different systems. One of them also shows this when I > > run this: > > This problem is new to me. I suspect that you are running check-upgrade as > non-root? Need to investigate if and what can be done about this. Oh right, etckeeper plugin won't work when you run dnf as non root. And that's ok as it is expected to do it's job only when dnf updates/removes/installs some packages which can't be done without root permissions. I haven't run into this because I always run dnf under root. That said, it's still a good question whether there are some dnf operations which will work fine without root permissions which the etckeeper actions plugin prevents to run or pollutes with the warning listed above. Mentioned check-upgrade may be one of them. Another cases are repolist or search. One option way to address this would be to change the hook use for pre-install step, so that the plugin is executed later in the dnf flow, hopefully avoiding being run in cases such as check-upgrade or repolist. I selected the pre_base_setup hook because I wanted quick feedback when the repository is not clean[1] (avoiding me waiting for packages to be downloaded only to see etckeeper to fail the transaction later). We can check list of dnf5 hooks[2,3] in dnf transaction flow and see if there is a hook which will happen later in the flow so that dnf search or check-upgrade won't be affected by it while still being early enough for the original purpose of the etckeeper (eg. before package donwload). But it seems that while the current setup produces etckeeper related errors when one uses dnf under non root, it at least doesn't prevent the operation from completing (eg. I can use dnf search as non root and get results fine). [1] https://blog.marbu.eu/posts/2025-04-21-libdnf5-etckeeper#using-actions-plugin-for-etckeeper-integration [2] https://dnf5.readthedocs.io/en/latest/dnf5_workflow.html [3] https://github.com/rpm-software-management/dnf5/blob/main/libdnf5/plugin/iplugin.cpp
(In reply to Thomas Moschny from comment #8) > Thanks for looking into this! > > I created the new dnf5 subpackge in rawhide. The proposed action file does > not work though, as, in the current implementation of the actions plugin, > output lines of the executed action need to follow a certain output format. > > Therefore, I propose (and will implement in rawhide first) this action file: > > # to be placed in /etc/dnf/libdnf5-plugins/actions.d > # requires dnf5 5.2.11.0 or later > 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=/' > > It will prepend log.INFO= to any output line produced by etckeeper. Seems to > work in my first tests. This change seem to break the raise_error propagation on my system. I reported separate bz 2383751 to track it since this bug is already resolved (I would have provided feedback earlier if I noticed it in time). Another interesting thing I observe is that with the change you propose, etckeeper no longer provides useful commit messages. Instead of: ``` * 831f424d committing changes in /etc made by "dnf swap *openh264* noopenh264" * 0caf6d3e committing changes in /etc made by "dnf update -y" ``` which shows what command was used, it is listing the shell command directly: ``` * 625dbed7 committing changes in /etc made by "/usr/bin/sh -c /usr/bin/etckeeper post-install | /usr/bin/sed -e 's/^/log.INFO=/'" * 9304de82 committing changes in /etc made by "/usr/bin/sh -c /usr/bin/etckeeper post-install | /usr/bin/sed -e 's/^/log.INFO=/'" ``` Which are less useful. > Feel free to test and propose other solutions :)