From owner-dev-commits-src-main@freebsd.org Thu Mar 4 18:57:59 2021 Return-Path: Delivered-To: dev-commits-src-main@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 8E6485557C3; Thu, 4 Mar 2021 18:57:59 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Ds0Vv3cxpz4jBQ; Thu, 4 Mar 2021 18:57:59 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (unknown [IPv6:2601:405:4a00:acd:5d1e:c500:751e:7e8c]) (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 14AD42F8E3; Thu, 4 Mar 2021 18:57:59 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Subject: Re: git: 2c26d77d989a - main - Remove /boot/efi from mtree, missed in 0b7472b3d8d2. To: rgrimes@freebsd.org, Emmanuel Vadot Cc: "Rodney W. Grimes" , Warner Losh , Brandon Bergren , Ed Maste , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202103041512.124FC8KV056114@gndrsh.dnsmgr.net> From: Nathan Whitehorn Message-ID: <11c7fc3b-3b94-c56f-5755-44a5cb7ab884@freebsd.org> Date: Thu, 4 Mar 2021 13:57:58 -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: <202103041512.124FC8KV056114@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for the main branch of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 18:57:59 -0000 On 3/4/21 10:12 AM, Rodney W. Grimes wrote: >> On Thu, 4 Mar 2021 06:56:11 -0800 (PST) >> "Rodney W. Grimes" wrote: >> >>>> On 3/3/21 10:38 AM, Warner Losh wrote: >>>>> >>>>> On Wed, Mar 3, 2021 at 7:13 AM Nathan Whitehorn >>>>> > wrote: >>>>> >>>>> >>>>> >>>>> On 3/3/21 9:05 AM, Brandon Bergren wrote: >>>>> > On Wed, Mar 3, 2021, at 6:53 AM, Rodney W. Grimes wrote: >>>>> >> What am I missing here?? One place I am being told this is run in >>>>> >> an environment that may not even be an EFI booted system, and in >>>>> >> another place it is being used as a test if something is mounted >>>>> >> on it, which should only be true on an EFI booted system. >>>>> > That the script in question is a generic script that runs as >>>>> part of bsdinstall on every platform and has to be universal. >>>>> > >>>>> > The actual *problem* here is that >>>>> usr.sbin/bsdinstall/scripts/bootconfig has a default case that is >>>>> >? ? ? ? ? ? ? *)? ? ? ? ? die "Unsupported arch $(uname -m) for >>>>> UEFI install" >>>>> > >>>>> > which then causes the main script to bail out, leaving the >>>>> system in a half-installed state. >>>>> > >>>>> > If that had just been an exit 0 this would have never been a >>>>> problem, I suppose. >>>>> > >>>>> > Before the original change that broke this, there was a check >>>>> that the script was not running on powerpc or mips platforms >>>>> before running the efi bits, but this got taken out. >>>>> > >>>>> >>>>> Well, incidentally. The bootconfig script needs to know if there >>>>> is an >>>>> ESP it should configure, but the signalling mechanism (the >>>>> presence of >>>>> the ESP mount point) was being broken by mtree making that directory >>>>> unconditionally even on systems that don't use EFI. So then >>>>> bootconfig >>>>> tried to set it up, but failed later on, because there was no EFI >>>>> loader >>>>> to set up. The mtree change makes the ESP mount point only exist on >>>>> systems with an ESP. >>>>> >>>>> >>>>> So you made a unilateral change, without discussion of the bigger >>>>> design, to something without even asking the original person who made >>>>> the change to mtree about it for what sounds like an obscure case in >>>>> the installer that could be solved in a different way? It's trivial >>>>> enough to look at the boot method sysctl and skip the EFI update if we >>>>> didn't boot EFI (and if by change that's not on all systems, it's easy >>>>> enough to add it on all systems). I have no notion about why that >>>>> wasn't considered, at least, before jumping in and taking people by >>>>> surprise. >>> I still do not understand why machdep.bootmethod=EFI was rejected? >>> Is this value not present on ALL platforms that boot in EFI mode? >>> if exist(machdep.bootmethod) && machdep.bootmethod=EFI seems to >>> me to be the best and valid way to make this decision. If that >>> has issues working on a platform we need to fix that issue and not >>> do all this other stuff. >> We need to install and create the efi dir even if the installer is >> booted in CSM mode, so a user can switch to full uefi mode after and >> still can boot the FreeBSD that was installed. (The same thing must be >> done for bios boot code). > Ah, yes, ok, I see that issue, but isnt that driven by the fact > the user has selected GPT (EFI) in the disk menu, so could be > drive by an installer variable like any other aspect of the > installer? Passing around the users install parameters via > the file system is fragile as noted else where, this information > should be clearly avaliable within the installer script itself. > > The installer does not maintain state internally and system configuration is decoupled from partition editing to avoid precisely the kind of fragility you are worried about. -Nathan