From owner-dev-commits-src-all@freebsd.org Wed Mar 3 14:09:13 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 817E756B8D6; Wed, 3 Mar 2021 14:09:13 +0000 (UTC) (envelope-from nwhitehorn@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 4DrG893FWxz3nV7; Wed, 3 Mar 2021 14:09:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (unknown [IPv6:2601:405:4a00:acd:cc7b:682b:f804:9afd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: nwhitehorn/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 1CCEA223BC; Wed, 3 Mar 2021 14:09:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) To: Warner Losh , Ed Maste Cc: "Rodney W. Grimes" , Brandon Bergren , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202103021856.122IuYgV048086@gndrsh.dnsmgr.net> <3d947e4c-a529-0b27-a8d7-415600783e53@freebsd.org> From: Nathan Whitehorn Subject: Re: git: 2c26d77d989a - main - Remove /boot/efi from mtree, missed in 0b7472b3d8d2. Message-ID: Date: Wed, 3 Mar 2021 09:09:12 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US 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: Wed, 03 Mar 2021 14:09:13 -0000 On 3/2/21 10:19 PM, Warner Losh wrote: > > > On Tue, Mar 2, 2021, 7:01 PM Ed Maste > wrote: > > On Tue, 2 Mar 2021 at 19:30, Warner Losh > wrote: > > > > There has been some talk of moving the mount point to /efi, but > I think that went nowhere... > > I thought about /efi based on arguments from the Linux world, more > info at > https://wiki.archlinux.org/index.php/EFI_system_partition#Typical_m= ount_points > . > I did open https://reviews.freebsd.org/D28814 > to move the existing > uses to /efi. That said, I'm much more interested in us picking > something and using it in the installer/other tooling than whether > it's /boot/efi or /efi. > > > Me too. I am actually open to either. If I had a do over, I'd pick=20 > /efi honestly. > > But the directory presence or absence shouldn't be used to know if we=20 > have an ESP to deal with or not. > > Warner > It would have been nice to know that when I posted the original patch=20 for review that relied on this mechanism two weeks ago and you and Ed=20 both signed off. Or when we discussed this on Friday and no one knew why = it was in mtree -- I still honestly don't know from this thread -- and=20 then I proposed removing it and everyone said that was fine. There are=20 lots of other directories that we make in the installer that aren't in=20 mtree. What's special about this one? The problem here is that the installer needs to know if an ESP has been=20 made. If /boot/efi is supposed to be the mountpoint for an ESP, its=20 presence seemed like a reasonable way to signal that. Here are some optio= ns: - We could try to see if a partition is actually mounted there. That's=20 mildly annoying -- it involves parsing some shell output -- and results=20 in making a pointless directory on all non-EFI architectures. - We could try to have the installer signal to itself via some temp=20 file. This seems fragile and complicated. - We could duplicate the logic for whether to make an ESP in the first=20 place in several places, which seems like a terrible idea. But this needs to be settled *now*. It's already very, very late to get=20 this into 13.0 and we can't have another cycle of changing our minds=20 about reviewed code. -Nathan