From owner-freebsd-stable@FreeBSD.ORG Mon May 25 02:56:54 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 72489361 for ; Mon, 25 May 2015 02:56:54 +0000 (UTC) (envelope-from brandon.wandersee@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.158]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EF251E0 for ; Mon, 25 May 2015 02:56:54 +0000 (UTC) (envelope-from brandon.wandersee@zoho.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:subject:message-id:mime-version:content-type:user-agent; b=kQTh7FJDCnKNXOyV2AU5k1iprTQ8uOchIioA4MWpbuArnPZCO2RMg+LthD/DJlgkxVSD1Zf3E/c+ Jdx6Z143Na2HkhfL334vqfEoTY9x6mNtxCmilTkFjVkjRC+vuKO6 Received: from WorkBox.Home (184-100-107-74.mpls.qwest.net [184.100.107.74]) by mx.zohomail.com with SMTPS id 14325225715399.527037990154668; Sun, 24 May 2015 19:56:11 -0700 (PDT) Date: Sun, 24 May 2015 21:56:07 -0500 From: Brandon Wandersee To: freebsd-stable@freebsd.org Subject: Kernel fails to boot after update Message-ID: <20150525025607.GA1071@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mon, 25 May 2015 02:56:54 -0000 After updating my system to r283501 today, my system fails to boot from the new GENERIC kernel, either in single- or multi-user mode. The old kernel still boots fine, though, indicating that the base system itself is fine. The old kernel was built from r281528, and the only things that have changed in the configuration since then are the inclusion of nvme, nvd and hyperv, none of which I've ever used. I tried trimming all of those from the latest GENERIC configuration, with no luck. I can't say at exactly which point in the boot process the failure lands, other than that it happens prior to the filesystems being mounted (hence the lack of logged information). It simply gets less than halfway through the boot sequence and then abruptly reboots. Is there any way to prevent this reboot from happeneing so I can see any applicable error messages, or any other advice on debugging this? Thanks in advance. - Brandon -- =========================================== :: Brandon Wandersee :: :: brandon.wandersee@zoho.com :: =========================================== "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams ===========================================