From owner-freebsd-arch@freebsd.org Sat Dec 16 15:31:37 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 5E25FE85BC0 for ; Sat, 16 Dec 2017 15:31:37 +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 3010668533; Sat, 16 Dec 2017 15:31:37 +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 46C516352; Sat, 16 Dec 2017 15:31:36 +0000 (UTC) Subject: Re: loader.efi architecture for replacing boot1.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> From: Eric McCorkle Message-ID: <23c05735-4046-a41f-676c-877d9f07d5f8@metricspace.net> Date: Sat, 16 Dec 2017 10:31:35 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 15:31:37 -0000 On 12/16/2017 00:49, Warner Losh wrote: > CD/DVD booing won't break. We'll still load a kernel from them. No > boot.config needed for this case (though it might be for others). How is that possibly going to work for a liveDVD on a random system? People expect it to "just work" (meaning, it correctly guesses the kernel, then loads it). I can see it working with boot.config (which I'd be fine with), but if we don't search the CD drives, there's no way it can work. > But for now, loader.efi has got to work whether installed > in a boot1/loader (legacy) configuration, or installed directly to the > ESP.  Otherwise, there's going to be a lot of unhappy people out there. > > Correct. My proposed behavior will do just that, and if we get it wrong > by default (a) you can be explicit with boot variables or (b) you can > type something into the OK prompt, which you didn't have before. No, I'm talking about people with existing installations, which still have both boot1 and loader.efi. A change this big needs to be phased in over time, which means both modes of operation need to be supported for a while.   > As for the fallback search, it's just that: a fallback mechanism.  Its > job is to make a sane guess as to where to find the system, but > ultimately it's not doing anything the user can't do themselves.  And it > will only run if the EFI vars aren't set anyway, so it can't possibly > interfere with any of that. > > > And the fallback mechanism of typing what you want is wrong because? Because every single person out there with an install is going to suddenly have to type, and that's going to lead to a whole bunch of people saying we broke loader. > But it's job isn't to guess. If we don't know for sure what to boot, it's > our job to fail so the next OS in the list gets a shot at booting. That won't happen though. If loader fails to find an installed system, it drops out to a prompt, but it doesn't exit. Given that, it makes sense to make an effort at finding an installed system.