etckeeper with git breaks update-manager

[Borim]

I have configured etckeeper to use git. It works fine if I use apt-get or synaptic paket manager.

But when the update-manger install new packet versions it ends with an "installation falied" message. When I check the status of the git repository in the etc directory, some changes are not commited, e.g.:

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

 modified: apt/apt.conf.d/01autoremove-kernels
 modified: init.d/resolvconf

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: etckeeper 1.9ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-29.53-generic 3.13.11.2
Uname: Linux 3.13.0-29-generic x86_64
NonfreeKernelModules: wl tbs6982fe tbs6680fe tbs6923fe tbs6985se tbs6928se tbs6982se tbs6991fe tbs6618fe tbs6922fe tbs6928fe tbs6991se
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Jun 28 09:42:13 2014
InstallationDate: Installed on 2014-03-30 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140329)
PackageArchitecture: all
SourcePackage: etckeeper
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.etckeeper.etckeeper.conf: 2014-03-30T16:33:03.109833

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[tilo kremer (ubunteelo)]

I am getting the same symptoms, but the error message is slightly more verbose:

fatal: $HOME not set

*** Please tell me who you are.

Run

  git config --global user.email "<email address hidden>"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@xxxxx.(none)')

[Martin Günther (launchpad-domain-the-phoenix)]

I get the same error message as tilo kremer. Note that this only occurs in update-manager; running "apt-get update" from the command line works fine. Also, $HOME and the git configs are set both for normal user and root.

Using a german locale an zsh, if that's got anything to do with it.

[Borim (borim)]

I am using also a german local. Also the fault does not happen every update. Sometimes it works without a fault, but I did not recognize any schema, when the fault happen and when not.

[Manzuk István (imanzuk)]

+1 for the "Please tell me who you are." issue, with Hungarian locale and bash.

[Martin Weis (martin-weis-newsadress)]

Related to bug #1267564 (duplicate)
Proposed solution as found on
http://triple-networks.com/2014/07/20/etckeeper-git-issue-on-trusty/

To prevent this, make sure “/etc/hosts” contains a FQDN for the current hostname of your machine.

[...]

127.0.1.1 ursula.example.com ursula

[Borim (borim)]

I think the two bugs are only related. In #1267564 every change with apt, synaptic or update-manager leads to an error, as username and email are not set. As changing packages require root privilege the username and email have to be configured for the root login.
When this is done altering packages with apt, synaptic works. Until now I had never a problem when using apt or synaptic.

This bug report is about a problem with the update-manager and etckeeper. Although username and email are set in git for the root login, updating packages with the update-manager fails sometimes. Most of the time the updates are applied without any errors.

[Mikko Rantalainen (mira)]

Am I then only one thinking that etckeeper should have post-install script to request git user.name and user.email fields to be filled for root if those are missing? I know how to do that manually but I guess random etckeeper user may not know that those are needed and it would be much better user experience to ask for those during etckeeper install.

[Martin Günther (launchpad-domain-the-phoenix)]

@Mikko Rantalainen: This bug has nothing to do with whether user.name and user.email have been set for root or not, but I like your idea, so please file a different bug report for that.

[Christian Ehrhardt  (paelzer)]

Hi, sorry to wake up old bugs, but I'm trying to clean up some older bugs.
As I've analyzed in [1] nowadays the user/email/FQDN seems to be more stable and no more cause that fatal issues. But as Martin already outlined that was more the topic of bug 1267564 while this here is about something that seems to be special about unattended-upgrades

I've done a few unattended upgrades (with massive sets of packages to hopefully include what was the reason to break it) and do-release-upgrades (those were mentioned to be a problem in other places) but all of them worked fine so far. Unfortunately Borim said in comment #5 that it happens sometimes, so I can't be sure that means we are good now.

To act on this (seems silly after so much time of nothing happening, but there isn't anything else one could act on as-is) I have to ask all of you (8 people marked as affected) if you had:
a) found this resolved by a certain new version?
b) found this resolved by a certain new config?
c) worked around this somehow, if so how?
d) found other hints to the actual root cause since the last update to this bug?
e) In the original report it was mentioned that apt/apt.conf.d/01autoremove-kernels and
   init.d/resolvconf where in half committed state. Was that true for everyone here that
   was affected (=could there be something special with those?)

[1]: https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/1267564/comments/9

[Borim (borim)]

Hi, my workaround was to no longer use etckeeper. So I currently cannot answer your other questions.

As you said the bug is quite old and it is possible, that in the mean time the issue was fixed. As you have tested it, I would treat it as solved.

[Christian Ehrhardt  (paelzer)]

Thanks for your reply Borim, although it has a sad touch since you had to switch away.
I've thrown a few more test servers of mine into using etckeeper, if there is anything left I'd hope they will expose a remaining issue.

If nothing else happens that confirms the bug still exists the bug will auto-expired in ~60 days and then go to incomplete which is the right state. That is even more correct than setting fix released as have never explicitly found and fixed what it was back then.

[Armin Stebich (lordofbikes)]

I'm subscribed to this issue, so I assume I was affected by it too. I think I can vaguely remember.
I still use etckeeper with git and I surely did the release upgrade from 18.04 to 20.04 without issues.
So for me and my configuration I can confirm that this issue is solved in 18.04/20.04.

[Launchpad Janitor (janitor)]

[Expired for etckeeper (Ubuntu) because there has been no activity for 60 days.]