partimage won't run on amd64

Bug #19124 reported by Rick Beldin on 2005-07-22
Affects Status Importance Assigned to Milestone
partimage (Debian)
Fix Released
partimage (Ubuntu)

Bug Description

partimage isn't listed in the package list above

Installed partimage 0.6.4-10 on 5.04 running on a AMD64 using Synaptic manager.
  No errors during installation.

When you run it:

Error: sizeof(DWORD) != 4 (8)
This version has been compiled with an uncompatible version of gcc.

 file /usr/sbin/partimage
/usr/sbin/partimage: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped

apt-cache show partimage
Package: partimage
Priority: optional
Section: universe/admin
Installed-Size: 660
Maintainer: Sergio Rua <email address hidden>
Architecture: amd64
Version: 0.6.4-10
Depends: libbz2-1.0, libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.4.1-3),
libnewt0.51, libpam0g (>= 0.76), libssl0.9.7, libstdc++5 (>= 1:3.3.4-1),
slang1a-utf8 (>> 1.4.9dbs-4), zlib1g (>= 1:1.2.1)
Conflicts: partimage-server (<< 0.6.0), partimage-doc (<= 20020126-6)
Filename: pool/universe/p/partimage/partimage_0.6.4-10_amd64.deb
Size: 196290
MD5sum: 97e3865a28042b625913cb449b18c185

gcc -v
Reading specs from /usr/lib/gcc-lib/x86_64-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc --disable-multilib x86_64-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)

readelf shows:

ELF Header:
  Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Data: 2's complement, little endian
  Version: 1 (current)
  OS/ABI: UNIX - System V
  ABI Version: 0
  Type: EXEC (Executable file)
  Machine: Advanced Micro Devices X86-64
  Version: 0x1
  Entry point address: 0x4043c0
  Start of program headers: 64 (bytes into file)
  Start of section headers: 293208 (bytes into file)
  Flags: 0x0
  Size of this header: 64 (bytes)
  Size of program headers: 56 (bytes)
  Number of program headers: 8
  Size of section headers: 64 (bytes)
  Number of section headers: 26
  Section header string table index: 25

Todd Deshane (deshantm) wrote :

Thank you for reporting this bug.

I was able to reproduce this problem on my
breezy AMD64 box as well.
It is version 0.6.4-10

When running partimage I get the error:
Error: sizeof(DWORD) != 4 (8)
This version has been compiled with an uncompatible
version of gcc

Changing status to New/Confirmed

Lakin Wecker (lakin) wrote :

I just verified that this is still a problem in Dapper with the latest updates. Assigning to the right package, and confirming.

Rocco Stanzione (trappist) wrote :

Still a problem in edgy as well.

Rocco Stanzione (trappist) wrote :

This seems deliberately built into partimage. src/client/main.cpp says:

   if (sizeof(unsigned long int) != 4)
      fprintf (stderr, "Error: sizeof(DWORD) != 4 (%d)\n", sizeof(unsigned long int));
      goto errcheck;

After poking around on google and, it seems partimage is not 64bit clean. It won't compile with -m32 (at least not on my box), and debian apparently doesn't package it for amd64 because of this. Maybe we shouldn't either.

Rocco Stanzione (trappist) wrote :

Alternatively, if we could just package a 32bit binary for amd64, that's rumored to work.

Rocco Stanzione (trappist) wrote :

I can confirm that 32bit partimage binary works, as long as I have a 32bit libnewt and libslang available. It may also be possible to build the package with -m32 on amd64, if we had libnewt and libslang in lib32.

Will 32-bit fix for 64-bit be available in Edgy or not? Or do we have to wait for Edgy+1? Why is partimage not 64-bit clean? Is this is small or large task to fix in the sources...hrmmm
Kristian Hermansen

Alfonso Rodriguez (euoar) wrote :

I hope this can be of help to somebody. I had the same problem in my ubuntu edgy beta amd64. What I have done is to get the static i386 binary tarball from, remove the old "partimage" binary from /usr/sbin and then put the i386 binary there. Until now it works pefectly.

Kai Kasurinen (kai-kasurinen) wrote :

Fixed in Feisty:

partimage (0.6.4-17) unstable; urgency=low

  * Update maintainer email address to <email address hidden>.
  * Switch debian/partimaged-passwd to /bin/bash, it uses bash only
    features, like read -s.
  * debian/patches/disable_header_check.diff
    - Added. Disable header check for amd64. Closes: #391046
      This patch is a workaround. A proper fix is expected in the next
      upstream release.

Changed in partimage:
status: Unknown → Fix Released
William Grant (wgrant) on 2007-03-09
Changed in partimage:
status: Confirmed → Fix Released
Mathijs Vogelzang (mathijs) wrote :

I have all repositories enabled (including updates, pre-release, etc.) but my version of partimage is still stuck at 0.6.4-15ubuntu1, and therefore I still have the sizeof(DWORD) != 4 problem.
Also, I saw on the debian bug tracker that this bug is supposed to be fixed starting from version 0.6.4-8? (

Brian Murray (brian-murray) wrote :

I can confirm this still being an issue with the latest version of partimage, 0.6.4-15ubuntu1, on amd64.
"Error: sizeof(DWORD) != 4 (8)
This version has been compiled with an uncompatible version of gcc."

Changed in partimage:
status: Fix Released → Confirmed
jmrasor (jmrasor) wrote :

Same here.

System is amd64 dual-core (Brisbane 4400).
OS is Feisty Desktop CD, with all updates installed.

Necreia (necreia) wrote :

I confirm the error.

Core 2 Duo AMD64, fully updated.

I also experience this problem in Feisty.

0.6.4-17 merge is now on Feisty and Gutsy.

Changed in partimage:
assignee: nobody → xxxxx1
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.