From owner-freebsd-arch@freebsd.org Sun Aug 6 22:33:53 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 00970DCE5FB for ; Sun, 6 Aug 2017 22:33:53 +0000 (UTC) (envelope-from specials@furthermore.co.za) Received: from furthermoreincconsultancy.co.za (static-ip-188-138-82-240.inaddr.ip-pool.com [188.138.82.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9E99471402 for ; Sun, 6 Aug 2017 22:33:52 +0000 (UTC) (envelope-from specials@furthermore.co.za) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mail; d=furthermoreincconsultancy.co.za; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; i=postmaster@furthermoreincconsultancy.co.za; bh=6UoWvTgtjMc9qsLxqLh5N7NSw7I=; b=Oj0guG7hMo0Z5h7jv9XW1Fz0EZT8NSm7oUq2hI2EkdmNQ4cp6ehG1PqK0ruIJW4IXUzhdiigLml7 wj4ePHtYJvDqeTSTe5rx8z5R30GpDd7br7UzIj3wTg7fQxblrld1EOYLx98l0+E0p3qp8hA5YfGD BDKA8badZsswcJDN+Yg= Received: from specials@furthermore.co.za (41.164.39.47) by furthermoreincconsultancy.co.za id hgucl00001gn for ; Mon, 7 Aug 2017 00:33:51 +0200 (envelope-from ) Date: Mon, 07 Aug 2017 00:33:51 +0200 Message-ID: <20178703351490AMUNIQUEID@USER-PC> From: i5 Desktop Special To: freebsd-arch@freebsd.org Subject: i5 Desktop Special - EXTENDED TILL TUES 8 AUG - R3999 X-Mailer: AutoMSW (www.automsw.com) ID: 1386816 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Sun, 06 Aug 2017 22:33:53 -0000 i5 Desktop PC - only R3999 = EXTENDED TILL TUESDAY 8 AUG 2017 5 Desktop PC 350GB Hard Drive 4GB Memory = 3.1GHZ Intel=AE Core=99 i5-650 Processor 8 x USB Slots DVD Reader/Writer Installed with Windows 7 System FREE APPS (VLC / Adobe Reader / Open Office) FREE Keyboard and Mouse This desktop is designed for powerful use, and is suitable for many purpos= es such as GAMING, OFFICE PC, DESIGNING WORK, ETC. = It is powerful enough to handle a lot of work load, and will NOT let you d= own, regardless of your requirements. The small design lets you use it in very tight spaces, such as a bedroom, = office cubicles, limited desk space. It is a robust desktop, so it can be used=A0 without fear of damage to the= casing, or internal components. It come fully installed with Windows 7, and Open Office, so you can start = using it IMMEDIATELY REASONS TO OWN THIS PC Incredible Performance Boosts productivity Green Features =96 Uses very little resources to run = Ergonomic Design Industrial quality design and materials Suitable for everyone FREE EXTRAS USB Keyboard USB Mouse Programmes Pre-Installed Windows 7 64bit Open Office Adobe Reader VLC Media Player =A0Email us today on desktop@products-sales.co.za for more information or = to purchase or call 021 903 0501 / 021 903 0118 =A0Renewed/refurbished to brand new. No Monitor included =A0Delivery to your door via courier or collection can be arranged (R99) =A0 =A0OFFER VALID TILL TUESDAY 8 AUG 2017 ONLY!! =A0_______________________________________________________ Why am I receiving this message? 1. You subscribed on one of our many related websites 2. A friend has forwarded you this message 3. You have had previous communications with one of our linked websites. = Eg. You have requested quotes/bookings/info regarding related products fro= m us How do I Unsubscribe? Reply to this e-mail with the word "Unsubscribe" =A0 Notes: Pictures are a representation of the item, but might differ with certain a= spects All prices are subject to change without notice Stock levels are not guaranteed and items might be place on back-order Courier charges are estimates, all courier charges will be quoted per orde= r. By accepting this email without unsubscribing, possible further marketing = emails will be sent to you. From owner-freebsd-arch@freebsd.org Fri Aug 11 04:03:59 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 DEF50D92F79 for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.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 BAC0E835BC for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B70F7D92F78; Fri, 11 Aug 2017 04:03:59 +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 B69E0D92F76 for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 8452E835BB for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id c74so16247455iod.4 for ; Thu, 10 Aug 2017 21:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=zss1P+GlI+n73pzz+f86ARPyxlA+CvAchkQeyiqR27s=; b=HCIAtalov04HurTeOdlBOeDX3ELQNfMOtKtXRcleU6H8CIl9wKUHMdD+Y4sGzycASI fioSi/onSB0iEikgVUinl+K1lvWbL5FgkfevDO/kN4FIGahmd3Bl2ucSDe61WmLt3EOk Kar0ly15sdHQ5ZFhlNIA+HimMC1qDR6OyBXO3TQumv+ykOJVlV2DQBvjjVNjQHbEcLUN +PtA5DmO4XoxkRvgu+bKuXsEx2IqdbiAM2gGMNmhhxL0UiVHLk13uDGPReM8SuZKB0DZ /UDRveJ37BH/Vl1LPNZgEFTHMwSLZI1Xf9MKDmu/RFfFaW4idhgUp9X3pOqEfsjjiK6Q G2LQ== 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:from:date:message-id:subject :to; bh=zss1P+GlI+n73pzz+f86ARPyxlA+CvAchkQeyiqR27s=; b=Kd9qwK9JqClsnog+EoBW7c24RtSruhPQz+GULCSjVyQkJNftWSKE8buXeOdApIIJj3 lbezXt1l/4meh9humb91IyIYNwPBQdwBfmPKqrf40pvYFnd3XkkkhOn6805a2KyhAkx6 Iv0EKWCz3kfFutxlpy8Zg6ssVWVCl6s84fPuDym4iw/T1DNpQuuUUeqfKka5HZVUG0rj uCSVZdGB9YlVC6NoeZYotnYTJhLSDFlzaMLeiR1GAYOm8EtAgkpzyaOGSP1oKGjKbsoB VDZNcurh3NmE+qky+Jp1KK48ScVcQ0qbc1+c2poYp0QMlCAn6JM/RjiBKo56KEI49F1Z I38Q== X-Gm-Message-State: AHYfb5gM8mPtwGSuJu4FqgWPuRbYI75LSI9ESzm/0WVjFSe9iYcLDyep o8t6kSU8HYpPUTWtXNFl2nyxq3Q4IoMSWbQ= X-Received: by 10.107.136.104 with SMTP id k101mr11649415iod.62.1502424238521; Thu, 10 Aug 2017 21:03:58 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Thu, 10 Aug 2017 21:03:57 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:fc73:9056:67a0:a7d0] From: Warner Losh Date: Thu, 10 Aug 2017 22:03:57 -0600 X-Google-Sender-Auth: Ax1LfHdybnDowHSRCuXqvaFEAf4 Message-ID: Subject: Proposed Enhancements to the EFI booting To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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 04:04:00 -0000 Greetings, I've been circulating a document (the latest version you can find here https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT= 90Jg/edit?usp=3Dsharing ) 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=E2=80=99t 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=E2=80=99s some problems with this algorithm. It=E2=80=99s not possibl= e to specify a partition to boot from. We boot from the first /boot/loader.efi that=E2=80= =99s found, even if multiple partitions on a drive have one. Second, it=E2=80=99= 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=E2=80=99t use the ad-hoc method for identifying which F= reeBSD partition to boot off of that we use for BIOS boots since in the UEFI runtime environment it=E2=80=99s tricky to get the attribute flags of a par= tition. Finally, it doesn=E2=80=99t 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 loa= der to use. If we can use that boot loader, we=E2=80=99re done. Otherwise, i= gnore 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 Fi= le path that=E2=80=99s ZFS:yyyy, then boot from the Boot environment for ZF= S 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 =E2=80=98boot once=E2=80=99 option that=E2= =80=99s similar to =E2=80=98BootNext=E2=80=99 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=E2= =80=99s 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. Open Issues: Allan Jude has raised some issues about ZFS. ZFS has it=E2=80=99s own way t= o deal with all this and he=E2=80=99s curious how this fits into that. EFI doesn= =E2=80=99t 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=E2=80=99m= 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... 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" From owner-freebsd-arch@freebsd.org Fri Aug 11 19:48:04 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 9E433DB76B7 for ; Fri, 11 Aug 2017 19:48:04 +0000 (UTC) (envelope-from wlosh@bsdimp.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 778BE17C2 for ; Fri, 11 Aug 2017 19:48:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 738FBDB76B6; Fri, 11 Aug 2017 19:48:04 +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 7303EDB76B5 for ; Fri, 11 Aug 2017 19:48:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 3787E17C0 for ; Fri, 11 Aug 2017 19:48:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id o9so23784931iod.1 for ; Fri, 11 Aug 2017 12:48:04 -0700 (PDT) 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=Gq0yrM43S/SXkLePrR0sYC2QLLC1Ij224A3BwO5R+DI=; b=FY7M8Jmhqw8OvrmOhChHgtDa80TWMqIqs1rRhPqFd4e4WWtMHuEzxREVXGRwNKeTvw MHQN2MLcVheWOgJWF1E0ZHWPkejUpPrCyWNefn0AUVWajauJkClSz2E/AlaJ19VjBV3m 4tTx529MG2g7sDSVUhz+A7FzWCHylVNJp+6wr1qK5E+Cp4fcW99I8L9uDen4+P84vJrv 2Og0zGYXU8dSANdsvMjL6G6jJzioaX92H37aP1DUshWhcI1oGiccNuD0br8yD/k/XbnI doUftEtqiGoeSOqJ6Y9FM8Eng1CIVVDbRxC+oJbJohU+aHTWzNFJy4i+DWYmh/QWwd/V C3rQ== 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=Gq0yrM43S/SXkLePrR0sYC2QLLC1Ij224A3BwO5R+DI=; b=G06FvIYfjk2NIp8J3jxDERj7R6xF9ScUcJYqyYI+pkMhNzr2m7t7Q/gaa5Imq5eEDv RbgAx05OOG6vzu14h9YL1Sp2v02CKG8pM2/5vzQ5X0w++o/Z24RBFajVtzEpjj+1K6tZ JCSbAORfeZbgSZCkHDRDaWtRcFC+imhncPtqPsc9PdKSgxJCkj7092XXxngp/4u060jj OBDgaRt5DjTqcocps2ZaRvZmwhVH5YkLaoivo+dHJQpcELCdyoDbUexvCl1wo15NEJXU oY2pUhlZGpM+Am3nSAyiB4oJ89IAXQLA8cRQOurYSBZm272ccNQnq7ASorwbEqw9RoVr egWw== X-Gm-Message-State: AIVw113IftWcBdrJmEe1/sFd/a/ZAskeTKaU6Uds3XVC6d9LiLSvxOko ZE+NtrbfGQijg7vRJ76Df0hklMsyAUg9 X-Received: by 10.107.147.133 with SMTP id v127mr12884774iod.128.1502480883199; Fri, 11 Aug 2017 12:48:03 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 11 Aug 2017 12:48:02 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:fc73:9056:67a0:a7d0] In-Reply-To: <20170811194028.GB19972@wkstn-mjohnston.west.isilon.com> References: <20170811194028.GB19972@wkstn-mjohnston.west.isilon.com> From: Warner Losh Date: Fri, 11 Aug 2017 13:48:02 -0600 X-Google-Sender-Auth: ZqB2uUPTDIjMib9XL3x-dSFcKdQ Message-ID: Subject: Re: Proposed Enhancements to the EFI booting To: Mark Johnston Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.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:48:04 -0000 On Fri, Aug 11, 2017 at 1:40 PM, Mark Johnston wrote: > 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=3Dsharing > > ) > > > > 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=E2=80=99t 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 formatte= d > > and has a /boot/loader.efi we can load. > > > > There=E2=80=99s some problems with this algorithm. It=E2=80=99s not pos= sible to specify a > > partition to boot from. We boot from the first /boot/loader.efi that=E2= =80=99s > > found, even if multiple partitions on a drive have one. Second, it=E2= =80=99s 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=E2=80=99t use the ad-hoc method for identifying whi= ch FreeBSD > > partition to boot off of that we use for BIOS boots since in the UEFI > > runtime environment it=E2=80=99s tricky to get the attribute flags of a > partition. > > Finally, it doesn=E2=80=99t 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=E2=80=99re done. Otherwis= e, 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=E2=80=99s ZFS:yyyy, then boot from the Boot environment fo= r 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 bo= ot > > 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 =E2=80=98boot once=E2=80=99 option that= =E2=80=99s similar to > > =E2=80=98BootNext=E2=80=99 but happens only once. In UEFI, BootNext alm= ost 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=E2=80=99s > > 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. > Correct. EFI Boot Manager has a concept of profiles being active or not active. That's how this functionality will be implemented. There's no standardized notion of a partition being bootable or not. That's a FreeBSD extension. same with bootnext and bootfail flags. So upgrades would become flipping the boot order in UEFI:BootOrder and/or toggling active on the two UEFI:BootXXXX variables. It just changes the command you need to issue from gpart to efibootmgr . > 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? No. We shouldn't. That duplicates functionality, and the flags bits we need to make these decisions are a pain to get to in boot1.efi. They are FreeBSD specific, but won't be carried forward since better functionality already exists in the BootOrder and BootXXX variables. This is much more flexible as well, since it allows you to have multiple profiles that point to the same partition, but have different parameters, only one of which is active at any time, which is impossible with the old GPT scheme. Warner > > > Open Issues: > > > > Allan Jude has raised some issues about ZFS. ZFS has it=E2=80=99s own w= ay to deal > > with all this and he=E2=80=99s curious how this fits into that. EFI doe= sn=E2=80=99t 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 th= e > > 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=E2=80= =99m > leaning > > against. > > > > Can nextboot -k foo be implemented with this? My first notion is that i= t > > would FreeBSD:KernelXXXX to specify the kernel and FreeBSD:NextKernelXX= XX > > which would load that kernel and then unset FreeBSD:NextKernelXXXX. Dit= to > > for FreeBSD:KernelFlagsXXXX and FreeBSD:NextKernelFlagsXXXX. nextboot(8= ) > > would set all these. Maybe FreeBSD:LoaderXXXX and FreeBSD:NextLoaderXXX= X > > 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" > From owner-freebsd-arch@freebsd.org Fri Aug 11 19:59:50 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 9172ADC21FB for ; Fri, 11 Aug 2017 19:59:50 +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 6A4871F8A for ; Fri, 11 Aug 2017 19:59:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 66116DC21FA; Fri, 11 Aug 2017 19:59:50 +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 65A0BDC21F9 for ; Fri, 11 Aug 2017 19:59:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 26BBD1F89 for ; Fri, 11 Aug 2017 19:59:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x22f.google.com with SMTP id u139so26054532qka.1 for ; Fri, 11 Aug 2017 12:59:50 -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:in-reply-to:user-agent; bh=q75gB/2eFgrWlTpHAsIM9A+4y6hjv2eFeR8KQTIFF2w=; b=jxkMjEKmkhITmigItVYM6qrpVGwISNR/3etkGhb4ri9rnJrw4eLb29MmtUFt9NTNVL r6ppzmv77H5419qsyQpDhcDJDkDRt4TogLSmzM8Of/qJ0atXBsZtAT26kHjl+Sobq5of k1WFfJwze3s2vjl6X3V2dZOIipZ+Gpx/6Q/+9XrTEdKcL7dI/DTRi49SRjgyr1Wt/a2W x8v9nGm+mmRJZfgM2bbIVjGFGjbkh1rzMAaJ2rDLXtq6A78E10njeK4X4Q22hfAfz7Ub 0Pyozi2qXeXRgsp8STkuhyOavfuHQsQa3Op1/HnJj6kHPGLwrciO9ezHVtm51kz8wnGG MuWw== 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:in-reply-to:user-agent; bh=q75gB/2eFgrWlTpHAsIM9A+4y6hjv2eFeR8KQTIFF2w=; b=ZWVjy0NvMB+vSVXU7/qQgUA7NbB4HWgv2VrfW9KmJnLkWhizsmJ6bJL+xMowCYtnhY CAN2vTBrr/Q6evvLZ+TSj1gB9fiieG/t9TWG6OZxe80VWdsOIXHvuPVfdgm45EKoTavW ih7WKam0gCAI82uhbecQk2ubVrfEX3SEcp1HAEE8hh4NrsbqYxQ6Gd0WanwgX1o8TwtM Agb/hwzTdUq7dY8ywN3GvTFTjBBS9Ux7GllS9wSaJfuGDW3H5bmenA7/nX2bzWCHcj9N srvBDHn4XuL+Ym8JfsxsHTEt2F+5zNcr8h4iblFjKju8zRecNgzmUXEhrBn+H+aqby8D IMrw== X-Gm-Message-State: AHYfb5i4aNSXohzGzh/3RRzaVlyT2lXMTGCU7D6P6MW1CyLQEdLEpBmJ pa1DhXZJDQR8kQ== X-Received: by 10.55.122.68 with SMTP id v65mr20350072qkc.225.1502481589182; Fri, 11 Aug 2017 12:59:49 -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 10sm1140520qtq.42.2017.08.11.12.59.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 12:59:48 -0700 (PDT) Sender: Mark Johnston Date: Fri, 11 Aug 2017 13:00:31 -0700 From: Mark Johnston To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Proposed Enhancements to the EFI booting Message-ID: <20170811200031.GD19972@wkstn-mjohnston.west.isilon.com> References: <20170811194028.GB19972@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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:59:50 -0000 On Fri, Aug 11, 2017 at 01:48:02PM -0600, Warner Losh wrote: > > 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. > > > > Correct. EFI Boot Manager has a concept of profiles being active or not > active. That's how this functionality will be implemented. There's no > standardized notion of a partition being bootable or not. That's a FreeBSD > extension. same with bootnext and bootfail flags. > > So upgrades would become flipping the boot order in UEFI:BootOrder and/or > toggling active on the two UEFI:BootXXXX variables. It just changes the > command you need to issue from gpart to efibootmgr . > > > > 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? > > > No. We shouldn't. That duplicates functionality, and the flags bits we need > to make these decisions are a pain to get to in boot1.efi. They are FreeBSD > specific, but won't be carried forward since better functionality already > exists in the BootOrder and BootXXX variables. > > This is much more flexible as well, since it allows you to have multiple > profiles that point to the same partition, but have different parameters, > only one of which is active at any time, which is impossible with the old > GPT scheme. Ok, that's fine with me. I just wanted to point out that that functionality is both useful and currently missing, so I'm glad that there will be a replacement with a simple interface. From owner-freebsd-arch@freebsd.org Sat Aug 12 23:04:14 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 7C0DADCF77C; Sat, 12 Aug 2017 23:04:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 4D8F7754EA; Sat, 12 Aug 2017 23:04:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x236.google.com with SMTP id v77so28050167pgb.3; Sat, 12 Aug 2017 16:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=znrYEwvgTOWFns9qDd/FlEN6wOeuzZwlcN6toe0t1TI=; b=O0uBSADRDmy2bYjbiYtRt27e77qTIlkk7a6WKnLwE9IIR0sdfT0g0PFnK6NXQZC8AV pu20jJEsgkwVq/c/cSj5hScpIgrFWzX8w/ttu1jqkHP171E+A+hQ/lsUsRGIYRsdh6UY hng/gez0kexiVaT26C6pprq4iqypnrtbgeB1IJHn8tP+HirkAKm6efXiHINrk9/8DcE9 S9KKVYZBZoflTJxdfqJ+/D7T7+DqPT6KdKGBWkIEStdz/T+0xjLt1bw1e7coBQWrfpoG 1zpVo5lHiGDAEIV0E07AGTbUW2EVbQA3rPD3R4VNFuRthlrtWc79ehEhRhdD7BSelb7w YXVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=znrYEwvgTOWFns9qDd/FlEN6wOeuzZwlcN6toe0t1TI=; b=AE4WPkOBploG4ojhNsZ+bv9fL9ORsMjlU1hKfTZ/3uW/ieYvhngxGNAUO5F3hhhElW Ck7tUkzD7zqy+iU9WAoWt+AGXAo6TAOonsrv46PA7GxQse47XFRXJJNTls5rvSiDZIv3 KkyikLeC5JFqX0I/6BZT9ykN5QE3ExzU/pl7c3iS1RSq6qJsC114l8JH9yBC1ioXjXj9 LI24i93jHQtOuCsgnfHqRWij/ESeRzUritrPoxs3+TnA9aZeS7B/tplbSObE242nOuiI zsz4ExggzDbtlmv+LChsHGxHfNtQ7ToifXPJjFcPpStnsy/4mK7opIZyak33RDzLmwsY XZAA== X-Gm-Message-State: AHYfb5gmribseXDTd3CI62TQ5w6Kk/CjkB3iNDqcrexkkAWfNbuUPL6U Xr2NFM+bWFwRhNcBvQw= X-Received: by 10.98.111.2 with SMTP id k2mr20458913pfc.78.1502579053038; Sat, 12 Aug 2017 16:04:13 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id n66sm8172987pfk.38.2017.08.12.16.04.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Aug 2017 16:04:12 -0700 (PDT) From: "Ngie Cooper (yaneurabeya)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_ECC24559-C2D8-49E0-9D2A-465882906A34"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: [RFC] Add limited sandbox capability to "make check" Date: Sat, 12 Aug 2017 16:04:11 -0700 Message-Id: <3E64B992-F7C4-45AC-8C38-3E84EA6DA5CB@gmail.com> Cc: FreeBSD-arch list To: "freebsd-testing@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: Sat, 12 Aug 2017 23:04:14 -0000 --Apple-Mail=_ECC24559-C2D8-49E0-9D2A-465882906A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am proposing a change to =E2=80=9Cmake check=E2=80=9D in the = source tree that mirrors what other open source projects do when = executing =E2=80=9Cmake check=E2=80=9D in terms of not requiring the = libraries/programs and tests to be installed to the system when running = =E2=80=9Cmake check=E2=80=9D. I have opened up the following CRs on = Phabricator for the change: - https://reviews.freebsd.org/D11905 - Add limited sandbox = capability to "make check" - https://reviews.freebsd.org/D12014 - Supporting changes for = `Add limited sandbox capability to "make check=E2=80=9D` The first CR has been open for approximately a week and needs to = be reviewed. The second CR is the mechanical changes that would be = required in order for the changes in D11905 to take effect. I would really like some help reviewing the change because I am = proposing something (infrastructure-wise) that is meant to improve = others being able to execute tests, as the amount of testing done via = the FreeBSD Test Suite [as a whole] is smaller than I would like. This change is not meant to supplant executing the entire suite, = as need be, or other CI solutions =E2=80=94 it=E2=80=99s meant to be a = sane developer shortcut which would improve dev->test->commit velocity = and [hopefully] reduce the number of commits without proper testing done = beforehand. Thank you, -Ngie --Apple-Mail=_ECC24559-C2D8-49E0-9D2A-465882906A34 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZj4lrAAoJEPWDqSZpMIYVzboP/1pl/5Dl8f0rktN1+4RGyg+W VjajJCWhPMP2xfHefG0L89+SsmoFLrbFkkpusnQALMb/uGgtDluymt3MCVWNbu7G 9CuVaRQyGQwbRV5Ry/CKSogo6ySVgEiHuC+XZ5vSaI+oAxXRVkAK3S2oxZHjcg0S TD3TKwSUAt2zG77qli+P8BAOsDgSa9S6IeAcqNMf/e83D20qK65QRAxb006l8Bf4 7/d11tKnYeESMTAJ6cuZsKlpOnu0l+I9PxdCtRCtjtA7y/Q15qrHg/NXO+eEm5Yo HqPSvKXOHLdJlt1AFH5nuHH3429qdf0iNzDVaT2Iu6AodxEMkc3455QCcl78FK0i GQIxN1c7Dd5Oc0HQshx9D2iMo7rurmin4gQ3hHPy/V5Y17gyP4/Ygl28ebpwPfCB +5tyj4rTeYaBtOtPwAQsp3vjBiHKvHpOf4D9dimJhP/+5yml/wr8M3G6Hzh/P7TX doxJHWnIfJpj88AglTq8HHxjlEQRYm1hL9xuGoOdQttQhqnXfO+KxnqBXdioouuU ag5CRz3fDAOsR/Rt/F2OYG/vb9PS9NrvDyHU79zFx5yUQYvFmrqmW5W2bJFRdw7y M78LRPxRk8wDm3P8KDQtKTILYkEtjNRJcxY7XNXl8Jwkmm+mp7CCZ+vBhGS6MBlp glekw4LJ1IXGdDv1rA+n =8+zQ -----END PGP SIGNATURE----- --Apple-Mail=_ECC24559-C2D8-49E0-9D2A-465882906A34--