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
aurelien@aurel32.net http://aurel32.net
Reply to: