Bug#1124811: dpkg 1.22.21 for i386 does not run on real 32-bit-hardware like amd-geode

Package: dpkg
Version: 1.22.21
Severity: important

Dear Maintainer,

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



    * What led up to the situation?
    * What exactly did you do (or not do) that was effective (or
      ineffective)?
    * What was the outcome of this action?


I had a machine with amd-geode-processor running Devuan 5 (daedalus) 
(equivalent to Debian Bookworm). Updating this machine to Devuan 6 
(excalibur)(equivalent to debian Trixie) failed in the process after 
dpkg was updated to 1.22.21.

With 1.22.21 each call to dpkg produces this messages on the system-console:

 >>>
Jan  6 17:57:50 melone.lissner.home kernel: [  961.268404] traps: 
dpkg[13518] trap invalid opcode ip:4d8a20 sp:bfb03fac error:0 in 
dpkg[4d8000+2d000]
Jan  6 17:57:50 melone.lissner.home kernel: [  961.268404] traps: 
dpkg[13518] trap invalid opcode ip:4d8a20 sp:bfb03fac error:0 in 
dpkg[4d8000+2d000]
Jan  6 17:57:50 melone.lissner.home kernel: [  961.712470] traps: 
dpkg[13519] trap invalid opcode ip:41ca20 sp:bff2e80c error:0 in 
dpkg[41c000+2d000]
Jan  6 17:57:50 melone.lissner.home kernel: [  961.712470] traps: 
dpkg[13519] trap invalid opcode ip:41ca20 sp:bff2e80c error:0 in 
dpkg[41c000+2d000]
Jan  6 17:57:55 melone.lissner.home kernel: [  966.277087] traps: 
dpkg[13521] trap invalid opcode ip:40ca20 sp:bff1a79c error:0 in 
dpkg[40c000+2d000]
Jan  6 17:57:55 melone.lissner.home kernel: [  966.277087] traps: 
dpkg[13521] trap invalid opcode ip:40ca20 sp:bff1a79c error:0 in 
dpkg[40c000+2d000]
Jan  6 17:58:04 melone.lissner.home kernel: [  975.913874] traps: 
dpkg[13525] trap invalid opcode ip:47fa20 sp:bf991c9c error:0 in 
dpkg[47f000+2d000]
Jan  6 17:58:04 melone.lissner.home kernel: [  975.913874] traps: 
dpkg[13525] trap invalid opcode ip:47fa20 sp:bf991c9c error:0 in 
dpkg[47f000+2d000]
Jan  6 20:03:15 melone.lissner.home kernel: [ 8484.912451] traps: 
dpkg[19563] trap invalid opcode ip:4dba20 sp:bfa0e09c error:0 in 
dpkg[4db000+2d000]
Jan  6 20:03:15 melone.lissner.home kernel: [ 8484.912451] traps: 
dpkg[19563] trap invalid opcode ip:4dba20 sp:bfa0e09c error:0 in 
dpkg[4db000+2d000]
Jan  6 20:03:40 melone.lissner.home kernel: [ 8509.962567] traps: 
dpkg-deb[19568] trap invalid opcode ip:49aa20 sp:bfe727dc error:0 in 
dpkg-deb[49a000+19000]
Jan  6 20:03:40 melone.lissner.home kernel: [ 8509.962567] traps: 
dpkg-deb[19568] trap invalid opcode ip:49aa20 sp:bfe727dc error:0 in 
dpkg-deb[49a000+19000]
<<<
(As you can see the numbers vary for each dpkg invocation, except for 
the "+2d000"-part)

I'm pretty sure this is hardware-dependend: The amd-geode-machine is 
running on a NFS-root. The NFS-server is a VM on a more up-to-date-CPU. 
This VM is also running the i386 architecture. When I do a "chroot" on 
the server to the directory of the amd-geode-machine and try to call 
dpkg it works withou "illegal opcode".


Reverting dpkg back to 1.21.22 solved this problem.


 >>>
root@melone:~# lscpu

Architecture:           i586

   CPU op-mode(s):       32-bit

   Address sizes:        32 bits physical, 32 bits virtual

   Byte Order:           Little Endian

CPU(s):                 1

   On-line CPU(s) list:  0

Vendor ID:              AuthenticAMD

   Model name:           Geode(TM) Integrated Processor by AMD PCS

     CPU family:         5

     Model:              10

     Thread(s) per core: 1

     Core(s) per socket: 1

     Socket(s):          1

     Stepping:           2

     BogoMIPS:           996.03

     Flags:              fpu de pse tsc msr cx8 sep pge cmov clflush mmx 
mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall

Caches (sum of all):

   L1d:                  57 KiB (1 instance)

   L1i:                  57 KiB (1 instance)

   L2:                   128 KiB (1 instance)

Vulnerabilities:

   Itlb multihit:        Not affected

   L1tf:                 Not affected

   Mds:                  Not affected

   Meltdown:             Not affected

   Spec store bypass:    Vulnerable

   Spectre v1:           Mitigation; usercopy/swapgs barriers and __user 
pointer sanitization

   Spectre v2:           Mitigation; Full generic retpoline, STIBP 
disabled, RSB filling

   Srbds:                Not affected

   Tsx async abort:      Not affected

root@melone:~#
<<<


    * What outcome did you expect instead?


My expectation would be that 1.22.21 works on the old hardware as the 
1.21.22 has done.



Kind regards
Ekkehard


-- System Information:
Distributor ID: Devuan
Description:    Devuan GNU/Linux 6 (excalibur)
Release:        6
Codename:       excalibur
Architecture: i586

Kernel: Linux 5.8.16-antix.1-486-smp (SMP w/1 CPU thread)
Kernel taint flags: TAINT_DIE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Thank you for using reportbug