Date: Thu, 4 Mar 2021 13:57:58 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: rgrimes@freebsd.org, Emmanuel Vadot <manu@bidouilliste.com> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Warner Losh <imp@bsdimp.com>, Brandon Bergren <bdragon@freebsd.org>, Ed Maste <emaste@freebsd.org>, src-committers <src-committers@freebsd.org>, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 2c26d77d989a - main - Remove /boot/efi from mtree, missed in 0b7472b3d8d2. Message-ID: <11c7fc3b-3b94-c56f-5755-44a5cb7ab884@freebsd.org> In-Reply-To: <202103041512.124FC8KV056114@gndrsh.dnsmgr.net> References: <202103041512.124FC8KV056114@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/4/21 10:12 AM, Rodney W. Grimes wrote: >> On Thu, 4 Mar 2021 06:56:11 -0800 (PST) >> "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> wrote: >> >>>> On 3/3/21 10:38 AM, Warner Losh wrote: >>>>> >>>>> On Wed, Mar 3, 2021 at 7:13 AM Nathan Whitehorn >>>>> <nwhitehorn@freebsd.org <mailto:nwhitehorn@freebsd.org>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11c7fc3b-3b94-c56f-5755-44a5cb7ab884>