David Wolfskill wrote:
> On Sun, Jul 27, 2014 at 01:19:49PM +0200, Baptiste Daroussin wrote:
>> ...
>> This is a known one I'm very sorry about but tricky to fix, to solve it, open
>> your /usr/local/etc/pkg.conf you might have a duplicated entrey in alias
>> (probable leaf), remove the second one, that will solve your problem.
>> ....
> Errr...??!?
> I haven't changed /usr/local/etc/pkg.conf at all.
> I have 3 systems I'm trying to update, and 2 more to update if I get
> those done successfully.  I use portmaster to build & update ports
> on all 5 systems.
> Each of the 3 has failed in the installation phase of updating to
> pkg-1.3.1.  Each is running stable/9 @r269090.  Two are i386; one
> is amd64.  The i386 systems had been upgraded successfully to
> pkg-1.3.0; the amd64 system is only updated weekly, so it had been
> running pkg-1.2.7_4.
> Each of the 3 has failed with:
> ...
> ===>  Installing for pkg-1.3.1
> ===>   Registering installation for pkg-1.3.1
> Child process pid=11028 terminated abnormally: Segmentation fault: 11
> *** [fake-pkg] Error code 245
> Stop in /common/ports/ports-mgmt/pkg.
> *** [/common/ports/ports-mgmt/pkg/work/.install_done.pkg._usr_local] Error 
> code 1
> Stop in /common/ports/ports-mgmt/pkg.
> ===>>> A backup package for pkg-1.3.0 should
>        be located in /usr/ports/packages/portmaster-backup
> ===>>> Installation of pkg-1.3.1 (ports-mgmt/pkg) failed
> ===>>> Aborting update
> ===>>> Update for ports-mgmt/pkg failed
> ===>>> Aborting update
> In each case, the md5 checksum for /usr/local/etc/pkg.conf is
> 4e302ae1f371e5134ffa717ff693d6f0.  I have not done anything with it;
> I know of no reason I would want to change it.
> And so far, I haven't found a way to even get any of these systems back
> to a point where I have any confidence at all that the
> currently-installed ports and their dependencies are being tracked: on
> one system, I tried the "Reversion to pkg-1.3.0" approach; that yields:

By any chance is there a core file around releated to this, and if so
was the binary that faulted unstripped?  I'd be interested in seeing the
backtrace... (I'm not using 1.3 or even NG on any of my production
systems at the moment because I personally don't trust it yet (I have 57
complex systems and if they screw up I end up rebuilding the OS from
scratch) so I'd be happy to take a look at any cores an unstripped
binaries to see if I can work out why people see this occasionally... 
Sounds like you have 3 identical systems which 2 worked no problems the
third faulted .. this is obviously not good and needs to be fixed, so
will give another pair of eyes at the problem.


Michelle Sullivan

freebsd-ports@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Reply via email to