From owner-svn-src-head@freebsd.org Mon Mar 7 00:38:54 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 0EA8DAC1CA2 for ; Mon, 7 Mar 2016 00:38:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8A3E860 for ; Mon, 7 Mar 2016 00:38:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id n190so115555299iof.0 for ; Sun, 06 Mar 2016 16:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=NXQOs8vL6zG7D4RisOAPdmtJON1AedIHxbVCqDRXGBc=; b=rKsYddddX7tkr8kGdFnv5FJkNKlRCnXzhl2j0efuavu4Z+j6eWZjRpuHCWQbAk3U7Z 0uh6r9pAB0j018Bji8m+E1HVAMUVCp/uAXxWqWys7DoyJo32G4y1Bmyen5KIQAcs7l/a H/ELyDk+XPa/9vQjbEVj+L6ioD4SwN1bykv8XeXhwcKbD4UzxqC862qmYimSLzHvPPgJ W05VAggIRy6g73amOF/8zfC//Vi3r5/J/QKgy7sF7Q9TAigz4HfxhRZo4F1hQN1a5T8e I4+m7QlDsNkXS26O/TI+uypVK04utD9GGecc9AC77/3O5SV/DQ2kl/m7LzEe7FPD+j8e wQLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NXQOs8vL6zG7D4RisOAPdmtJON1AedIHxbVCqDRXGBc=; b=JNqtYqLEAViYDIGqsrSFUvsOXfbLHZ/s+t4tJYbR7BgxsTy2HJe3ErEBFWUGJ2ovvc 4Ijkcf2r2XdGo39pSGv62TW2QWKqbAm2c0huvl5gZIvCb9DFZm+37LWmo3013hZW3jAS DcEK0MWKuWO9dwYtjtyROX8qHnUgD94qKN8L0mFdC7LyNv3reub1ZrPBpyqpHHPuC/hf GYhBA6uhzlOqA9ciVUo7VxRkUvD+4CslUDEmsZA//ei/m8oXS/xUGJfU8eeodccIZQ9p rqQVKyN7cWt94DaK73ecyPGmZricXugawkC3FDMwn9wOIoQT7JjHW1r7b42UP83nwNhe bMwQ== X-Gm-Message-State: AD7BkJL9PiN4Ymj1W5JciADHVl4TMdbOwmrWwu7A5ywO3RXyZ6L4K6HKJ4ZT/uiLkK3fXm44wnlIuyhfTIZUfw== MIME-Version: 1.0 X-Received: by 10.107.14.209 with SMTP id 200mr18007774ioo.73.1457311133134; Sun, 06 Mar 2016 16:38:53 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.36.65.167 with HTTP; Sun, 6 Mar 2016 16:38:53 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <201603061557.u26FvhMi033982@repo.freebsd.org> <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> <5ba9554b9066227c883140c7c12e4703@mail.lifanov.com> <0D2DFD32-B29F-48EA-8D60-458960993E97@FreeBSD.org> Date: Sun, 6 Mar 2016 17:38:53 -0700 X-Google-Sender-Auth: SZTxryjxMKnWCAvG-LxYRiKW0BE Message-ID: Subject: Re: svn commit: r296428 - head/sys/boot/common From: Warner Losh To: Nikolai Lifanov Cc: Dimitry Andric , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers , owner-svn-src-head@freebsd.org, Oliver Pinter Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Mon, 07 Mar 2016 00:38:54 -0000 On Sun, Mar 6, 2016 at 4:44 PM, Nikolai Lifanov wrote: > 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. > I think it is. First, the boot code you talk about doesn't matter *AT*ALL* for this change. It needn't be deployed to be safe. We've had a few rare cases where you do need new boot code as well, but they seem to happen about once a decade or so. Personally, I always install both a kernel and userspace at the same time when upgrading, though sometimes just the kernel. Usually it just doesn't matter. In this case, I'll know I need new boot blocks. I'm kinda of the opinion that the boot loader should be part of installkernel, but I can see how others may disagree and that's likely too much POLA to do now (it should have been done in the 4.0 time frame when we went to a tertiary boot loader). With the recent expansion of limits, however, it's become critical that you have a new kernel on boot so that limits used by the rc system are set correctly (the new code has no fallback, but fails for limits it doesn't know about, which is super lame, and should be fixed, but until it is we're stuck with needing a new kernel. This also means, btw, that a 10.x kernel has no chance of booting an 11.x userland, which is somewhat contrary to traditional practice in the project). Warner