Hi,
unsere Repos haben Recovery und/oder Migration nach Omnibus nicht unbeschadet überstanden. Bei einigen Repos kommt beim Klonen/Pushen folgendes:
+++ remote: error: non-monotonic index ./objects/pack/ pack-76337be173d5e2d203f12e37dc8553e66eebecdf.idx remote: error: index file ./objects/pack/ pack-8bf934c19ecc65e873489a6ea4ee4220084b6fdf.idx is too small remote: error: index file ./objects/pack/pack- b48b401850b48e64a84182e2a2270bda332d5951.idx is too small remote: error: non-monotonic index ./objects/pack/ pack-76337be173d5e2d203f12e37dc8553e66eebecdf.idx +++
Ich habe dazu etwas recherchiert und folgendes hat bei meinem Netmon Web- Client Repo geholfen: http://joemaller.com/1283/git-error-index-file-is-too-small/
Hatte den Fehler schonmal jemand und kann dazu etwas mehr sagen als ich? Nicht dass ich die Fehlerbehebung jetzt auf alle Repos anwende und dann mehr kaputt mache als heile :D
Viele Grüße Clemens
Am Freitag, 18. November 2016, 12:35:58 CET schrieb Clemens John via Admin:
Ich habe dazu etwas recherchiert und folgendes hat bei meinem Netmon Web- Client Repo geholfen: http://joemaller.com/1283/git-error-index-file-is-too-small/
Hatte den Fehler schonmal jemand und kann dazu etwas mehr sagen als ich? Nicht dass ich die Fehlerbehebung jetzt auf alle Repos anwende und dann mehr kaputt mache als heile :D
Hi,
Teilerfolg! Ich habe den Vorschlag jetzt mit folgendem Script auf alle Repos angewendet (Backup existiert):
+++ #!/bin/bash for namespace in /var/opt/gitlab/git-data/repositories/*; do for repo in "$namespace"/*; do [ -d $f ] && cd "$repo" && echo "Entering into $repo" && git repack -a -d done; done; +++
Jetzt kann man die Repos klonen ohne Fehlermeldungen zu bekommen. Mein Eindruck ist auch, dass da nichts verloren gegangen ist.
Probleme gibt es allerdings nach wie vor beim Pushen. Neue Dateien kann ich pushen, aber alte Dateien modifizieren geht wohl nicht. Zumindest konnte ich die in der letzten Woche bei mir angesammelten Commits nicht pushen:
+++ [floh1111@flohlap api-server_fixed]$ git push --verbose Versende nach git@git.ffnw.de:netmon-sc/api-server.git Enter passphrase for key '/home/floh1111/.ssh/id_rsa': Zähle Objekte: 49, Fertig. Delta compression using up to 4 threads. Komprimiere Objekte: 100% (18/18), Fertig. Schreibe Objekte: 100% (49/49), 8.11 KiB | 0 bytes/s, Fertig. Total 49 (delta 32), reused 45 (delta 31) remote: error: unable to create temporary file: Not a directory remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To git.ffnw.de:netmon-sc/api-server.git ! [remote rejected] master -> master (unpacker error) error: Fehler beim Versenden einiger Referenzen nach 'git@git.ffnw.de:netmon- sc/api-server.git' +++
Zu "remote: error: unable to create temporary file: Not a directory" ist Google nicht sehr ergiebig sodass ich mich jetzt an der Brutalo-Methode versucht habe, siehe https://forum.gitlab.com/t/how-can-i-delete-a-repository-and-push-a-new-one/...
1. korrumpiertes Repos auf den lokalen Rechner klonen 2. Das Repo unter /var/opt/gitlab/git-data/repositories/ vom Server löschen 3. Die Gitlab-URL des dazugehörenden Projekts aufrufen und ein neues leeres Repo erzeugen. 4. Das vorher geklonte Repo pushen
Da wir nicht genau wissen, welche Repos betroffen sind, könnte man den Prozess immer dann ausführen, wenn man beim Pushen in ein Repo ein betroffenes Repo findet. Bis alle Repos wieder clean sind, kann sich das natürlich hinziehen. Was meint ihr?
Viele Grüße Clemens
On 11/18/16 22:53, Clemens John via Admin wrote:
Am Freitag, 18. November 2016, 12:35:58 CET schrieb Clemens John via Admin:
Ich habe dazu etwas recherchiert und folgendes hat bei meinem Netmon Web- Client Repo geholfen: http://joemaller.com/1283/git-error-index-file-is-too-small/
Hatte den Fehler schonmal jemand und kann dazu etwas mehr sagen als ich? Nicht dass ich die Fehlerbehebung jetzt auf alle Repos anwende und dann mehr kaputt mache als heile :D
Hi,
Teilerfolg! Ich habe den Vorschlag jetzt mit folgendem Script auf alle Repos angewendet (Backup existiert):
+++ #!/bin/bash for namespace in /var/opt/gitlab/git-data/repositories/*; do for repo in "$namespace"/*; do [ -d $f ] && cd "$repo" && echo "Entering into $repo" && git repack -a -d done; done; +++
Jetzt kann man die Repos klonen ohne Fehlermeldungen zu bekommen. Mein Eindruck ist auch, dass da nichts verloren gegangen ist.
:S oh oh ich bin skeptisch ...
Probleme gibt es allerdings nach wie vor beim Pushen. Neue Dateien kann ich pushen, aber alte Dateien modifizieren geht wohl nicht. Zumindest konnte ich die in der letzten Woche bei mir angesammelten Commits nicht pushen:
+++ [floh1111@flohlap api-server_fixed]$ git push --verbose Versende nach git@git.ffnw.de:netmon-sc/api-server.git Enter passphrase for key '/home/floh1111/.ssh/id_rsa': Zähle Objekte: 49, Fertig. Delta compression using up to 4 threads. Komprimiere Objekte: 100% (18/18), Fertig. Schreibe Objekte: 100% (49/49), 8.11 KiB | 0 bytes/s, Fertig. Total 49 (delta 32), reused 45 (delta 31) remote: error: unable to create temporary file: Not a directory remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To git.ffnw.de:netmon-sc/api-server.git ! [remote rejected] master -> master (unpacker error) error: Fehler beim Versenden einiger Referenzen nach 'git@git.ffnw.de:netmon- sc/api-server.git' +++
Zu "remote: error: unable to create temporary file: Not a directory" ist Google nicht sehr ergiebig sodass ich mich jetzt an der Brutalo-Methode versucht habe, siehe https://forum.gitlab.com/t/how-can-i-delete-a-repository-and-push-a-new-one/...
- korrumpiertes Repos auf den lokalen Rechner klonen
- Das Repo unter /var/opt/gitlab/git-data/repositories/ vom Server löschen
- Die Gitlab-URL des dazugehörenden Projekts aufrufen und ein neues leeres
Repo erzeugen. 4. Das vorher geklonte Repo pushen
Da wir nicht genau wissen, welche Repos betroffen sind, könnte man den Prozess immer dann ausführen, wenn man beim Pushen in ein Repo ein betroffenes Repo findet. Bis alle Repos wieder clean sind, kann sich das natürlich hinziehen. Was meint ihr?
Also Clemens ich weiß ja nicht ob es die auch so geht, aber wirklich überzeugt bin ich von der Lösung nicht. Wollen wir mal testen ob die Probleme auch auftreten wenn wir kein omnibus nehmen sondern wieder zum alten setup?
vg Tarek
Hi,
naja, den Schritt müssen wir so oder so mal gehen um auf Omnibus zu migrieren.
Jetzt wieder eine neue VM hochzuziehen und dort Tage dran zu sitzen halt ich persönlich gesagt für komplett bescheuert - alleine die Zeit für das Recovery war ja nicht wenig...
Am 18. November 2016 23:22:05 MEZ, schrieb Jan-Tarek Butt via Admin admin@lists.ffnw.de:
On 11/18/16 22:53, Clemens John via Admin wrote:
Am Freitag, 18. November 2016, 12:35:58 CET schrieb Clemens John via
Admin:
Ich habe dazu etwas recherchiert und folgendes hat bei meinem Netmon
Web-
Client Repo geholfen: http://joemaller.com/1283/git-error-index-file-is-too-small/
Hatte den Fehler schonmal jemand und kann dazu etwas mehr sagen als
ich?
Nicht dass ich die Fehlerbehebung jetzt auf alle Repos anwende und
dann
mehr kaputt mache als heile :D
Hi,
Teilerfolg! Ich habe den Vorschlag jetzt mit folgendem Script auf
alle Repos
angewendet (Backup existiert):
+++ #!/bin/bash for namespace in /var/opt/gitlab/git-data/repositories/*; do for repo in "$namespace"/*; do [ -d $f ] && cd "$repo" && echo "Entering into $repo" && git
repack -a -d
done; done; +++
Jetzt kann man die Repos klonen ohne Fehlermeldungen zu bekommen.
Mein
Eindruck ist auch, dass da nichts verloren gegangen ist.
:S oh oh ich bin skeptisch ...
Probleme gibt es allerdings nach wie vor beim Pushen. Neue Dateien
kann ich
pushen, aber alte Dateien modifizieren geht wohl nicht. Zumindest
konnte ich
die in der letzten Woche bei mir angesammelten Commits nicht pushen:
+++ [floh1111@flohlap api-server_fixed]$ git push --verbose Versende nach git@git.ffnw.de:netmon-sc/api-server.git Enter passphrase for key '/home/floh1111/.ssh/id_rsa': Zähle Objekte: 49, Fertig. Delta compression using up to 4 threads. Komprimiere Objekte: 100% (18/18), Fertig. Schreibe Objekte: 100% (49/49), 8.11 KiB | 0 bytes/s, Fertig. Total 49 (delta 32), reused 45 (delta 31) remote: error: unable to create temporary file: Not a directory remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To git.ffnw.de:netmon-sc/api-server.git ! [remote rejected] master -> master (unpacker error) error: Fehler beim Versenden einiger Referenzen nach
'git@git.ffnw.de:netmon-
sc/api-server.git' +++
Zu "remote: error: unable to create temporary file: Not a directory"
ist Google
nicht sehr ergiebig sodass ich mich jetzt an der Brutalo-Methode
versucht
habe, siehe
https://forum.gitlab.com/t/how-can-i-delete-a-repository-and-push-a-new-one/...
- korrumpiertes Repos auf den lokalen Rechner klonen
- Das Repo unter /var/opt/gitlab/git-data/repositories/ vom Server
löschen
- Die Gitlab-URL des dazugehörenden Projekts aufrufen und ein neues
leeres
Repo erzeugen. 4. Das vorher geklonte Repo pushen
Da wir nicht genau wissen, welche Repos betroffen sind, könnte man
den Prozess
immer dann ausführen, wenn man beim Pushen in ein Repo ein
betroffenes Repo
findet. Bis alle Repos wieder clean sind, kann sich das natürlich
hinziehen.
Was meint ihr?
Also Clemens ich weiß ja nicht ob es die auch so geht, aber wirklich überzeugt bin ich von der Lösung nicht. Wollen wir mal testen ob die Probleme auch auftreten wenn wir kein omnibus nehmen sondern wieder zum alten setup?
vg Tarek
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
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
Am Samstag, 19. November 2016, 02:57:18 CET schrieb Clemens John via Admin:
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 ;)
Mal eben fürs Log was ich aus meinen noch lokal vorhandenen Repos neu eingespielt habe:
Netmon-SC * api-server * web-client Puppet * Alles Vorstand * Mitgliederverwaltung * Vorstand Community * Admin-Team
Backups der Repos auf dem Git-Server habe ich mit "*_backup" markiert. Das wars an Repos von meiner Seite.
Viele Grüße Clemens
Am Donnerstag, 24. November 2016, 10:28:43 CET schrieb Jan-Tarek Butt via Admin:
Alle repos haben immernoch die falschen urls.
Hi,
Website funktioniert unter beiden URLs: https://git.ffnw.de/ffnw-firmware/siteconf https://git.nordwest.freifunk.net/ffnw-firmware/siteconf
Klonen funktioniert unter beiden URLs: git clone git@git.ffnw.de:ffnw-firmware/siteconf.git git clone git@git.nordwest.freifunk.net:ffnw-firmware/siteconf.git
Passt das so oder gibt es noch ein anderes Problem?
Viele Grüße Clemens
On 11/24/16 10:38, Clemens John via Admin wrote:
Am Donnerstag, 24. November 2016, 10:28:43 CET schrieb Jan-Tarek Butt via Admin:
Alle repos haben immernoch die falschen urls.
Hi,
Website funktioniert unter beiden URLs: https://git.ffnw.de/ffnw-firmware/siteconf https://git.nordwest.freifunk.net/ffnw-firmware/siteconf
Klonen funktioniert unter beiden URLs: git clone git@git.ffnw.de:ffnw-firmware/siteconf.git git clone git@git.nordwest.freifunk.net:ffnw-firmware/siteconf.git
Passt das so oder gibt es noch ein anderes Problem?
Hm, ah habs den fehler alle repos die ich genannt hatte sind leer.
Hab meine teile davon nun upstream gesync :)
Läuft nun alles:) Danke dir für deine Mühe.
Ein build mit ATH10K ibss treiber läuft nun:) https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/473
vg Tarek
-
Clemens John -
Jan-Tarek Butt -
Stefan