From owner-svn-src-all@freebsd.org Sun Mar 6 19:57:35 2016 Return-Path: Delivered-To: svn-src-all@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 DA2C5AC1116; Sun, 6 Mar 2016 19:57:34 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 C6A35EEC; Sun, 6 Mar 2016 19:57:34 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id E3028239746; Sun, 6 Mar 2016 14:57:33 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.1 Received: from app.lifanov.com (chat.lifanov.com [206.125.175.13]) by mail.lifanov.com (Postfix) with ESMTPA id 1824523958D; Sun, 6 Mar 2016 14:57:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Mar 2016 14:57:32 -0500 From: Nikolai Lifanov To: Dimitry Andric Cc: Oliver Pinter , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, owner-svn-src-head@freebsd.org Subject: Re: svn commit: r296428 - head/sys/boot/common In-Reply-To: <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> Message-ID: <5ba9554b9066227c883140c7c12e4703@mail.lifanov.com> X-Sender: lifanov@mail.lifanov.com User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 19:57:35 -0000 On 2016-03-06 11:17, Dimitry Andric wrote: > On 06 Mar 2016, at 17:00, Oliver Pinter > wrote: >> >> On 3/6/16, Dimitry Andric wrote: >>> Author: dim >>> Date: Sun Mar 6 15:57:43 2016 >>> New Revision: 296428 >>> URL: https://svnweb.freebsd.org/changeset/base/296428 >>> >>> Log: >>> Since kernel modules can now contain sections of type >>> SHT_AMD64_UNWIND, >>> the boot loader should not skip over these anymore while loading >>> images. >>> Otherwise the kernel can still panic when it doesn't find the >>> .eh_frame >>> section belonging to the .rela.eh_frame section. >>> >>> Unfortunately this will require installing boot loaders from >>> sys/boot >>> before attempting to boot with a new kernel. >> >> Could you please add a note about this to UPDATING file? > > I am a bit torn on this, because normally we always tell people to > install the kernel first, reboot, then run make installworld (which > also > installs the boot loaders). > > However, in this case, people might depend on their boot loader loading > modules which are required to make the system boot at all. So if they > happened to forget updating their boot loader first, a panic might be > the result. > > I wonder what a failsafe and acceptable upgrade scenario is, in this > case. Normally the procedure is something like: > > make buildworld > make buildkernel (with KERNCONF=whatever, if needed) > make installkernel (again with KERNCONF, if needed) > reboot (to single user, but cheating is possible usually) > mergemaster -p > make installworld > > This could maybe be modified to: > > make buildworld > make buildkernel (with KERNCONF=whatever, if needed) > make installkernel (again with KERNCONF, if needed) > make -C sys/boot install > reboot (to single user, but cheating is possible usually) > mergemaster -p > make installworld > > E.g. insert the step which installs the boot loaders just after (or > before) the step which installs the kernel. > > Is something like this acceptable as a one-time workaround, or maybe it > is better in general, in case we ever add other new features to the > boot > loaders? > > -Dimitry In my opinion, boot *blocks* (boot1) should be updated seldomly and not on every install. All (?) instances of not updating these resulting in a failed boot have an UPDATING entry or a similar warning (like the one during "zpool upgrade"). - Nikolai Lifanov