From owner-svn-src-all@freebsd.org Sun Mar 6 17:10:15 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 6BAA69DBCFE for ; Sun, 6 Mar 2016 17:10:15 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 06573E56 for ; Sun, 6 Mar 2016 17:10:15 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wm0-x234.google.com with SMTP id n186so55452501wmn.1 for ; Sun, 06 Mar 2016 09:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+1UdcWC12E+2aNYB994kxCrSA9YwheJZd02E3CbYQ0I=; b=DqYioVcHqQEs9pydGO5/I7vj6+nVC2CdHo+/mKgGPbHwPmDK86MQzcYziCIIGFqg19 kpE6m3H/7s9B1S4t79F/ZCPrE81goF6rehFWE2GlOsHfQB8RKhyPAcfVGAD/a5HaL86B vgJhTmq+/g4Oh6yB775aEGt830bvzjJdrO0zyWLC53XEcfE8ps3HADpTMBTH9MAYXwAk TMQPDHFsbMAhbwwpHVOGnaLfEmc8qVndG9dfvGkg1PGhs1kXH8946WAfYyrP32+iyps+ NIBxk9gOMjZRcBAbpUHr/MlI07nL4xNB9L97drvLD8m0i/qGwSuz1m5lM6VS3v6bIIfR W0NQ== 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=+1UdcWC12E+2aNYB994kxCrSA9YwheJZd02E3CbYQ0I=; b=i0JjOlqdoPLxfRmKHeOaeoy2MBaj/1o8cHikiV3iQELCv9Eja+31kIqqj3iH5I/+du HIc6Hx3FT8J7lyOOE9zj8j8NwZ+5VXJhxRAtiy68KjqhA67ZG0tbLmD9hCGcaECAL1XM IOJx5/sRrRO4vejktf5ZRNUWFylAaWEEU9SR9dzNZKKwK2WJgmbPN7f8p951QvDplgQS xOL09/vBbAvf1arfwQEKWmi34GQyaqZoVJvY/xEP08QnbY5EaJtQL7Jr8Ad2ihuBTidJ ckaUk/i2Eyt3dVoJTxvVIeoVZka+8YjqbuBeMcuIKzIWan/uHPGTu26Qf4ALrVF2227l l/qQ== X-Gm-Message-State: AD7BkJLmhr86mU5Rwz/w+04SxtwqohCD0IxxSawl/pgTMk7MQMzxgF56apeh4iNOchl3Xar2aQUbhd7xffGWo9rl MIME-Version: 1.0 X-Received: by 10.194.200.194 with SMTP id ju2mr17936563wjc.63.1457284213298; Sun, 06 Mar 2016 09:10:13 -0800 (PST) Received: by 10.194.243.98 with HTTP; Sun, 6 Mar 2016 09:10:13 -0800 (PST) In-Reply-To: <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <0FC43773-1BF0-43FF-BB97-35B482ABBE12@FreeBSD.org> Date: Sun, 6 Mar 2016 18:10:13 +0100 Message-ID: Subject: Re: svn commit: r296428 - head/sys/boot/common From: Oliver Pinter To: Dimitry Andric Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 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 17:10:15 -0000 On 3/6/16, 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? If I'm not wrong, the bootloaders are self-contained (using libstand, and statically linked) same as the kernel, so they are not depend from the other parts of the system, and they already lives under the ${SRCTOP}/sys with the kernel, so logically bootloader belong to the kernel and it's acceptable from me to update them under the installkernel phase. The question is with this method everything working fine or this would break something? > > -Dimitry > >