From owner-freebsd-arch@freebsd.org Fri Aug 11 19:39:47 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 E317DDB6E74 for ; Fri, 11 Aug 2017 19:39:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BBC90126D for ; Fri, 11 Aug 2017 19:39:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B7DF2DB6E73; Fri, 11 Aug 2017 19:39:47 +0000 (UTC) Delivered-To: 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 B774CDB6E72 for ; Fri, 11 Aug 2017 19:39:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 6D90F126B for ; Fri, 11 Aug 2017 19:39:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id d145so25959632qkc.2 for ; Fri, 11 Aug 2017 12:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=L0AFcxXw/ltWCb5jmCC3nG1NFsrH8w+Rl4uX/be82z0=; b=oh562PHoLLYtEdQSQ24pdM9mi/PJAWZTZD1uc/cuP582YQdHrO8sVZay/FxQl8fK/I ZBlRviCsOtarlp5C2gLhzQkcLwfsGmsaCfkxFCbEOhLbwS4/ZDIqtwyODR2NoQ879R5+ 8CNA7C7wRaE92keJpc7U1y+FoC0BihiMU+oRgzrSaCPkTI+/4UpLYWxCJcLnvYLrDmYb wgBEQyLpeKHc0sifg6mp2Tes5UNx0V8wJXlWKSGcpsPH/ZP2oes7P5sMbCCE4TpAgcYQ Pgrwpz8Anposz3r9vvJkhQRICc+GTV6vs7WsBvDaocjuFThNgXUUAFb2/4dWS6b3ymx2 Rhgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=L0AFcxXw/ltWCb5jmCC3nG1NFsrH8w+Rl4uX/be82z0=; b=YnC8Z5tiI4QsskHCBWnQisRvlRHJJeSI8m9aeCNw6sSH5OLyY+slh0K2qwnKYnTFKV 0FjnCp+siLYI3i0ES8uenuQxk5EODSZStnpq9x/Ppi1QB9hygyZ/j1JvwC7vZQumPPKI SzcyT7QgJV9CxA4KxxRIzlLMKokA6yBxT8OcF31W4Fcewfmw1g99RWDAP5aYxR6xh3sg gWaDvBYr5n0tCTSJCX++ZD6Rjokji+jpK66F1OdLd0BVhqV9a2G1y75p8euU6JX6uZ7b RS4x7QPdm6RnVtwa9CZnhoZLDMtsP9mJv+Niezh2MVgKPQDWyVJgGHoTWbQtfMJLUFPJ 08DA== X-Gm-Message-State: AHYfb5jL1m/dmZrYcrCSTf1LGb6VprBJ3RIm6HEzN4qZbunS6mzqzo3l B52FnhWHNyxY5g== X-Received: by 10.55.215.26 with SMTP id m26mr20180965qki.95.1502480386052; Fri, 11 Aug 2017 12:39:46 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id z189sm1005872qkc.39.2017.08.11.12.39.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 12:39:45 -0700 (PDT) Sender: Mark Johnston Date: Fri, 11 Aug 2017 12:40:28 -0700 From: Mark Johnston To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Proposed Enhancements to the EFI booting Message-ID: <20170811194028.GB19972@wkstn-mjohnston.west.isilon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) 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: Fri, 11 Aug 2017 19:39:48 -0000 On Thu, Aug 10, 2017 at 10:03:57PM -0600, Warner Losh wrote: > Greetings, > > I've been circulating a document (the latest version you can find here > https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit?usp=sharing > ) > > I'm opening it up for general comments now. I intend to turn this into a > full spec, including the bits in the UEFI standard that I reference by > pointer, and move to implementation soon once any issues are resolved. > > Warner > > FreeBSD UEFI boot protocol > > This document outlines the enhancements to the UEFI Boot Manager Protocol, > as outlined in Version 2.6 of the UEFI spec, chapter 3. It assumes that you > are familiar with that chapter and though a comprehensive doc with our > additions folded into it would be good, it hasn’t been produced. > Current Algorithm > > Boot1.efi currently searches for /boot/loader.efi using a fairly > complicated algorithm. > > First, we look for any ZFS pool that has a /boot/loader.efi on it, > consistent with its boot environment settings. If we find that, we use it. > > Second, we search all of the partitions on the device that we booted > boot1.efi off of for a UFS partition that has a /boot/loader.efi we can > load. If we find that, we use it. > > Third, we search all other devices for a partition that is UFS formatted > and has a /boot/loader.efi we can load. > > There’s some problems with this algorithm. It’s not possible to specify a > partition to boot from. We boot from the first /boot/loader.efi that’s > found, even if multiple partitions on a drive have one. Second, it’s very > non-deterministic. The second step was added to add some determinism to the > process so if you plugged in a FreeBSD 11.0R release USB stick and > rebooted, you would reboot to the installed system and not the USB > installer. It doesn’t use the ad-hoc method for identifying which FreeBSD > partition to boot off of that we use for BIOS boots since in the UEFI > runtime environment it’s tricky to get the attribute flags of a partition. > Finally, it doesn’t use the standard UEFI boot manager protocol. > Proposed Algorithm > > First, the FreeBSD UEFI Boot Loader UUID shall be > cfee69ad-a0de-47a9-93a8-f63106f8ae99 (below as FreeBSD:). The UEFI defined > global variable UUID (EFI_GLOBAL_VARIABLE) is > 8BE4DF61-93CA-11d2-AA-0D-00-E0-98-03-2B-8C (below as UEFI:) > > Boot1.efi will find what to use with the following algorithm: > > > 1. > > If the UEFI boot manager passes an optional parameter to boot1.efi, then > parse it as if it were a EFI Device Path to find the next stage boot loader > to use. If we can use that boot loader, we’re done. Otherwise, ignore it. > 2. > > Get the value of UEFI:BootCurrent. This will be a 4 digit hex number > XXXX. If FreeBSD:BootLoaderXXXX exists, and specifies a file we can load, > use it. This is in the form of a EFI device path (binary). If it is a File > path that’s ZFS:yyyy, then boot from the Boot environment for ZFS pool > yyyy. If :yyyy is omitted, use the first ZFS pool you find. > 3. > > If a ZFS pool exists with a bootable environment, boot it. > 4. > > If a partition with a known filesystem exists on the same device as > boot1.efi was loaded from, and it contains /boot/loader.efi, use it. > 5. > > Set FreeBSD:BootFailedXXXX to the reason for the failure and return > Failure to UEFI (so UEFI goes to the next item in the list) > > > If FreeBSD:BootArgumentsXXXX exists, parse it like ASCII text and pass it > to the boot loader found in steps 1-4 above. Otherwise pass nothing. > > If the FreeBSD:Update variable is set, the rc system will update the boot > order so that UEFI:BootCurrent is at the start of UEFI:BootOrder. This is > currently done in /etc/rc.d/gptupdate. I propose a /etc/rc.d/efiupdate to > do this, and to report all the BootFailedXXXX variables ala gptupdate. > > Discussion of points raised on IRC: > > FreeBSD currently implements a ‘boot once’ option that’s similar to > ‘BootNext’ but happens only once. In UEFI, BootNext almost implements this. > The BIOS loads that option, then deletes the BootNext env variable. Unless > the OS does something the make it permanent, this is the same as FreeBSD’s > boot once (because the order then reverts to BootOrder). I think that > BootFailed needs to be implemented with the extra protocol outlined in step > 5. There is also a "bootme" GPT flag that is currently ignored when booting using boot1.efi. We use it to avoid in-place upgrades: there are two root filesystems, only one of which is mounted during boot. Upgrades are done by installing the to-version of the OS to the inactive root filesystem, flipping the "bootme" flag off on the active partition, flipping it on on the inactive partition, and rebooting. How should this interact with step 4 of your algorithm? Should we prefer a GPT "bootme" entry over a filesystem on the same device as boot1.efi? > > Open Issues: > > Allan Jude has raised some issues about ZFS. ZFS has it’s own way to deal > with all this and he’s curious how this fits into that. EFI doesn’t know > about ZFS, so at most we can only define what happens when boot1.efi takes > over. In that case, I proposed to him that we do what we do now, and > selection of what ZFS thing can be done either as I proposed, or via the > zfsbootcfg process if nothing further than ZFS is specified (or > automatically selected). > > How does loader.efi fit for people that load it directly? > > Do we want to enable / disable the automatic looking for boot locations > separately from what to boot being explicitly specified or not? I’m leaning > against. > > Can nextboot -k foo be implemented with this? My first notion is that it > would FreeBSD:KernelXXXX to specify the kernel and FreeBSD:NextKernelXXXX > which would load that kernel and then unset FreeBSD:NextKernelXXXX. Ditto > for FreeBSD:KernelFlagsXXXX and FreeBSD:NextKernelFlagsXXXX. nextboot(8) > would set all these. Maybe FreeBSD:LoaderXXXX and FreeBSD:NextLoaderXXXX > too... > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"