Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Oct 2017 21:46:02 -0400
From:      Eric McCorkle <eric@metricspace.net>
To:        freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>
Cc:        Warner Losh <imp@freebsd.org>
Subject:   New behaviors for loader.efi
Message-ID:  <ecfa88fb-be25-0c47-ee24-ef6511dccd9e@metricspace.net>

next in thread | raw e-mail | index | archive | help
Following the earlier discussion on the fate of loader.efi, and in light
of my GELI work, I've begun working on modifications to loader.efi to
allow it to be installed to the ESP, while maintaining
back-compatibility with the legacy system.

There's a couple of points that probably warrant discussion before I go
any farther.

First, we'll need to figure out what to do with boot.conf, which
previously contained the arguments that would get passed to loader.
Personally, I think the logical place for this is /efi/boot/config or
/efi/boot.conf

Second, does loader.conf exist on the boot filesystem, or should it also
exist on the ESP?  I'm inclined to think this should be left on the boot
filesystem, as there may be more than one, and it's potentially specific
to the kernel installed there.

Last, loader has typically relied on the fact that it's installed
directly on the boot filesystem, so it can obtain a good initial
currdev/loaddev.  If it's installed on the ESP, it potentially has to go
hunting for the boot device.

I'm stealing (back) code from my boot1 refactor for this, which first
looks at partitions on the same disk, then looks at all devices.  The
actual test, I'm thinking, is to look for /boot/loader.conf,
/boot/kernel/kernel, and possibly other files.  Of course, we also need
to retain the legacy behavior so that existing systems don't break.


So I'm thinking the overall procedure looks like this:

1) Parse command-line args (this is to maintain back-compatibility)

2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args
inside as if they were extra args

4) If loaddev/currdev are set by command-line arguments, use them as-is
and stop

5) Otherwise, try the legacy currdev/loaddev detection scheme (this will
fail if we're installed to the ESP)

6) If that fails, check the preferred devices

7) If that fails, check all devices

8) If that fails, continue without a currdev (which will drop us to the
loader prompt)


What do people think of this procedure?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ecfa88fb-be25-0c47-ee24-ef6511dccd9e>