From owner-freebsd-current@freebsd.org Mon Sep 17 20:34:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCE2610A6C68 for ; Mon, 17 Sep 2018 20:34:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72DFD8C1E4 for ; Mon, 17 Sep 2018 20:34:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x230.google.com with SMTP id 139-v6so148250itf.0 for ; Mon, 17 Sep 2018 13:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=A/Vvk97l/j+VrM1KgagWiKIF7T+RgHWKkdK2AyCF+nE=; b=WuY9Tnb0Y5+Zfrvi6lQkVwr51rnmDajeC8lDnwK7IiY7kzOZqTJ+occ6WubM3KIRGH /kseecuxxPj4QWkKTs6YxGMZvOLCxNn8UQck8NyVFn9W4Sn4cS42gPBRT3uO1zhvTn0U 5AFGcAyIyzyUekGTmMd0fJxC/zPOECjoZIY9UgthHIw6NaXWrW4YSA6ij8xxzEtr9IPZ 0Umi6DyGkAcAcLZR9s0pEVzpo7LVuG7jdSfGfVPBdzypY9dj76qJBDhTg0iI/FQiArSO l3w3OBS3ttvdtOZwe/iuhsbGa4tlCBGFR66BR+ZwiH4AGi1+7WleV/xiFddiL4K1/F6f jc3w== 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=A/Vvk97l/j+VrM1KgagWiKIF7T+RgHWKkdK2AyCF+nE=; b=Dv8mhXRMUY4wHjsKLLMSgKin2XlbNg/nXIxJctm2cTbRLT+loHhUbL+lNG7PYe2WoR jBLXhjv2Nndk4DDGLvy7emE6pY1ktNDcnptLCPeInZx1WTEnYgW7RhBjjT89XEdKxjyA 6wBFDgwhvFdmNIbjNKiQH5HOXcbEp/H2YgRwHEigvJUVqCYOLYie/9y1DKYL+NkIVFr+ MxWc7H/2diyrudiV5Kg/Cei8e2V4Jtwb2qMzObaH7KgOR6jDnXYis6T/VTTy3JlG9seE 5Z9R/GbotyUh4nYTyiJM8wSrHk2f3O9kXglmrVy2CJkWrY5BJuLMWYlznM8CRDkrip65 XqSQ== X-Gm-Message-State: APzg51D8fp8QU1ML9RshLZdHZJiy+ujL/xPPTVmTUtqMwXr5p8xoB/bS 0W7RZaTxKM57KZWzAzK1VEEyvSs3XRIfNUBUPfY= X-Google-Smtp-Source: ANB0VdbB9WFuxJERUtqN65jXsEbNLu0GMcKW5RbBD0IjpXHVv2kNUvd7hk9rpFRUB+aDaKEomxo2OmW0LdNDOlnpCCs= X-Received: by 2002:a24:728f:: with SMTP id x137-v6mr722458itc.40.1537216482850; Mon, 17 Sep 2018 13:34:42 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:404:0:0:0:0:0 with HTTP; Mon, 17 Sep 2018 13:34:22 -0700 (PDT) In-Reply-To: References: <1dbeee10-857e-7fb2-dac2-1047353739ba@bluestop.org> <3ce6e6cb-a608-2969-09d4-201df07df586@bluestop.org> From: Ed Maste Date: Mon, 17 Sep 2018 16:34:22 -0400 X-Google-Sender-Auth: T0qMniqOyoXauhgNNH-S8Gu_TXI Message-ID: Subject: Re: FreeBSD EFI projects To: Warner Losh Cc: Rebecca Cran , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2018 20:34:44 -0000 On 17 September 2018 at 14:17, Warner Losh wrote: > Items on my list are: > > (1) Retiring boot1.efi entirely before 13.0. It was originally designed to > be a small, never changing blob we'd toss into an ESP and have all the > smarts in loader.efi. I'd go further than this: it was originally designed as a stopgap to have FreeBSD work in an EFI world when we didn't support the standard UEFI interfaces and did not have a straightforward way for loader.efi to find its script/configuration files in a different partition or filesystem. As far as I recall it was never intended to be a permanent part of the UEFI boot process. We'll probably reacquire a small first-stage UEFI boot component: the UEFI Secure Boot shim loader. But it can load loader.efi from the ESP and won't be used outside of Secure Boot configurations. > Moving to a > 'standard' setup for EFI would be a good first step, as well as having a > script to do this both for when the ESP is mounted in a non-standard place, > as well as for when it's not mounted. I'm not sure how far we have to go in catering to non-standard configurations. I completely agree we should have a standard EFI configuration and should support seamless upgrades in that configuration. For other cases I'd personally just ensure we've fully documented the components and processes.