Package: installation-birthday
Version: 9
Severity: normal

[~]# installation-birthday 
I: Installation date: 2018-06-07

But that's today!  I'm quite certain I'd remember reinstalling (and it'd
take weeks of intense work to make it as messy as it is...).  Looking at
available evidence (/etc/hostname and a bunch of similar files), I see it
was d-i reinstalled on 2015-02-26, although plenty of edited config files
are restored older (winner being /etc/issue from 2002-11-16).

Looking under the hood, I see that installation-birthday knows mostly about
ext4.  I have only one /-on-ext4 box, on it it says:
I: Installation date: 2012-12-31
Hmm, nope.  This particular system is tricky, as it was installed as woody. 
/ is on md RAID1, its current disks' SMART says 31322 and 41410 hours
respectively, that's Sep 2013.  So _some_ md-raid operations alter the date
while other don't; it's possible there was indeed a mkfs+copy involved.  If
so, then on ext3/4 (but not other filesystems!), installation-birthday gives
at least something usable (last filesystem migration), but that's still not
installation.

Your program then does some fallbacks:
  '/var/log/installer',
    Would work if installed via d-i but not purged, looks good.  It's
    somehow absent on all boxen I checked, though.
  '/var/log/bootstrap.log',
    Is there on a 2016 machine, not on a 2013 one.
  '/var/lib/vim',
    Only heretics using a particular bad editor will have this...
  '/lost+found',
    ext4 dropping, won't be present on other filesystems.  And its mtime
    will change every time fsck actually finds something.
  '/root',
    Assumes you never do maintenance as root.
  '/etc/machine-id',
    Dbus only thus won't be present on servers.

Turns out the bogus date came from /root -- it'd be good if you dropped it
from the list.  Or possibly used the oldest mtime rather than the mtime of
the first file you find.


Thus, I'd recommend the following two changes:
* dropping /root and possibly /lost+found (or taking only oldest mtime)
* documenting that filesystem migration often resets the date
Or possibly a note that the program is meant for fun and the reported date
shouldn't be used for anything vital. :)


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages installation-birthday depends on:
ii  e2fsprogs  1.44.2-1
ii  python3    3.6.5-3

installation-birthday recommends no packages.

installation-birthday suggests no packages.

-- no debconf information

Reply via email to