Debian Bug report logs - #1054552
dpkg: stat fails on 32-bit systems when access time is bogus

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jarek Czekalski <jarekczek@poczta.onet.pl>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: glibc: stat fails when access time is bogus

Date: Wed, 25 Oct 2023 20:53:57 +0200

Package: libglib2.0-0:i386
Severity: normal
X-Debbugs-Cc: jarekczek@poczta.onet.pl

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***

   * What led up to the situation?
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

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.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-20-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Message #10 received at 1054552@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Jarek Czekalski <jarekczek@poczta.onet.pl>, 1054552@bugs.debian.org

Cc: libc6@packages.debian.org

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

Date: Wed, 25 Oct 2023 23:29:42 +0100

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

Message #17 received at 1054552@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: Jarek Czekalski <jarekczek@poczta.onet.pl>

Cc: Simon McVittie <smcv@debian.org>, 1054552@bugs.debian.org, dpkg@packages.debian.org

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

Date: Thu, 26 Oct 2023 19:27:48 +0200

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

Message #26 received at 1054552@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Aurelien Jarno <aurel32@debian.org>

Cc: Jarek Czekalski <jarekczek@poczta.onet.pl>, Simon McVittie <smcv@debian.org>, 1054552@bugs.debian.org, dpkg@packages.debian.org

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

Date: Fri, 27 Oct 2023 02:22:05 +0200

Hi!

On Thu, 2023-10-26 at 19:27:48 +0200, Aurelien Jarno wrote:
> control: reassign -1 dpkg
> control: retitle -1 dpkg: stat fails on 32-bit systems when access time is bogus

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

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

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

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

Right, I think this would be ideal, otherwise the entire port becomes
pretty useless if dpkg itself cannot even be used. There are several
things to take into account though:

  - autoconf with the AC_SYS_YEAR2038 macro has not been released yet,
    so I'll need to implement a replacement for that, which I guess I
    might need to do anyway otherwise that would involve requiring a
    too recent autoconf version.
  - This could wait for the time64 transition, but then this will
    leave the i386 port broken (as is supposed to be intended by
    that transition), which means this report could not be solved,
    but that seems less than ideal as I've mentioned before, because
    that means the port is dead at that point. So…
  - Building dpkg with time64 support *everywhere* could be a problem
    when the shared libraries it uses or it might use in the future are
    not also built with time64 support (the default for i386 based on
    the proposed time64 plan in Debian). I've done a brief check over
    all currently potentially used libraries and their public
    interfaces:
    + libmd → ok (no types involving time)
    + libselinux → ok
    + libz → ok
    + libbz2 → ok
    + liblzma → ok
    + libzstd → ok
    + libps → Hurd library, might be a problem, need to check further
    + libsocket → Solaris library (not relevant in Debian)
    + libkvm → BSD library (not relevant in Debian, several BSDs
               force-switched to time64 anyway)
    + libcurses → seems ok on a quick skim
    And prospective ones:
    + libaudit → ok
    + libacl → ok
    + libcap → ok
  - If none of these libraries get built with time64 on all 32-bit
    arches (including i386), then dpkg might still fail due to
    internal failures in those libraries.

So I guess once the first part is done I _could_ build dpkg with time64
on *all* 32-bit arches that support it (including i386), although if
(like it looks like) the ABIs for the listed shared libraries are not
affected by time64, then it might be way better to also build these
libraries everywhere with time64 anyway, because that should not affect
backwards compat for its current users, and if new symbols get added
with time types then those would not affect old binary programs that
people are concerned about, and would still make it safe to use the
libraries.

Thanks,
Guillem

Send a report that this bug log contains spam.