From owner-svn-src-head@freebsd.org Mon Mar 7 00:56: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 1E8D8A931C9; Mon, 7 Mar 2016 00:56:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 E4580E68; Mon, 7 Mar 2016 00:56:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x229.google.com with SMTP id n190so115822056iof.0; Sun, 06 Mar 2016 16:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Jhn/jbM0sPTc33EMk+a9Zk51lTvXska81qc0H5mSPDY=; b=eIyBpsmnQAWispn/1LtzyRm6a7gH9jupzI9RezfdskM4umt1adVlhZCyzZHVMlEUaW 6gzSu/XjlgMhBcRKdiB9sZLGywNVlQj9a+3jYjSDR9SCJO59UsPofCErXm0VviAWBCq1 gwygbq3WHWjrFMF8iY1dOEflJyaYY8Xztc7EXviLSpqswve7uApEv4zZVc3/7sDmERir t52+IbgVInchEZECFTxDHu29ceYccQVDHCAIPtDVLSaBNjWamBsUTuoe/fVCuWk+zQ9B E+MGBsMusiqc+/rtbTQpZ5cmj45Z8LWX6UvTdeP1e5syvelSGYzcuyupLrjHOZM2yA+8 vYQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Jhn/jbM0sPTc33EMk+a9Zk51lTvXska81qc0H5mSPDY=; b=HwDYbpU5EHxc4mD+t2gGfxVtjU7fJU10YiLah0blNmtuC30RhN3CqNtm4Tgvlu6TQH 3arPZHesvOIi6GqO83jNDsx2GXaMsa82P4VdEL9d2aPuxqV1vJqJLfVdsXzcVEMc2Bxc v4tVxu32KvnSxvPkctEK/SPIIvWDQztBZV2N1uVNURMirMH7VDzweUE8422Pfty3EA1x mhD4Y4ZXe+ZLKEfGKYtAY/QYVzXLMEvOZLDn58L/ERTGr6hb6CKez6P7H276nses68Ho vLFCNHLZ706hTF9WoKIbhBZvs24q5a2Ld4CVz5Jn0/V8xJmD/crpynZqc1jmTegqDDj2 unrA== X-Gm-Message-State: AD7BkJLmIyuqNbZdUuy5+vAAmEwfLOx5k8/kHEW+HW6gAv+9WG6RVbVQntG6ffKF7q0K3BLCo+Bn9n8ErMWQPA== MIME-Version: 1.0 X-Received: by 10.107.162.144 with SMTP id l138mr17578219ioe.123.1457312181148; Sun, 06 Mar 2016 16:56:21 -0800 (PST) Received: by 10.36.14.19 with HTTP; Sun, 6 Mar 2016 16:56:21 -0800 (PST) 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 16:56:21 -0800 Message-ID: Subject: Re: svn commit: r296428 - head/sys/boot/common From: Adrian Chadd To: Warner Losh Cc: Nikolai Lifanov , 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-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:56:22 -0000 Oh wow, i didn't know at all that limits broke booting in this way. Sorry :( This is the first time I've heard about it. -a On 6 March 2016 at 16:38, Warner Losh wrote: > > > 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