From owner-dev-commits-src-all@freebsd.org Mon Mar 1 16:50:24 2021 Return-Path: Delivered-To: dev-commits-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BC943564273; Mon, 1 Mar 2021 16:50:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dq5q44nJbz3CMR; Mon, 1 Mar 2021 16:50:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8E37E34A05; Mon, 1 Mar 2021 16:50:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f54.google.com with SMTP id dj14so829331qvb.1; Mon, 01 Mar 2021 08:50:24 -0800 (PST) X-Gm-Message-State: AOAM533rheAmQNdoGEDl0x2vlYvlnkAjcDxtK4gIHAoZs/VRPy4Dy8ZZ ZumnoBE2vD4AMA7+jYC9kmXB1xkj+bqTOspnG1g= X-Google-Smtp-Source: ABdhPJxxtvD84NcW4djlS83mCTjJicYJU1oKQuYygD+jaxWl/tvsCAed5xJwDmwV81mdlHqge784reCPNtxJ87LC7HY= X-Received: by 2002:a05:6214:1424:: with SMTP id o4mr15704344qvx.34.1614617424200; Mon, 01 Mar 2021 08:50:24 -0800 (PST) MIME-Version: 1.0 References: <202102232124.11NLOT27012354@gitrepo.freebsd.org> <583f83d8-c78b-d961-d2c5-9693bd36563b@freebsd.org> <743fd126-2077-49b1-9c85-7ccc61616b98@www.fastmail.com> <460ceb98-e0c1-42b3-8e3c-2587c5ce8398@www.fastmail.com> <8215cd95-6905-49da-ab07-65796845613c@www.fastmail.com> <82f307a1-d7e2-0950-510d-148a1a7e61a2@freebsd.org> In-Reply-To: <82f307a1-d7e2-0950-510d-148a1a7e61a2@freebsd.org> From: Kyle Evans Date: Mon, 1 Mar 2021 10:50:10 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: 0b7472b3d8d2 - main - Mount the EFI system partition (ESP) on newly-installed systems. To: Nathan Whitehorn Cc: Brandon Bergren , Warner Losh , Kevin Bowling , Jessica Clarke , Colin Percival , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev-commits-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 16:50:24 -0000 On Mon, Mar 1, 2021 at 10:45 AM Nathan Whitehorn wrote: > > > > On 3/1/21 11:42 AM, Kyle Evans wrote: > > On Mon, Mar 1, 2021 at 10:39 AM Nathan Whitehorn wrote: > >> > >> > >> On 2/28/21 3:44 PM, Brandon Bergren wrote: > >>> On Sun, Feb 28, 2021, at 2:25 PM, Warner Losh wrote: > >>>> Yes. I agree as well. I was just hoping to say just that: EFI is barely > >>>> theoretically possible, but in reality we'll likely never use it.... > >>>> > >>>> The net effect is that we don't want to install efi on powerpc on freebsd. > >>>> > >>>> Warner > >>>> > >>> Yeah. The code before the change excluded mips and powerpc platforms, and it should continue to do so instead of using the existence of a /boot/efi directory as the only clue. > >>> > >>> Currently bsdinstall bails out and leaves powerpc* in a half-installed state because the die in the uname case propagates to the main script, so it never runs the bits after the bootconfig. > >>> > >> So that was a deliberate choice to keep the list of places that know > >> about efi vs. non-EFI centralized. I'd prefer to just not make that > >> directory on systems where it doesn't apply rather than messing with the > >> installer. Do you know where it is being made? > >> -Nathan > > It's part of the hierarchy in ^/etc/mtree/BSD.root.dist > > > > Is there a reason it needs to be? The installer bits all make it when > needed already, so just removing it there seems like the simplest path. I can't think of a reason, as long as both the release(7) scripts and the installer create it as needed -- I note that vmimage.subr seems to create it itself, but arm.subr seems to get it wrong atm. It'll need to create /boot/efi for PART_SCHEME == GPT, and /boot/msdos should probably be scoped down to PART_SCHEME == MBR where it's used at the moment.