From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 18:03:52 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3CD4584 for ; Mon, 9 Feb 2015 18:03:51 +0000 (UTC) Received: from smtp6.ore.mailhop.org (smtp6.ore.mailhop.org [54.149.35.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4C437B4 for ; Mon, 9 Feb 2015 18:03:51 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp6.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YKrpI-0007dV-Qo; Mon, 09 Feb 2015 17:08:49 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t19H8eK7073067; Mon, 9 Feb 2015 10:08:40 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18oQlXoseMcenmegtoB6FGW Message-ID: <1423501720.16794.18.camel@freebsd.org> Subject: Re: freebsd-update and hang during reboot From: Ian Lepore To: Kurt Lidl Date: Mon, 09 Feb 2015 10:08:40 -0700 In-Reply-To: <54D8E341.101@pix.net> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:03:52 -0000 On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote: > Joel wrote: > > Hi, > > > > Just about every machine I have seems to hang after running freebsd-update and doing a reboot. The last message on the screen is "All buffers synced¡ and it just freezes. > > > > This happens when doing a freebsd-update and going from 10.0 to 10.1, but also when doing a fresh 10.1 install and using freebsd-update to get the latest -pX security patches. As soon as I reboot the machine, it hangs. > > > > Iÿve tried it on several different HP ProLiant models, on Intel NUCs and on VMware virtual machines. Same phenomenon everywhere. Itÿs really easy to trigger: just install 10.1, use default settings everywhere, freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I think Iÿve seen it on > > > > > > > > > > 30 servers or so now. > > > > Everything works like it should after the initial hang tough - no matter how many times I reboot it completes the reboot cycle just fine. > > > > Iÿve seen several people (mostly on IRC) mention this problem, but no solution. > > > > Is anyone working on fixing this? > > I ran into this problem in spades when upgrading a set of servers from > FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, > but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung > at the same place, after printing the "All buffers synced" message. > > I ultimately determined that if I did the following, rather than > just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", > it would consistently AVOID the hang: > > sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" > > Your mileage may vary, but you don't have a lot to lose by trying it. > > -Kurt > That is just bad advice. sync(1) does not g'tee that all data has been written, no matter how many times you type it. shutdown -n tells the system to abandon unwritten data. All in all, this is a recipe for silent filesystem corruption. Using it after an update is just asking to have a mix of old and new files on the system after the reboot. A more robust workaround would be to "mount -r" on all filesystems before invoking the shutdown (even a shutdown -n should be safe after everything has been remounted readonly). If the mount -r hangs on one of the filesystems, then you've probably got a clue as to where a normal shutdown is hanging. -- Ian