From owner-svn-src-head@freebsd.org Sun Mar 6 23:44:22 2016 Return-Path: Delivered-To: svn-src-head@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 E1844A95B2A; Sun, 6 Mar 2016 23:44:21 +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 CCD262F3; Sun, 6 Mar 2016 23:44:21 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id C4DC1239744; Sun, 6 Mar 2016 18:44:15 -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 shortcircuit=ham autolearn=disabled version=3.4.1 Received: from android-bedfe57c17b4b0b3 (107-134-20-191.lightspeed.rlghnc.sbcglobal.net [107.134.20.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 5DC94239403; Sun, 6 Mar 2016 18:44:14 -0500 (EST) User-Agent: K-9 Mail for Android In-Reply-To: <0D2DFD32-B29F-48EA-8D60-458960993E97@FreeBSD.org> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> <5ba9554b9066227c883140c7c12e4703@mail.lifanov.com> <0D2DFD32-B29F-48EA-8D60-458960993E97@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: svn commit: r296428 - head/sys/boot/common From: Nikolai Lifanov Date: Sun, 06 Mar 2016 18:44:11 -0500 To: Dimitry Andric CC: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, owner-svn-src-head@freebsd.org, Oliver Pinter Message-ID: X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 23:44:22 -0000 On March 6, 2016 4:13:34 PM EST, Dimitry Andric wrote: >On 06 Mar 2016, at 20:57, Nikolai Lifanov >wrote: >> >> 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"). > >Well, each time you run make installworld, almost all the files in >/boot >(except for configuration) get reinstalled. For e.g. mbr, boot1 and >such, this has no consequences at all, until you install them into some >partition using gpart, but changes to loader, loader.efi or zfsloader >*will* affect the next startup. > >Per a suggestion from Kostik, maybe it would be nice to have a separate >"make installboot" target, which installs just the components in /boot. >This could then be used before or after "make installkernel". > >-Dimitry The bootcode gets installed to boot, but deployed with gpart, cp, sliced in half and dd, etc. And that's to one or more partitions. I don't think that a separate install target that just stages boot1 to /boot is valuable. - Nikolai Lifanov