On 3/4/21 10:12 AM, Rodney W. Grimes wrote:
On Thu, 4 Mar 2021 06:56:11 -0800 (PST)
"Rodney W. Grimes" <free...@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
<nwhiteh...@freebsd.org <mailto:nwhiteh...@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
_______________________________________________
dev-commits-src-main@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
