From owner-freebsd-arch@freebsd.org Sat Dec 16 17:07:38 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 EFBA8E889CA for ; Sat, 16 Dec 2017 17:07:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF7B16B223 for ; Sat, 16 Dec 2017 17:07:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id m11so1435488iti.1 for ; Sat, 16 Dec 2017 09:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RuND/c8Maq1jdSunTWkoSOkEFibhxs8B872VDfNbP2Q=; b=EVPdHdVBTygVVM5fvXBzFJSbrMWzdKjtxu8WjFUpzyMcj6fcVfeA4R11sABI8toNo0 x1yfA0B6cBsd0gQe/rPuRYGMxIlwyTqSWStIdNp5uaB3iIEzKG+QHcxsdwksnuHeQ+km 3IFPDOvhO1FDPglhxHXUuz5Fw9rlqxbuaAMfYp6o6P4zfC6H3Y/5mfWcI8RXRT+FC4dt pHsfVZcU8dy6q/43fOfYNKpj6EOt8qlMtB+JJrr4h+qYrY4dQUWP4z8eHQQACRypcwnz jvylx9zG9kTyiLVdsleYLGvbO/L8AytqthcgjnB+zqVfgJTMR6AhGiTo+uay8PIN0SJJ 2ILQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RuND/c8Maq1jdSunTWkoSOkEFibhxs8B872VDfNbP2Q=; b=NfmANNOn67O0WKz6DJEV4qckDshf3IM7eV+c22Tgxu+Na6niLqN1WlPtsp0e0IVhtb yW8zeuu5id2p0ULa9ZhH4NhQMozVbPpSM+EybjgJGDIt0oUPTXpVhe1sls/reqv/lTnj uJazjQlfGAgjiOvpGFCc8QfMWjlcoKRb8g9NLKi3uJeGtThNgnNREjjOFZEnkywvP62e XE9Dl5VGP4WnqkCDsiY5rCWKyyrXSZfJQb4Hg7ANONTCemZW4BTv0Cyg0OMkqZhDUsyv wsE//JkBtLaMxHYotm8LFrGZeFTabwHvrCxlNamP2fUStbdhUnBG6ai75pvbTsFyv2ue xPlg== X-Gm-Message-State: AKGB3mKoxKLUgDtI2dFRbHkeGLNcoPupg+A9KOIf0ETKyI616EMKhuit hg6EiArhDog8WZgXjE4+BceygIF9gdvZ4XSGhKTryw== X-Google-Smtp-Source: ACJfBosN2GGBgDy+8yv3VIAyZhAMkh6y/UiugLECq+6kvl+SV8hLqRaNLISC3XEs35bSQ5O7RtARYUXbW5sJnx0snKk= X-Received: by 10.36.164.13 with SMTP id z13mr13950701ite.115.1513444057861; Sat, 16 Dec 2017 09:07:37 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 16 Dec 2017 09:07:37 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <23c05735-4046-a41f-676c-877d9f07d5f8@metricspace.net> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> <23c05735-4046-a41f-676c-877d9f07d5f8@metricspace.net> From: Warner Losh Date: Sat, 16 Dec 2017 10:07:37 -0700 X-Google-Sender-Auth: -s2kkTqO7tjpQWnW5QKLujhdZGU Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 17:07:39 -0000 On Sat, Dec 16, 2017 at 8:31 AM, Eric McCorkle wrote: > 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. And it will. It booted off the CD device, and will search the CD device (and only the CD device) for the kernel. It will find it there. How could that not 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. Unless they have a totally whacked out system, the proposed thing that I'm suggesting will just work for them. If they are booting with multiple disks where /boot/loader comes from a different disk than the boot disk, they will have to do something to configure it. The number of such people is likely zero given how fragile this setup is (it breaks when you plug in a thumb drive with a release on it, for example). > 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. I maintain no such people will have to do that. The UEFI BIOS is required to set BootCurrent and BootXXXX. However, even in the absence of this, we'll look for a ZFS pool (and disks) or UFS partition on the same disk. This should generally work by default. > > 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. > No. It doesn't. You're assuming that if we fail, the system won't boot. That's false. If we fail to boot device X, it's our job to fail so that if there's a Y or a Z it can be next. We have no knowledge of whether the user would prefer Y or Z as the next one to try, but the boot manager that runs inside every single UEFI firmware does and it will go to the next one. Y might be a recovery disk or copy of a freebsd memory stick release and Z might be a redundant copy of X to use in cases where X fails. Or vice versa. Do we want to boot to the installer? Not as a first choice, but maybe as a last resort. But we should let UEFI orchestrate the retries. Trying to second guess is fundamentally wrong, especially in UEFI where the boot order and boot recovery stuff is so extensively and particularly defined. Having fought the "oh, I'm going to guess" code in boot1.efi for over a year and after having it consistently pick the wrong thing to boot on some tiny fraction of the hundreds of systems I've had deployed give me strong empirical data that shows the guessing too hard bit is actually actively harmful. I've thought about this a lot. I've thought through all the supported scenarios. I've written up documents and solicited feedback. Nobody to date has said "oh no! I really want the random installed system roulette! I love it! Don't kill it." Warner