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

control: reassign -1 dpkg
control: retitle -1 dpkg: stat fails on 32-bit systems when access time is bogus

Hi,

On 2023-10-25 23:29, Simon McVittie wrote:
> 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.

I agree with the explanation.

> 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.

Yes, and that also means there is nothing that can be done on the glibc
side as the API is already provided started with Debian 12.

> 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.

The other alternative is to add support at the dpkg level, just like it
is already the case for some packages like coreutils. I am therefore
reassigning the bug to dpkg, but I fully understand if it get tagged as
wontfix until 64-bit timestamps are supported at the distribution-wide
level.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email protected]                     http://aurel32.net