From owner-freebsd-current@freebsd.org Tue Dec 19 21:50:01 2017 Return-Path: Delivered-To: freebsd-current@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 3CADDEA2C8E for ; Tue, 19 Dec 2017 21:50:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 F39516D0DB for ; Tue, 19 Dec 2017 21:50:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id f18so10086578ioh.1 for ; Tue, 19 Dec 2017 13:50:00 -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=FbY1eZLelyVJSC05ZntVJvfPX/r0qCMOHBdSreBg3oM=; b=IL9oRIGsvbnHNE56EslldDbKNSQzbMbrOEzgR9U43GxbqVWU+szl6iy2nZzaYE9whG POv7q5SmF898jPHz63xSjrbiGO5+RHuHMn399hmMlbMI103CKBFTVDwuOgkQX7SOYB/6 8bRxRLO8SQoVK1TnPD3SGMK1qvrIdpFFhECf0T+naqOdjE9U6dXnS500sBfqnel4gj46 HtXE1+tno1iSKJzG/qOxuSL/OQuyhxF2DIC8dxBx58pwmnM5IciCZD6glTeu8vr48RhG eQLwynTagRvpfqqLcJY28Sf/jkOTPfRPeDLNdD098xKwQrFb7kdXvF8vdgF/gFEpu5GB n3cg== 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=FbY1eZLelyVJSC05ZntVJvfPX/r0qCMOHBdSreBg3oM=; b=foBlT7n+ztzxCJxLjgMBAf8p55gzYJWjAd+GrCuwfrAIcaVNZ2HvMHTw7r9e7jDQZO tkK0dRtOqQIWHlPvZM/ao4oWF7ny2t9O+VrpQOdM7lcQmmrPPPefgCpT9d2kQs2udvsO 0mIjCh/1fveV0euXqS7uGCu16wi1LEebqH20xrOS289MSR4D8C0HkqAYurMl8hRbHdJI 7XeNoAPJMxh2dzqiDzsam8k4dODSHt7kKKp2igr31KVw6LOJu+pytvw6eyXX/9T33nJ6 /Q7GU4K2SnwVa7iikk/5ncqxaWXeY05eDqvIg+HCvLlJtT5ZWgd55i592AZz76D65bGO HqGQ== X-Gm-Message-State: AKGB3mIO58AWOKNXaQS1EBYa2pdDS5Pbia5FvnZ9CZ0PLkfPBF6dyo2H 0FZFhQTvp9XzFcSY6p/CrF5QLZXYT5yr2uQTFYUiIw== X-Google-Smtp-Source: ACJfBotbKBCOYviImxfc6UcT/f2V+xyNdss8rb9YusXKdCKHuqGJkpKWuDqj53e8VUK8LaqySxyyBTSRxpfKk9cSVRU= X-Received: by 10.107.83.8 with SMTP id h8mr5502229iob.63.1513720200169; Tue, 19 Dec 2017 13:50:00 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:49:59 -0800 (PST) X-Originating-IP: [2607:fb90:6f6a:13fc:4073:f971:9d8e:a305] Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:49:59 -0800 (PST) In-Reply-To: References: <60C20606-853E-43AE-9F90-44C65026A098@dsl-only.net> From: Warner Losh Date: Tue, 19 Dec 2017 14:49:59 -0700 X-Google-Sender-Auth: vkWnR5Qy8jGJliD0hYrLbVHFkT8 Message-ID: Subject: Re: UEFI booting survey To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Tue, 19 Dec 2017 21:50:01 -0000 On Dec 19, 2017 10:58 AM, "Mark Millard" wrote: On 2017-Dec-18, at 2:37 PM, Warner Losh wrote: > . . . > > Or the following pseudo-code with all the weird special cases removed for clarity > > load loader.efi from ESP > if BootXXXX uefi variable holds a second path, use that for root/kernel > otherwise if an override variable holds a kernel/root path, use that > otherwise scan for a usable ZFS pool, use that if it exists > otherwise use the same partition loader.efi was booted from for root/kernel if it's usable > otherwise use the first UFS partition on the ESP that's usable. > > A partition is usable if /boot/loader.rc exists on that path. What will be the role of /etc/fstab in establishing were the kernel is loaded from? Where world is loaded from? Where/how does use of /etc/fstab for specifying the root file system mount fit in the above pseudo-code? Same as today: it is what the boot loader passes to the kernel as the Unix name of /. I have no plans to change that. It's of almost no use to the boot loader, since it can't know what BIOS device da3 is, for example, if that's in fstab. Or even more complex examples like /dev/mirror/primary. Efibootmgr can take Unix devices and paths and turn them into UEFI paths so we know what devices to use for what. In the absence of those, or an equivalent fallback, we are quite limited in what we can do since we don't have the context needed to translate. Warner (For my particular interest the context uses UFS, not ZFS.) > What is being deleted is one final step: "otherwise use the first UFS partition on any drive in a random order that's usable." which used to be at the end of the boot1.efi psuedo code. It's my belief that no such installations actually use this due to the random factor today (plug in a new USB drive and it might take over). If my belief is wrong, it's my belief that efibootmgr will solve it, and failing that, the fallback mechanism (for platforms that use u-boot + EFI where UEFI variables don't work) will allow the two or three people that are doing this today. === Mark Millard markmi at dsl-only.net