Bug#1054552: glibc: stat fails when access time is bogus

[Simon McVittie]

Control: reassign -1 libc6

On Wed, 25 Oct 2023 at 20:53:57 +0200, Jarek Czekalski wrote:
> I tried to upgrade system (apt-get upgrade), but it failed in dpkg:
> 
> Unpacking initscripts (3.06-4) over (2.96-7+deb11u1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/initscripts_3.06-4_all.deb (--unpack):
>  unable to stat './var/log' (which was about to be installed): Value too
> large for defined data type

This is nothing to do with GLib (libglib2.0-0), but I assume you meant
glibc (libc6)? Quoting the rest of the bug report below for glibc
maintainers:

> stat /var/log
> 
>   File: /var/log
>   Size: 4096            Blocks: 8          IO Block: 4096 directory
> Device: 8,1     Inode: 2752691     Links: 12
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ root)
> Access: 2040-05-10 23:31:40.285032309 +0200
> Modify: 2023-10-25 16:03:42.313742411 +0200
> Change: 2023-10-25 16:03:42.313742411 +0200
>  Birth: 2017-02-27 09:46:56.739719147 +0100
> 
> This date (2040) causes dpkg to fail. The workaround is correcting it by
> touch /var/log.
> 
> Running system with bogus date (2040).
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
> touch /var/log
>    * What was the outcome of this action?
> dpkg started working
>    * What outcome did you expect instead?
> dpkg should work with strange date or give a better message. Maybe just
> documentation (for stat) should be fixed and suggest problems with dates.
> 
> Current outcome is as follows: apt-get suddenly fails with a cryptic message
> (initially it was "unable to stat '.'" instead of /var/log). It may be
> extremely difficult to diagnose the issue.

It is not possible for 32-bit stat() to work correctly on 32-bit systems
with dates beyond 2038, because the timestamp will not fit in the data
type used. The only solution would be for the program in question (in
this case, dpkg) to be compiled with support for 64-bit timestamps.

Your bug report seems to be from an upgrade from Debian 11 to Debian 12,
and Debian 11's glibc version did not support APIs that provide 64-bit
timestamps on 32-bit systems, so Debian 11's dpkg cannot support that
either.

Debian 12's glibc does, but that will only help you after fully upgrading
to Debian 12, at which point you will have Debian 12 versions of glibc
and dpkg.

Unfortunately, I don't think there's necessarily anything that can be done
here, beyond the general move towards supporting 64-bit timestamps
distribution-wide that is already in progress.

    smcv