From owner-freebsd-hackers@freebsd.org Fri Jun 7 02:30:19 2019 Return-Path: Delivered-To: freebsd-hackers@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 75EA615C5FBB for ; Fri, 7 Jun 2019 02:30:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEFEC9076F for ; Fri, 7 Jun 2019 02:30:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id i34so626829qta.6 for ; Thu, 06 Jun 2019 19:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uLdyiyBlYBekeZawK7rAP3/1Yv1JwHad/ntyCSbP5uI=; b=OiRTY0Pb2PDZ6/9Wjxs7zjfI6CCMWq/OhhGhbC8CpsjSbN538KEwGjYYQTBK6u5q82 w9xyFzy0UT+WCF4t6pmky1u9aOKlI2A4cfnu0by6CwW+RBIseL070xWiW+zVm3nXD3Ln BJvR1eCdgoxFPprM7I71PxAxSp0R0u2iNq8hA3sh+U3iMg7loiXeqC2q4zO0TrK6GPdf HUbNFqy8sbs7Qtzz24yvFrPeibWgKJJ9HlwZY2yIV0OCqAxBAmumByxHILCJAFPK5a3L ZuTwaFpGUgV7AHe0G0/AgDMOBLLaToeT8aUl16PU765R1u9beaWxpRuLh8N05w1LwmJs ffiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uLdyiyBlYBekeZawK7rAP3/1Yv1JwHad/ntyCSbP5uI=; b=hPLQSBEfqaIvxG84eKbnnz0uIULwluGi60Rc3qHOilEl2UZYdf6N6SGmkbVWpk6PHG NKnqPO7cCntyViPhEpJ/PbWTGz21abqqw2i69XAO1SEIts0coDvayKkA3UJxRifBNgNu EWRCwzJhDl8joSldWA1UqWONcPqbffMLVj0ZvPnBrRKA3JTYK94FOgsjvTAzB+Bh+ZiL kvz1Vp45k3gq77uhpgPmH4OY3FoZgXFItiu2FdBr7ZY6YXZwdEWopLikHK7IAdh19d8j 48unSI8l9HQrFaEF38ZLrtwqscs3Ld+O8FHDlvF8C1Zhvi5G4nmkEWHXI5d+e/11WtJA A6pg== X-Gm-Message-State: APjAAAUBhyFBiIimWCh9qMsC4mwWcNl9hfG9RaXrCIPfsMxa0CUDMsJv eMER7tRQ4TX9YlZWil560AdCWmIwIfc6wgVxXznsVyV2yutoLQ== X-Google-Smtp-Source: APXvYqwY3AGyFq+SOp5ng82q1cnGtdmsXGQ0wW6QxABTSffMtS59pVXY6eg13uaPXzTJminRGdazaaMfkZaFt5GbWaM= X-Received: by 2002:a0c:b66f:: with SMTP id q47mr41933771qvf.102.1559874616955; Thu, 06 Jun 2019 19:30:16 -0700 (PDT) MIME-Version: 1.0 References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> In-Reply-To: From: Warner Losh Date: Thu, 6 Jun 2019 20:30:06 -0600 Message-ID: Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags To: Jan Martin Mikkelsen Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: DEFEC9076F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=OiRTY0Pb X-Spamd-Result: default: False [-5.96 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.99)[ip: (-9.39), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.30), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 02:30:19 -0000 On Tue, Jun 4, 2019 at 3:03 PM Warner Losh wrote: > > > On Tue, Jun 4, 2019 at 9:40 AM Jan Martin Mikkelsen < > janm@transactionware.com> wrote: > >> >> On 4 Jun 2019, at 16:10, Warner Losh wrote: >> >> >> On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen < >> janm@transactionware.com> wrote: >> >>> Hi, >>> >>> The UEFI boot1 loader does not support the GPT >>> bootme/bootonce/bootfailed flags for selecting which partition to boot. >>> >>> Is there a reason for this? >>> >> >> Yes. There's three. >> >> First, UEFI provides no way to get to these flags via their block >> interfaces. Second, the block interfaces are independent, so there was n= o >> easy way to know w/o jumping through a bunch of hoops. Third, the UEFI >> Boot Manager Protocol was championed as being the one-true way to select= a >> boot partition. It's significantly more flexible and reliable than >> rewriting the partition table from time to time. >> >> However, there's significant drawbacks to the UEFI scheme. Vendors suck >> at not mucking up the UEFI Boot Manager Protocol (I'm looking at you >> SuperMicro). And the trend in embedded where UEFI has a foothold has bee= n >> to move away from writable variables at all... Finally, the UEFI Boot >> Protocol assumes a host + media. There's no media-agnostic way to produc= e >> an image with multiple partitions that you ping-pong between (say a >> recovery USB stick that moves from system to system). >> >> So against my better judgement, I've been working on making gptboot.efi. >> It's not as terrible as I thought it would be, but it shows another issu= e: >> loader.efi and boot1.efi process all the partitions they find, but gptbo= ot >> just does one disk's worth and stops when it successfully boots somethin= g: >> this has required a restructuring of the boot1 code that I started with = to >> rearrange the loops used to find things. An no, the gptboot.efi will not >> support ZFS, which has its own way to do this outside of UEFI Boot Manag= er >> Protocol. >> >> If you don't want to wait, there's now a mechanism for loading loader >> environment variables from a file called \efi\freebsd\loader.env in the = ESP >> that can accomplish much the same thing. >> >> >> OK. >> >> I am looking at similar situations: Supermicro servers and various >> flavours of embedded systems. For some of the newer embedded systems UEF= I >> is the necessary approach. I am not at all interested in writable variab= les >> in firmware. I=E2=80=99m also not interested in booting from ZFS. >> >> My question was because I have been reading the efi/boot1 source code an= d >> deciding what to do to duplicate the bootme/bootonce functionality. That >> there were lots of hoops to jump through was clear. However, I was comin= g >> to the conclusion that boot1.efi needed to duplicate the functionality o= f >> gptboot, and was getting ready to implement. >> >> How far have you gone with your gptboot.efi? What=E2=80=99s missing >> > > I have it mostly written at this point. Nailing down going back and forth > between handles and different partition numbers. > Update to the latest and apply https://reviews.freebsd.org/D20547 and this will create a gptboot.efi you can test. It works for me for the first few cases I've tested. Warner