From owner-freebsd-stable@freebsd.org Wed Dec 23 13:23:16 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 696A8A4EED3 for ; Wed, 23 Dec 2015 13:23:16 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id B4C9215D1 for ; Wed, 23 Dec 2015 13:23:15 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Wed, 23 Dec 2015 14:23:08 +0100 Authentication-Results: connect.ultra-secure.de; auth=pass (login); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.16 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.16; helo=connect.ultra-secure.de; envelope-from= Received: from connect.ultra-secure.de (expwebmail [127.0.0.16]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id A33F5803-B37C-45DD-B6EA-814C62516EEA.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=NO); Wed, 23 Dec 2015 14:22:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Dec 2015 14:22:51 +0100 From: rainer@ultra-secure.de To: Aristedes Maniatis Cc: freebsd-stable Subject: Re: freebsd-update incorrect hashes In-Reply-To: <567A92BD.5010105@ish.com.au> References: <567A92BD.5010105@ish.com.au> Message-ID: <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> X-Sender: rainer@ultra-secure.de User-Agent: Roundcube Webmail/1.1.3 X-Haraka-GeoIP: --, , NaNkm X-Haraka-GeoIP-Received: X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 5, bad: 0, connections: 20, history: 5, pass:relaying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 13:23:16 -0000 Am 2015-12-23 13:25, schrieb Aristedes Maniatis: > I've had problems with freebsd-update for many years now. It is by far > the least reliable component of FreeBSD since I started with the > operating system back at 3.4 in 1999. > > Anyhow, I'm usually able to get past the exceedingly slow downloads > and errors to the upgrade process, but this time nothing I do will get > me to the end. I've tried deleting /var/db/freebsd-update but several > hours later I was at the same place again. The internet link is fast, > but with a web proxy in this location, some downloads are slightly > delayed while the virus scanner on the proxy does its thing. Perhaps > 3-5 seconds delayed. The problem is phttpget or the proxy, depending on the point of view. Some proxies have (had) problems with the pipelined http requests that phttpget seems to use. apt (Debian/Ubuntu) has, too - but they can be disabled altogether there. http://webcache.googleusercontent.com/search?q=cache:OwcOVJamJOoJ:https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/55213-http-pipelining-broken-after-upgrade-utm-9-3-a.html+&cd=1&hl=de&ct=clnk&gl=ch IMO, there should be an option to use wget instead of phttpget. Or at least disable the request-pipelining. There was a PR with patches floating around to make freebsd-update use wget, but it never gained traction. Also, didn't phttpget have problems with proxies needing authentication? I usually have authentication at the proxy disabled for *.freebsd.org for this reason.