Bug#547503: git-core: "git clone" fails on armel
Sascha Silbe
Version: 1:1.6.3.3-2
Severity: important
git clone fails on my Debian armel system:
sascha.silbe@flatty:~$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Initialized empty Git repository in /home/sascha.silbe/sugar-jhbuild/.git/
remote: Counting objects: 4772, done.
remote: Compressing objects: 100% (2079/2079), done.
error: inflate: data stream error (invalid distance too far back)
fatal: pack has bad object at offset 616818: inflate returned -3
fatal: index-pack failed
sascha.silbe@flatty:~$ git clone git://git.gnome.org/jhbuild
Initialized empty Git repository in /home/sascha.silbe/jhbuild/.git/
remote: Counting objects: 19804, done.
remote: Compressing objects: 100% (6374/6374), done.
fatal: pack has bad object at offset 487227: inflate returned -5
fatal: index-pack failed
sascha.silbe@flatty:~$
The same repositories can be checked out fine on a Debian i386 system (inside the same network):
sascha.silbe@caravan:/tmp/sascha_silbe/tmpbox.PjGIP1AEY7$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Initialized empty Git repository in /tmp/sascha_silbe/tmpbox.PjGIP1AEY7/sugar-jhbuild/.git/
remote: Counting objects: 4772, done.
remote: Compressing objects: 100% (2079/2079), done.
remote: Total 4772 (delta 2815), reused 4486 (delta 2638)
Receiving objects: 100% (4772/4772), 1.88 MiB | 607 KiB/s, done.
Resolving deltas: 100% (2815/2815), done.
sascha.silbe@caravan:/tmp/sascha_silbe/tmpbox.PjGIP1AEY7$
strace doesn't show anything unusual; ltrace seems stuck inside an infinite loop of "unexpected instruction 0xe5bcf76c at 0xac08" (addresses not changing) if given "-f" to trace children (and without "-f" doesn't show anything useful).
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armel (armv5tel)
Kernel: Linux 2.6.31-rc9-flatty-ocf-1-00293-g53a104c (PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages git-core depends on:
ii libc6 2.9-25 GNU C Library: Shared libraries
ii libcurl3-gnutls 7.19.5-1.1 Multi-protocol file transfer libra
ii libdigest-sha1-perl 2.12-1 NIST SHA-1 message digest algorith
ii liberror-perl 0.17-1 Perl module for error/exception ha
ii libexpat1 2.0.1-4 XML parsing C library - runtime li
ii libgcc1 1:4.4.1-1 GCC support library
ii perl-modules 5.10.0-25 Core Perl modules
ii zlib1g 1:1.2.3.3.dfsg-15+b2 compression library - runtime
Versions of packages git-core recommends:
ii less 436-1+b1 pager program similar to more
ii openssh-client [ssh-client] 1:5.1p1-7+b1 secure shell client, an rlogin/rsh
ii patch 2.5.9-5 Apply a diff file to an original
ii rsync 3.0.6-1 fast remote file copy program (lik
Versions of packages git-core suggests:
pn git-arch <none> (no description available)
pn git-cvs <none> (no description available)
pn git-daemon-run <none> (no description available)
pn git-doc <none> (no description available)
pn git-email <none> (no description available)
pn git-gui <none> (no description available)
pn git-svn <none> (no description available)
pn gitk <none> (no description available)
pn gitweb <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gerrit Pape
> git clone fails on my Debian armel system:
>
> sascha.silbe@flatty:~$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
> Initialized empty Git repository in /home/sascha.silbe/sugar-jhbuild/.git/
> remote: Counting objects: 4772, done.
> remote: Compressing objects: 100% (2079/2079), done.
> error: inflate: data stream error (invalid distance too far back)
> fatal: pack has bad object at offset 616818: inflate returned -3
> fatal: index-pack failed
> sascha.silbe@flatty:~$ git clone git://git.gnome.org/jhbuild
> Initialized empty Git repository in /home/sascha.silbe/jhbuild/.git/
> remote: Counting objects: 19804, done.
> remote: Compressing objects: 100% (6374/6374), done.
> fatal: pack has bad object at offset 487227: inflate returned -5
> fatal: index-pack failed
> sascha.silbe@flatty:~$
Hi Sascha, the bug seems to be in zlib, not git. git uses the inflate()
function from zlib, which, in your case, returns the errors -3
(Z_DATA_ERROR) and -5 (Z_BUF_ERROR). See /usr/include/zlib.h.
Regards, Gerrit.
Jonathan Nieder
Can you reproduce this problem? If so, any ideas on how to fix it?
Gerrit Pape wrote:
> On Sun, Sep 20, 2009 at 02:08:20PM +0200, Sascha Silbe wrote:
>> git clone fails on my Debian armel system:
>>
>> sascha.silbe@flatty:~$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
>> Initialized empty Git repository in /home/sascha.silbe/sugar-jhbuild/.git/
>> remote: Counting objects: 4772, done.
>> remote: Compressing objects: 100% (2079/2079), done.
>> error: inflate: data stream error (invalid distance too far back)
>> fatal: pack has bad object at offset 616818: inflate returned -3
>> fatal: index-pack failed
>> sascha.silbe@flatty:~$ git clone git://git.gnome.org/jhbuild
>> Initialized empty Git repository in /home/sascha.silbe/jhbuild/.git/
>> remote: Counting objects: 19804, done.
>> remote: Compressing objects: 100% (6374/6374), done.
>> fatal: pack has bad object at offset 487227: inflate returned -5
>> fatal: index-pack failed
>> sascha.silbe@flatty:~$
>
> Hi Sascha, the bug seems to be in zlib, not git. git uses the inflate()
> function from zlib, which, in your case, returns the errors -3
> (Z_DATA_ERROR) and -5 (Z_BUF_ERROR). See /usr/include/zlib.h.
Thanks,
Jonathan
Please CC me on replies, as I’m not subscribed.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
Riku Voipio
> Hi arm porters,
>
> Can you reproduce this problem? If so, any ideas on how to fix it?
mv78x00: git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Initialized empty Git repository in /schroot/sugar-jhbuild/.git/
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (2095/2095), done.
remote: Total 4728 (delta 2798), reused 4376 (delta 2577)
Receiving objects: 100% (4728/4728), 1.87 MiB | 206 KiB/s, done.
Resolving deltas: 100% (2798/2798), done.
mv78x00: git clone git://git.gnome.org/jhbuild
Initialized empty Git repository in /schroot/jhbuild/.git/
remote: Counting objects: 20162, done.
remote: Compressing objects: 100% (6726/6726), done.
remote: Total 20162 (delta 15845), reused 16820 (delta 13378)
Receiving objects: 100% (20162/20162), 3.52 MiB | 118 KiB/s, done.
Resolving deltas: 100% (15845/15845), done.
mv78x00:
At the original report:
Kernel: Linux 2.6.31-rc9-flatty-ocf-1-00293-g53a104c (PREEMPT)
Whats this kernel? Which CPU and machine is it on? Zlib is heavily used
throughout debian, so any breakage should have been noted before by others.
Versions of packages git-core depends on:
ii libc6 2.9-25 GNU C Library: Shared libraries
Seems you have quite old sqeeze setup. Can you try updating?
Martin Guy
> >> git clone fails on my Debian armel system:
Just to say, there's a 500MHz 512MB armel-sid box here
n2100.martinwguy.co.uk that you can use for compilation and over ssh
if that's useful - just suggest a username by private email.
Good luck!
M
Sascha Silbe
> mv78x00: git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git
> sugar-jhbuild
[...]
Works fine for me now as well:
sascha.silbe@flatty:~/y$ git clone
git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Initialized empty Git repository in
/home/sascha.silbe/y/sugar-jhbuild/.git/
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (2095/2095), done.
remote: Total 4728 (delta 2795), reused 4376 (delta 2577)
Receiving objects: 100% (4728/4728), 1.87 MiB | 545 KiB/s, done.
Resolving deltas: 100% (2795/2795), done.
sascha.silbe@flatty:~/y$
Whatever it was, it seems fixed.
> Kernel: Linux 2.6.31-rc9-flatty-ocf-1-00293-g53a104c (PREEMPT)
>
> Whats this kernel? Which CPU and machine is it on? Zlib is heavily
> used
> throughout debian, so any breakage should have been noted before by
> others.
This is on OpenRD-Base with a custom kernel. The only two changes (vs.
the mainline kernel) that might have been relevant at all to this bug
are:
- apply cpu_idle IRQ fix from http://patchwork.kernel.org/patch/40871/
- apply OCF patch
http://downloads.sourceforge.net/project/ocf-linux/ocf-linux/20090901/ocf-linux-26-20090901.patch.gz
I doubt even that, though. If there's interest I can try again with the
old kernel, otherwise we can just close this bug.
CU Sascha
Jonathan Nieder
Sascha Silbe wrote:
> Works fine for me now as well:
>
> sascha.silbe@flatty:~/y$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
> Initialized empty Git repository in
> /home/sascha.silbe/y/sugar-jhbuild/.git/
> remote: Counting objects: 4728, done.
> remote: Compressing objects: 100% (2095/2095), done.
> remote: Total 4728 (delta 2795), reused 4376 (delta 2577)
> Receiving objects: 100% (4728/4728), 1.87 MiB | 545 KiB/s, done.
> Resolving deltas: 100% (2795/2795), done.
> sascha.silbe@flatty:~/y$
>
>
> Whatever it was, it seems fixed.
That’s too bad.
> This is on OpenRD-Base with a custom kernel. The only two changes
> (vs. the mainline kernel) that might have been relevant at all to
> this bug are:
>
> - apply cpu_idle IRQ fix from http://patchwork.kernel.org/patch/40871/
> - apply OCF patch http://downloads.sourceforge.net/project/ocf-linux/ocf-linux/20090901/ocf-linux-26-20090901.patch.gz
>
> I doubt even that, though. If there's interest I can try again with
> the old kernel, otherwise we can just close this bug.
Please do try it. Also (I know I’m pushing my luck here) if you still
have the old libc package around, could you try with that? It would
be nice to understand what went wrong here, so we can avoid it
breaking again.
The only possibly relevant kernel change I could find was commit
5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and
kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1.
So though I also have my doubts, we _could_ be lucky.
Jonathan
Sascha Silbe
>> I doubt even that, though. If there's interest I can try again with
>> the old kernel, otherwise we can just close this bug.
> Please do try it.
Confirmed, it still breaks with the old kernel
(2.6.31-rc9-flatty-ocf-1-00293-g53a104c), but works with the current one
(2.6.32-rc4-flatty-ocf-1-00488-g4b69b78).
> The only possibly relevant kernel change I could find was commit
> 5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and
> kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1.
> So though I also have my doubts, we _could_ be lucky.
I'd prefer not to track this down to a specific commit as this is a
production server now, but can try if you convince me there's some
benefit.
Can rule out my own patches, though, since they haven't changed between
the two kernels (only been rebased).
Jonathan Nieder
> Confirmed, it still breaks with the old kernel
> (2.6.31-rc9-flatty-ocf-1-00293-g53a104c), but works with the current
> one (2.6.32-rc4-flatty-ocf-1-00488-g4b69b78).
Thanks!
>> The only possibly relevant kernel change I could find was commit
>> 5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and
>> kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1.
>> So though I also have my doubts, we _could_ be lucky.
>
> I'd prefer not to track this down to a specific commit as this is a
> production server now, but can try if you convince me there's some
> benefit.
That's okay. I don't think you should bother.
I am satisfied, because now it's clear (1) the problem was in the
kernel, (2) the problem is actually fixed (not just a change in what
the remote repos were serving, for example), and (3) there was at least
one kernel change meant to address similar problems. It would be
lovely to confirm on some other machine that reverting that patch
introduces the errors, but even that does not seem necessary to me.
> Can rule out my own patches, though, since they haven't changed
> between the two kernels (only been rebased).
Thanks for tracking this down.
Pleased,