From owner-dev-commits-src-all@freebsd.org Mon Mar 1 19:34:56 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 72AC154A09C; Mon, 1 Mar 2021 19:34:56 +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 4Dq9Sw2QX1z3jqh; Mon, 1 Mar 2021 19:34:56 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (unknown [IPv6:2601:405:4a00:acd:85ea:d09e:32a:9875]) (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 D950F35E99; Mon, 1 Mar 2021 19:34:55 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Subject: Re: git: 0b7472b3d8d2 - main - Mount the EFI system partition (ESP) on newly-installed systems. To: Brandon Bergren , Kyle Evans Cc: Warner Losh , Kevin Bowling , Jessica Clarke , Colin Percival , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202102232124.11NLOT27012354@gitrepo.freebsd.org> <460ceb98-e0c1-42b3-8e3c-2587c5ce8398@www.fastmail.com> <8215cd95-6905-49da-ab07-65796845613c@www.fastmail.com> <82f307a1-d7e2-0950-510d-148a1a7e61a2@freebsd.org> <6611975a-f126-4a65-9a48-d3ed73c4d073@www.fastmail.com> From: Nathan Whitehorn Message-ID: <836d1eb1-83dd-e704-56c3-e351e7817c59@freebsd.org> Date: Mon, 1 Mar 2021 14:34:55 -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: <6611975a-f126-4a65-9a48-d3ed73c4d073@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 01 Mar 2021 19:34:56 -0000 On 3/1/21 1:39 PM, Brandon Bergren wrote: > On Mon, Mar 1, 2021, at 12:28 PM, Brandon Bergren wrote: >> >> On Mon, Mar 1, 2021, at 11:54 AM, Nathan Whitehorn wrote: >>> The /boot/uboot in BSD.root.dist also looks like cruft to me, but maybe >>> best to leave for now? >>> -Nathan >> It's used on Book-E powerpc* in some cases (and the bootloader is >> compiled and installed there by default on powerpc*) but it's a regular >> directory. I don't believe there's any custom behavior to treat it as a >> mount point because setting up booting is a machine specific thing in >> this case, and the user is expected to do something like copy it to the >> boot server or a partition on the bootstrap media. >> >> For example, on the X5000, the boot firmware is stored on an onboard SD >> card that has space left to install loaders and stuff, but this is >> something that is set up by hand. >> > Another thing to be aware of: > > On PowerNV (and Playstation 3, although that has bitrotted a bit), we currently use a ms-basic-data or fat32 partition mounted as /boot so that petitboot can load the kernel for direct execution. We do this because fat32 is the only filesystem we have in common with petitboot that we can easily write to. > > Be aware of this when changing detection behavior that we do in fact need this mounted as /boot and not as a subdirectory because of the way we currently do direct-execution on PowerNV. At the moment the behavior is isolated in partedit/partedit.powerpc but if the generic scripts are changed in a way where some assumption that /boot itself lives on the root filesystem comes into play, that they will have to special-case this. > This is one reason I really don't want any of this mechanism to be generic. I'd like the knowledge about the layout to be limited to the partition editor, which can signal to later parts of the install/upgrade process as needed. As written here for EFI, it is meant to do this by the presence of the EFI partition. -Nathan