Alexandre Takacs's picture

Hello

I have some applicances I have built using TK Core v12 (Debian 6).

I have seen recently issues after doing an apt-get upgrade - I get errors:

Processing triggers for python-central ...
fatal: object f587ae1e9fe456ed26c198ad17b9ea1ac1f58c6d is corrupted
error: failed to run reflog
E: Problem executing scripts DPkg::Post-Invoke 'if [ -x /usr/sbin/etckeeper ]; then etckeeper post-install; fi'
E: Sub-process returned an error code

Thisi is happening with any apt-get install. I have checked that /usr/sbin/etckeeper exists and is executable

This is happening on all TK applicances (ok I have stopped doing upgrades after seeing this problem on 3 out of 3 upgraded machines...).

Any idea what's happening ?

Thanks

Forum: 
Jeremy Davis's picture

It sounds like you can recreate it, but I just tested 2 different apliances and ran apt-get update && apt-get upgrade successfully...

Also what platform are you using? The only vaguely relevant info I could find via google suggests that git corruption is the reason for your error (etckeeper uses git to store the original config files). It seems that often the corruption is associated with HDD failure.

Alexandre Takacs's picture

Also what platform are you using? The only vaguely relevant info I could find via google suggests that git corruption is the reason for your error (etckeeper uses git to store the original config files). It seems that often the corruption is associated with HDD failure.

Well these are all VMWare virtual machines running the TKL appliances (one is the "stock" DocuWiki as downloaded from TK, one is my "famous" OpenERP custom appliance using PostgreSql again as downloaded from TK, etc). Nothing fancy / unusual as far as I can tell.


Jeremy Davis's picture

Instructions are in the docs (so no link handy but should be easy to find).

I'd also run a fsck/chkdsk on the hardware HDD. I have heard of minor host OS HDD corruption causing issues like this.

I don't currently have VMware installed anywhere but have successfuly used the VM images in VirtualBox without encountering this issue so if the images aren't corupted then I'd definately be checking out your hardware. It may also be worth trying to install from ISO and see if you get the same issues.

Alexandre Takacs's picture

will run some checks but the machines are hosted on completely different underlying hosts with high end SAN storage - would be most suprised if it is a hardware issue.


Jeremy Davis's picture

Perhaps it's something to do with interaction between VMware and ext4/LVM? Like I said you could try install from ISO. You could also try not using LVM...

Add new comment