Hi,
Wollen wir mal testen ob die Probleme auch auftreten wenn wir kein omnibus nehmen sondern wieder zum alten setup?
Am Gitlab liegt es nicht. Es sind definitiv die Git-Repos, die korrumpiert sind. Denn das Problem tritt bereits im original Recovery auf, dass ich vergangenen Samstag gezogen habe:
+++ root@srv15 ..sitories/netmon-sc/api-server.git_test (git)-[master] # pwd /home/floh1111/home/git/repositories/netmon-sc/api-server.git_test root@srv15 ..sitories/netmon-sc/api-server.git_test (git)-[master] # git fsck bad sha1 file: objects/9f/metadata.go9/256) bad sha1 file: objects/9f/codes.go bad sha1 file: objects/9f/entry.go bad sha1 file: objects/9f/metadata_test.go Checking object directories: 100% (256/256), done. error: index file objects/pack/ pack-8bf934c19ecc65e873489a6ea4ee4220084b6fdf.idx is too small error: index file objects/pack/pack- b48b401850b48e64a84182e2a2270bda332d5951.idx is too small error: non-monotonic index objects/pack/ ......... +++
Also Clemens ich weiß ja nicht ob es die auch so geht, aber wirklich überzeugt bin ich von der Lösung nicht.
Ich habe mal sicherheitshalber geprüft ob der Inhalt der Dateien eines Repos nach der obigen Prozedur der selbe ist, wie der Inhalt des korrekten Repos auf meiner Festplatte. Das sollte passen (diff -r --exclude=".git" api-server_old/ api-server_new/).
Überzeugt bin ich von der Lösung auch nicht. Eine Alternativlösung wäre die Repos zu löschen, ein neues Leeres Repo zu erstellen und dann eine lokale Kopie, die jemand noch von vor dem Crash bei sich auf der Platte hat, einzuspielen. Das habe ich jetzt bspw. für zwei Repos in der Netmon-SC Gruppe gemacht: https://git.ffnw.de/groups/netmon-sc/activity
Ich habe auch noch die Vorstands-Repos sowie die Puppet-Repos in einer aktueller Version auf der Platte. Die würde ich ebenfalls wieder einspielen. Aber erst morgen früh ;)
Viele Grüße Clemens