pkgng update segfaultet

max93

Well-Known Member
Hallo!

Ich habe mal wieder was seltsames, was sonst keiner zu haben scheint (also tendiere ich zu PEBKAC).

Ich habe einen build Server auf dem ich mir mit poudriere Packages baue und seit dem letzten Update der Ports kann ich auf den Servern pkg update nicht mehr ausführen, das segfaultet ständig:

Code:
root@build01:~# uname -a
FreeBSD build01.intern.tzs.it64.de 9.1-RELEASE FreeBSD 9.1-RELEASE #3 r244837: Sun Dec 30 03:29:19 CET 2012     root@build01.intern.sgd.it64.de:/usr/obj/usr/src/sys/IT64SERVER  amd64
root@build01:~# pkg -d update
Updating repository catalogue
repo.txz                                                                    100%  145KB 144.5KB/s 144.5KB/s   00:00
Segmentation fault (core dumped)
root@build01:~# echo $?
139
root@build01:~# ls -l pkg.core /tmp/rep*
-rw-------  1 root  wheel    147976 Mar 22 12:56 /tmp/repo.txz.3XsVwg
-rw-------  1 root  wheel  15446016 Mar 22 12:56 pkg.core
root@build01:~# ls -la /var/db/pkg
total 5864
drwxr-xr-x   2 root  wheel     3584 Mar 22 12:56 .
drwxr-xr-x  11 root  wheel      512 Mar 18 05:18 ..
-r--r--r--   1 root  wheel   720042 Mar 22 02:20 auditfile
-rw-r--r--   1 root  wheel  3910656 Mar 15 09:35 local.sqlite
-rw-r--r--   1 root  wheel   612352 Mar 15 09:35 repo.sqlite
-rw-r--r--   1 root  wheel   561152 Mar 21 17:59 repo.sqlite.unchecked

Er holt offenbar die repo.txz noch ab, stirbt dann aber lieber als die DB an die richtige Stelle zu - ähm - "stellen" (wird wohl mehr als ein simples xz --decompress | tar -x... sein). Die repo.sqlite im /tmp/repo.txz.* hat exakt die gleiche Größe wie /var/db/pkg/repo.sqlite.unchecked.

Auf einem zweiten Server habe ich exakt das gleiche Problem, der benutzt aber ein geringfügig anderes Repo (mysql55 anstelle von mysql51 und php5 anstelle von php53). Gebaut werden beide Repositories natürlich am gleichen build Server.

Wie bekomme ich jetzt raus, was da klemmt? Wie bekomme ich es wieder hin? Hat jemand eine Idee?

Danke & Ciao.
Markus
 
Ehrlich, bei segfaults zu finden muss man den Code in der Regel gut kennen oder braucht einen Compiler der Laufzeiterkennung Pufferüberläufe und dergleichen unterstützt.

Du kannst mal versuchen "-fstack-protector-all" zu den CFLAGS hinzuzufügen.
 
Ich zitiere einfach mal:
Code:
This only affects binary-packages-only users.

pkg 1.0.9 had a regression with 'pkg update' that will prevent
updating your repository. Please skip this version and use 1.0.9_1.


This version was only in ports for 7 hours. Due to the security
incident, there are still no official FreeBSD packages. If you are
using an unofficial mirror, it is unlikely it would have upgraded to
1.0.9 in the time it was in the tree.

If you are building your own packages and managed to get onto 1.0.9
you can upgrade to 1.0.9_1 as follows:

# cp /usr/local/sbin/pkgs-static .
# pkg delete -f pkg
# ./pkg-static add URL-TO-YOUR-PACKAGESITE/All/pkg-1.0.9_1.txz
#optional
# rm pkg-static


As for how this managed to get released. We did do a functional
test of this before releasing, but due to the nature of 'pkg update'
using a cache, it was not immediately obvious that it was broken.

We do need your help with adding more automated tests.
http://lists.freebsd.org/pipermail/freebsd-pkg/2013-March/000016.html
has our call for help on this front and more information.


Regards,
Bryan Drewery
Also ein neues ports-mgmt/pkg bauen und anschließend geht es wieder. Oder eben der Anleitung dort folgen.
 
Code:
This only affects binary-packages-only users.

pkg 1.0.9 had a regression with 'pkg update' that will prevent
updating your repository. Please skip this version and use 1.0.9_1.


This version was only in ports for 7 hours...
Wieso hab ich nur bei sowas "Glück"? Am Lottoschein hatte ich noch nie einen erwähnenswerten Treffer ;-)

Thx!
Markus
 
Back
Top