1

I am trying to clone a git repository from a GOGS server which is located on a Raspberry Pi 3. It fails with the following complaint:

git clone git@192.168.0.62:axelle/prog.git
Cloning into 'prog'...
remote: Enumerating objects: 3008, done.
remote: Counting objects: 100% (3008/3008), done.
error: pack-objects died of signal 9541/2583)   
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

As I use the repository from another host without any problem, I don't think there is any corruption. Rather, when I log on the server, I see RAM go drastically down, then basically the Pi freezes, and a short while after I get the error on client side, and my Pi server regains its memory. So, I think my clone fails because I fall out of memory on the Rpi.

I have seen several solutions which basically consist in using commands such as the following. But to be honest, I don't really understand if I should put a small window memory & size limit, or a big one. Anyway, I tried with 20m and 100m, and nothing worked :(

$ git config --global pack.windowMemory "100m"
$ git config --global pack.SizeLimit "100m" 
$ git config --global pack.threads "1"
$ git config --global pack.window "0"
$ git config --global core.bigfilethreshold 200K

With regards to big files - which might be another reason the clone fails, I probably have a few big files, but not too much. How can I check what's the biggest file of my repository? and should I then set core.bigfilethreshold slightly above?

Also, I saw some people recomment git fsck, but that does not work for me because my repository is not cloned.

Finally, I am not sure that the commands above will solve my problem, and I'd appreciate anyother solution so that I can clone my repo :) If there's a way to see the issue precisely on server's side, let me know too.

Logs:

On RPi (server) side, I have the following logs. I don't think they are relevant though, especially the 2nd one is about another repository (docs), while I am trying to clone (prog):

home/git/gogs/log $ sudo cat serv.log
2021/08/27 11:13:05 [FATAL] [...ogs/gogs/cmd/serv.go:268 runServ()] Fail to execute git command: exit status 128

/home/git/gogs/log $ sudo cat gogs.log
2021/08/27 00:16:18 [ WARN] Failed to perform health check on repository '/home/git/gogs-repositories/axelle/docs.git': execution is timeout [duration: 1m0s]

Edited (Sept 2, 2021)

  • I'm looking for a solution where I keep the GOGS server on the RPi 3. This means I'm not considering a solution where I upgrade to RPi 4, or add RAM to my RPI...
  • I tried a git clone --depth 1 git@192.168.0.62:axelle/prog.git which is probably close to working... but fails out of memory just by the end.

Output:

git clone --depth 1 --branch master git@192.168.0.62:axelle/prog.git
Cloning into 'prog'...
remote: Enumerating objects: 1355, done.
remote: Counting objects: 100% (1355/1355), done.
error: --shallow-file died of signal 98/1125)   
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
user369353
  • 11
  • 3
  • Install more memory on the server (perhaps difficult or impossible in this case), or, use something more capable as the server (recommended for this case). – torek Aug 27 '21 at 10:38
  • Obviously, that's not the solution I want ;-) I want to tweak it :) – user369353 Aug 27 '21 at 11:42
  • 1
    There's a fundamental problem here in that `git clone` *demands* a single packfile from the server. You can work around it a bit by cloning piecemeal (`--depth` and `--deepen` and eventually `--unshallow`), and the newfangled partial clone stuff would also be a way to deal with it. Partial clone is still undergoing a lot of work to be usable by people who aren't writing the code for Git, though. – torek Aug 27 '21 at 11:51
  • @torek git clone --depth 1 is failing too, just at the end (around 98%). Isn't there a way to clone just one or two subdirectories at a time? Like my repo is called prog. But, underneath I have arduino, scripts etc. Could I clone just prog/arduino for example? Or any other idea? – user369353 Sep 02 '21 at 08:30
  • No, you can't clone just some particular directory. (Not even the new partial clone code lets you do that. It could in theory, and perhaps once it's "live" it will, but right now there is not enough tooling.) But: if it's going to fail due to memory issues, it *should* fail long before that 98% point. Perhaps there's some other storage leak that could be fixed in the server... – torek Sep 02 '21 at 12:50
  • @torek how would I see that on the GOGS server? – user369353 Sep 02 '21 at 16:14
  • Not sure. You could try monitoring tools, but they disturb the environment (e.g., they take up valuable RAM), which could end up turning this into a [Heisenbug](https://en.wikipedia.org/wiki/Heisenbug). However you go about it though, you'll probably want to start by building Git from source, and adding/enabling tracing. – torek Sep 02 '21 at 16:45

1 Answers1

0

On a Raspberry Pi, RAM is limited and you can't easily add more. In situations where you need more RAM (which is the case for this GOGS failure), the solution is to use or increase the size of a swap file.

In my case, a swap file was already configured for 100M, but insufficient. Increase it (e.g. 1G):

  1. Disable temporarily swap file: sudo dphys-swapfile swapoff
  2. Edit file /etc/dphys-swapfile and modify CONF_SWAPSIZE. Example: CONF_SWAPSIZE=1024
  3. Setup system with this size: sudo dphys-swapfile setup
  4. Re-enable swap file: sudo dphys-swapfile swapon

This solves the issue I have, where the Git server fails on the RPi because it lacks RAM.

$ git clone git@192.168.0.62:axelle/prog.git
Cloning into 'prog'...
remote: Enumerating objects: 3019, done.
remote: Counting objects: 100% (3019/3019), done.
remote: Compressing objects: 100% (2594/2594), done.
Receiving objects: 100% (3019/3019), 638.82 MiB | 2.30 MiB/s, done.
remote: Total 3019 (delta 1217), reused 1353 (delta 234)
Resolving deltas: 100% (1217/1217), done.
Updating files: 100% (1158/1158), done.

Note that:

  1. Use of a swap file will be slower than RAM
  2. Depending on your case, you'll need to adjust the size of the swap file.
  3. dphys-swapfile setup checks you aren't asking for more than 50% of available disk space. This ensures your swapfile is of reasonable size. If you disk is close to full, you'll need to make disk space first.
  4. This solution only applies to Git server failures due to lack of memory on server side!
user369353
  • 11
  • 3