From owner-freebsd-arch@freebsd.org Thu Oct 26 01:46:11 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00487E59F6D; Thu, 26 Oct 2017 01:46:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id D134F64E3C; Thu, 26 Oct 2017 01:46:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6AA8F34F4; Thu, 26 Oct 2017 01:46:03 +0000 (UTC) To: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" Cc: Warner Losh From: Eric McCorkle Subject: New behaviors for loader.efi Message-ID: Date: Wed, 25 Oct 2017 21:46:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 01:46:11 -0000 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?