From owner-freebsd-arch@freebsd.org Tue Mar 26 05:03:43 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8CEB1562FA4 for ; Tue, 26 Mar 2019 05:03:43 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 226A275CC3 for ; Tue, 26 Mar 2019 05:03:43 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id D5AFA1562FA1; Tue, 26 Mar 2019 05:03:42 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95D181562FA0; Tue, 26 Mar 2019 05:03:42 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C01475CC0; Tue, 26 Mar 2019 05:03:41 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q53Y3k083257; Mon, 25 Mar 2019 22:03:34 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q53Ydo083256; Mon, 25 Mar 2019 22:03:34 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 22:03:34 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 0C01475CC0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 05:03:44 -0000 > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > We started installing /boot/loader with install world in FreeBSD -3.x > > and > > > > it has affected the boot ability that whole time... in the early days > > of > > > > loader, the kernel loader handoff protocol was immature enough to need > > a > > > > matched kernel. But that period lasted only a few months... loader has > > > > also been weird in other ways as well, since some embedded systems > > used the > > > > one in its, while others needed an extra step. As UEFI support has > > matured > > > > we're finding there are several issues around it as well where > > updating the > > > > ESP needs to be tied to updating /boot for the system to work > > sometimes. It > > > > has grown more complex over time, so we should separate. It's been a > > little > > > > weird on all the non x86 platforms to different degrees, but now that > > our > > > > main platform is affected it's become clear we may need to change. > > > > > > > > But we need to do so carefully as this violates POLA in a huge way, as > > well > > > > as needing doc changes in a bajillion places. > > > > > > I think we should treat files on the ESP the same way we treat other boot > > > blocks. installworld should continue to install the latest version into > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > I think the main difference here is that traditionally other boot blocks > > > didn't change very often, so no one really needed to update it them > > > post-install. loader.efi changes often enough we probably need to > > document > > > updating the ESP as an optional step in the upgrade process. I think > > > having an automagical script will probably go sideways, but standardizing > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > > > we can provide a script with defaults (or instructions) that work with > > > the standardized approach. > > > > Is there anyway to stash an easy to extract "version" in > > loader.* so that a Makefile/.sh script could easily check > > to see that your boot code is == `uname -KU` and just emit > > a warning at the end of installworld? > > > > No. There is no simple version we can check to make sure things are a > matched set.. Then I would call that a pretty fatal flaw in design. There needs to be a way to find out what version of "loader" /boot/loader.efi is there. I was also not asking if we have a way now, I was asking if there was a way to implement, and I doubt the answer to that question is no. > Warner > > John Baldwin > > Rod Grimes rgrimes@freebsd.org 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 Why does your mail client wrap my <70 column signature? -- Rod Grimes rgrimes@freebsd.org