From owner-freebsd-arch@freebsd.org Sun Mar 24 09:01:19 2019 Return-Path: Delivered-To: freebsd-arch@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 61BC6155161F for ; Sun, 24 Mar 2019 09:01:19 +0000 (UTC) (envelope-from kostikbel@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 BC4B0730F7 for ; Sun, 24 Mar 2019 09:01:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 72104155161A; Sun, 24 Mar 2019 09:01:18 +0000 (UTC) Delivered-To: arch@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 5A8561551619; Sun, 24 Mar 2019 09:01:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FF55730DE; Sun, 24 Mar 2019 09:01:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2O914lC009017 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Mar 2019 11:01:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2O914lC009017 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2O913nC009016; Sun, 24 Mar 2019 11:01:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Mar 2019 11:01:03 +0200 From: Konstantin Belousov To: Rebecca Cran Cc: FreeBSD Hackers , arch@freebsd.org Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <20190324090103.GO1923@kib.kiev.ua> References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 09:01:19 -0000 On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via freebsd-hackers wrote: > I've been working on EFI support, and have a review > (https://reviews.freebsd.org/D19588) to add a script, efi-update-loader, > which will update the ESP containing the FreeBSD boot1.efi or loader.efi. > > I'd like to integrate it into the build system so it gets run when users > do a "make installworld", but I'm lost looking through Makefile.inc1 - I > have no clue where to add the code. > > Does anyone understand where and what to add? Can we take use of the opportunity and finally stop installing loader at installworld target at all, please ? Add e.g. installloader target which would do whatever needed to loader. From owner-freebsd-arch@freebsd.org Sun Mar 24 23:47:34 2019 Return-Path: Delivered-To: freebsd-arch@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 3CF9A15489C4 for ; Sun, 24 Mar 2019 23:47:34 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 A11B16D81A for ; Sun, 24 Mar 2019 23:47:33 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5F38A15489C2; Sun, 24 Mar 2019 23:47:33 +0000 (UTC) Delivered-To: arch@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 4D30F15489C1; Sun, 24 Mar 2019 23:47:33 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C90586D819; Sun, 24 Mar 2019 23:47:32 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 8AACFC0A16; Sun, 24 Mar 2019 17:48:28 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0j6xUlv5kZu2; Sun, 24 Mar 2019 17:48:28 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 17:48:28 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Konstantin Belousov Cc: FreeBSD Hackers , arch@freebsd.org References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> From: Rebecca Cran Message-ID: Date: Sun, 24 Mar 2019 17:47:23 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190324090103.GO1923@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: C90586D819 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 23:47:34 -0000 On 3/24/19 3:01 AM, Konstantin Belousov wrote: > > Can we take use of the opportunity and finally stop installing loader > at installworld target at all, please ? > > Add e.g. installloader target which would do whatever needed to loader. Others have suggested adding a new step as well. I'm not sure we need it as a make target, but perhaps a generic script such as "update-loader" that will call "efi-update-loader" if on a UEFI system, or "boot0cfg" etc. on an MBR system (i.e. it knows how to install boot/loader code for all systems we support)? Also, about the naming: would you prefer 'install' or 'update' in the script name? When you say "stop installing loader", do you mean stop installing /boot/loader* entirely, or leave installworld installing those, but have updating the ESP as the extra step? -- Rebecca Cran From owner-freebsd-arch@freebsd.org Sun Mar 24 23:57:25 2019 Return-Path: Delivered-To: freebsd-arch@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 2E5C015491BD for ; Sun, 24 Mar 2019 23:57:25 +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 86E8D6DEB3 for ; Sun, 24 Mar 2019 23:57:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4A3E115491B9; Sun, 24 Mar 2019 23:57:24 +0000 (UTC) Delivered-To: arch@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 27DC415491B8 for ; Sun, 24 Mar 2019 23:57:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C095C6DEB2 for ; Sun, 24 Mar 2019 23:57:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id k189so4336362qkc.0 for ; Sun, 24 Mar 2019 16:57:23 -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=yCZJXOframkGITwVFoML9O1rte5dwvfAWAqdYiHRIPY=; b=gpSpe9g3H84yESz2SDYTK77j4L3nPJTSzhIJam27GDTpYaFU7CuUXoG7JFdM1+Q69K 6yHCwWQv50jOYUhjnoM2NWyS4xGrIcsH2wdHgF9Nwr4X43w/SQYvQ5akfsWdkccNHRdf PA7ZJuWBgvEIh/+usysyeuCJGAhf5DmvqAkzNEPzHf6FJIuvvSiTewMjaukZ5KFbIiBg rKKNf29p3nDmMO2CcoMo850xu9qY5/u5ZeQhvKNuYbEI63pZLMNAOxVlqlfinjtfLS4o DSaY2/hGmKIYVLlImEhMVU0UjFC2/jVEe7m3y4cBE2viQNr6EsQK3jQeAcZVt/986dau QUVA== 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=yCZJXOframkGITwVFoML9O1rte5dwvfAWAqdYiHRIPY=; b=iSEmAfMLpl4EvgIzkA9Gwkcn++g8T+NI4de7oG/CNFntIOEzOER39G3nfmmG75cu7X GY6Oy/YrzAXzH8e3CjkSItzjS09227FEntgTgoglfo1v+uLFPgTw60fRkdb8MK0u3J8n aV4BE7n73XZtOSBB5G6MzicVlwMH2x+zBd7PdRMj0s/xNNKTvc2q4mFLiF3EsoKMClIA R95zAxz6Z1GEWucoVq2skxyHODdWR5zlrrgDRuBMRNOKKy4ESHDDDVfftFN/9Ea47Uoe LwqQ2bfjpY98QmrrEEqdPbfxWK6keBK8oKeUPwsPOyxRLSkGAYh/WhivKhR7kLXJWv9T 8GsA== X-Gm-Message-State: APjAAAUsd3OpoQ4YKajwseVadQavsXXtiRq6SAb2Ndmtv9jnbhdsQui6 EdB5/99SchAXKnivFZ/522q0fiOLY5kR6/QT2v5pmZ9b X-Google-Smtp-Source: APXvYqz5al1H4Se+HcOtFX3hmr2ATebrdcdWYonJYHZxq38c+kv0/xs9OD9p9sqdw6Fq2YJh0PcCDJSQk3e2QS4GnFg= X-Received: by 2002:a05:620a:15c4:: with SMTP id o4mr17179803qkm.175.1553471842974; Sun, 24 Mar 2019 16:57:22 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> In-Reply-To: From: Warner Losh Date: Sun, 24 Mar 2019 17:57:12 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: C095C6DEB2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 23:57:25 -0000 On Sun, Mar 24, 2019 at 5:48 PM Rebecca Cran via freebsd-hackers < freebsd-hackers@freebsd.org> wrote: > On 3/24/19 3:01 AM, Konstantin Belousov wrote: > > > > > Can we take use of the opportunity and finally stop installing loader > > at installworld target at all, please ? > > > > Add e.g. installloader target which would do whatever needed to loader. > > > Others have suggested adding a new step as well. I'm not sure we need it > as a make target, but perhaps a generic script such as "update-loader" > that will call "efi-update-loader" if on a UEFI system, or "boot0cfg" > etc. on an MBR system (i.e. it knows how to install boot/loader code for > all systems we support)? Also, about the naming: would you prefer > 'install' or 'update' in the script name? > > > When you say "stop installing loader", do you mean stop installing > /boot/loader* entirely, or leave installworld installing those, but have > updating the ESP as the extra step? > He's asking for stopping doing a make install in src/stand. I'm thinking that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader phase. Again, only if the ESP is mounted, and we have a default spot for it. For this script, I don't think hunting for the ESP is the right way to go... which means we need to define a standard place for the ESP to be mounted, which we should do before we turn on any of these features. We have the start of a generic script to update things in src/tools/boot/install-boot.sh which was supposed to install boot blocks on everything known to run FreeBSD. Warner From owner-freebsd-arch@freebsd.org Mon Mar 25 00:02:57 2019 Return-Path: Delivered-To: freebsd-arch@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 095A515497B0 for ; Mon, 25 Mar 2019 00:02:57 +0000 (UTC) (envelope-from kostikbel@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 7D4E86E43A for ; Mon, 25 Mar 2019 00:02:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3B8C815497AE; Mon, 25 Mar 2019 00:02:56 +0000 (UTC) Delivered-To: arch@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 2983C15497AD; Mon, 25 Mar 2019 00:02:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67D1F6E439; Mon, 25 Mar 2019 00:02:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2P02fTi035581 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Mar 2019 02:02:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2P02fTi035581 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2P02fZT035580; Mon, 25 Mar 2019 02:02:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Mar 2019 02:02:41 +0200 From: Konstantin Belousov To: Rebecca Cran Cc: FreeBSD Hackers , arch@freebsd.org Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <20190325000241.GS1923@kib.kiev.ua> References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:02:57 -0000 On Sun, Mar 24, 2019 at 05:47:23PM -0600, Rebecca Cran wrote: > On 3/24/19 3:01 AM, Konstantin Belousov wrote: > > > > > Can we take use of the opportunity and finally stop installing loader > > at installworld target at all, please ? > > > > Add e.g. installloader target which would do whatever needed to loader. > > > Others have suggested adding a new step as well. I'm not sure we need it > as a make target, but perhaps a generic script such as "update-loader" > that will call "efi-update-loader" if on a UEFI system, or "boot0cfg" > etc. on an MBR system (i.e. it knows how to install boot/loader code for > all systems we support)? Also, about the naming: would you prefer > 'install' or 'update' in the script name? I do not see the need in the script which would call another commands. Having efi_update_loader alone would be fine, but I doubt that this script can do much except in situations where a lot of pre-assumptions are true. I believe that despite all the efforts put into efibootmgr and installer, it is hard/impossible to make the script not dangerous, except if the whole configuration was created by our installer. > > > When you say "stop installing loader", do you mean stop installing > /boot/loader* entirely, or leave installworld installing those, but have > updating the ESP as the extra step? I mean 'do not touch my ESP' on installworld. From owner-freebsd-arch@freebsd.org Mon Mar 25 00:20:21 2019 Return-Path: Delivered-To: freebsd-arch@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 F379C154A03D for ; Mon, 25 Mar 2019 00:20:20 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 674286EBC6 for ; Mon, 25 Mar 2019 00:20:20 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 20743154A03B; Mon, 25 Mar 2019 00:20:20 +0000 (UTC) Delivered-To: arch@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 F1D5D154A039; Mon, 25 Mar 2019 00:20:19 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A7DA6EBC5; Mon, 25 Mar 2019 00:20:19 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 36272C0A4D; Sun, 24 Mar 2019 18:21:22 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uWGl4vsUr5MR; Sun, 24 Mar 2019 18:21:21 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 18:21:21 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> From: Rebecca Cran Message-ID: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> Date: Sun, 24 Mar 2019 18:20:17 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 8A7DA6EBC5 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:20:21 -0000 On 3/24/19 5:57 PM, Warner Losh wrote: > > He's asking for stopping doing a make install in src/stand. I'm > thinking that's a good thing. We should update the ESP's > \efi\freebsd\loader.efi, but leave the\efi\boot\bootXXXX.efi alone as > part of this new installloader phase. Again, only if the ESP is > mounted, and we have a default spot for it. For this script, I don't > think hunting for the ESP is the right way to go... which means we > need to define a standard place for the ESP to be mounted, which we > should do before we turn on any of these features. > > We have the start of a generic script to update things in > src/tools/boot/install-boot.sh which was supposed to install boot > blocks on everything known to run FreeBSD. Only updating \efi\freebsd\loader.efi is the wrong thing to do in my opinion: there are situations like on ARM where EFI variables aren't persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case we know any changes to BootXXXX variables won't survive a reboot, and we need BOOTxxxx.efi. Is it safe to assume there's only a single ESP in the system? Is it not normal for there to be one ESP per disk for mirrored configurations, in which case each would need to be updated? Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or remaining where it is? We'd also need to update the ESP for binary installs using freebsd-update. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Mon Mar 25 00:32:17 2019 Return-Path: Delivered-To: freebsd-arch@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 F230F154A6C1 for ; Mon, 25 Mar 2019 00:32:16 +0000 (UTC) (envelope-from yaneurabeya@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 D82556F255 for ; Mon, 25 Mar 2019 00:32:15 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 98326154A6BB; Mon, 25 Mar 2019 00:32:15 +0000 (UTC) Delivered-To: arch@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 6ED8F154A6BA; Mon, 25 Mar 2019 00:32:15 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4E196F250; Mon, 25 Mar 2019 00:32:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-oi1-x229.google.com with SMTP id t206so5634749oib.3; Sun, 24 Mar 2019 17:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EmgJR6FIuqg2wxDs0+7sNzkmfnDmv1Fc0k0+TqsnOY=; b=cf7Jb4yoitUOSVMLFGsDwTenTD3KIyfeDrzibnFKrVK2n2P4spYgWidVJvEVv0hCPY H8Ocu/ev6CUeC4HBEMc+wy5G7C4Ubp0moGp+rVhmexD5rRxmeBCGiP3Xw2ksJyi6Badw ojgHOTeJCtmrq6MrA9hrLsk32a2AO+fXTGdN90sNqP8t9OX+qDfaagSzrlwKYCRtHBge 5Syg+WSsUyLN4JrhkLwAztk8/09jVWkajnhGHhBgCnC3ZFlVjzGp0Wn2iJRl32hW/ndK U4AzfOO/zNjuB1S9fvBCm0XNeA9QqgOk663/aET+K1RijpSUunWjsZE9KuRkz5lBtTXW wrbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EmgJR6FIuqg2wxDs0+7sNzkmfnDmv1Fc0k0+TqsnOY=; b=sHQtr0zPnMHrDMJzX2QViDgnpiFYKh10ZKdqrPadMRNE65oa8n1BSN+SlZ8txwu6t2 7u+JND4O0+JMi8YPWIgTv/PZlf4lPYbC7u7VvSaZfugoP7pOpbpNm5Gt/l0FwQOVm0eF KTUTddvTmm42FA+ymVoOxLdKbMqGC93lm78AkdZv/sJeuRM2aWgZJpRzG8PRGrAOFRNX BGjxFDyHWV6pf2Vzz78wby4snCbvB3nW6BCUWcAefXoiQD5DdqrCdMlB4ULkA4qoF5us TFSli4ab2QHLTJibvmZ0HFwtIesaiOuwf2Llw8CJ5xkgAIExNc8VHsbAq90P/o0L6DTJ xDRw== X-Gm-Message-State: APjAAAXo8C1aOPatG96MZVqjnxQi+JdDG/iWG62FOHK9iGLjU3SZiCHr mN86zH4kopJO+4ak66lF4aYQ/9Qd X-Google-Smtp-Source: APXvYqz+HdBjBLom83EdE308E29M6Jws+/4LFW30fe6rhHirQXBH49wgFrnRT95m0yj1ChL0lScEcg== X-Received: by 2002:aca:eb93:: with SMTP id j141mr9908318oih.178.1553473934005; Sun, 24 Mar 2019 17:32:14 -0700 (PDT) Received: from [100.168.146.207] ([172.56.6.99]) by smtp.gmail.com with ESMTPSA id e17sm5769609otp.41.2019.03.24.17.32.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 17:32:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" From: Enji Cooper X-Mailer: iPhone Mail (16D57) In-Reply-To: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> Date: Sun, 24 Mar 2019 17:32:10 -0700 Cc: Warner Losh , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> To: Rebecca Cran X-Rspamd-Queue-Id: E4E196F250 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:32:17 -0000 > On Mar 24, 2019, at 17:20, Rebecca Cran via freebsd-hackers wrote: >=20 >> On 3/24/19 5:57 PM, Warner Losh wrote: >>=20 >>=20 >> He's asking for stopping doing a make install in src/stand. I'm thinking t= hat's a good thing. We should update the ESP's \efi\freebsd\loader.efi, but l= eave the\efi\boot\bootXXXX.efi alone as part of this new installloader phase= . Again, only if the ESP is mounted, and we have a default spot for it. For t= his script, I don't think hunting for the ESP is the right way to go... whic= h means we need to define a standard place for the ESP to be mounted, which w= e should do before we turn on any of these features. >>=20 >> We have the start of a generic script to update things in src/tools/boot/= install-boot.sh which was supposed to install boot blocks on everything know= n to run FreeBSD. >=20 >=20 > Only updating \efi\freebsd\loader.efi is the wrong thing to do in my opini= on: there are situations like on ARM where EFI variables aren't persistent, a= nd we need \efi\boot\bootxxxx.efi for booting. What we could do is check if Q= ueryVariableInfo returns EFI_UNSUPPORTED, in which case we know any changes t= o BootXXXX variables won't survive a reboot, and we need BOOTxxxx.efi. >=20 > Is it safe to assume there's only a single ESP in the system? Is it not no= rmal for there to be one ESP per disk for mirrored configurations, in which c= ase each would need to be updated? >=20 > Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or rem= aining where it is? We'd also need to update the ESP for binary installs usi= ng freebsd-update. I was wondering about builds from scratch, as well=E2=80=94images comple= tely lacking boot blocks like Jenkins builds. Thanks! -Enji= From owner-freebsd-arch@freebsd.org Mon Mar 25 00:49:32 2019 Return-Path: Delivered-To: freebsd-arch@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 19B01154AE12 for ; Mon, 25 Mar 2019 00:49:32 +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 72B796FAFF for ; Mon, 25 Mar 2019 00:49:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C013154AE0F; Mon, 25 Mar 2019 00:49:31 +0000 (UTC) Delivered-To: arch@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 02999154AE0E for ; Mon, 25 Mar 2019 00:49:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69D6F6FAFE for ; Mon, 25 Mar 2019 00:49:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id z13so4367439qki.2 for ; Sun, 24 Mar 2019 17:49:30 -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=jQ7anEgsKTXSI0JC0fK+0Sq6mGbkY0ArWO40A+8431Y=; b=jQPVDRq+JaCo9lorOxNXWLC9D7JaMXi64LhRkHboMdfrM4M+Sq7NC6C/3igpKPXq11 ZXo5EGtr5Mxz25guHcsNjFOeRtZgwvJMOM4yScD+Aj079HuyJNpzpziqq4ItbVavyrop K2VbH6Sblsg/49QpJ1QYhPsse05DFka/VXhapg73j2wAdoErEsZjPpTw0aRufyeL1N6x lpIwbssmZcbM4ifZ/AZ7WVdQsHjuhwZPU3FXUxp3crWDRptl/3dIv+tAPFZdrN8+34vR d6pTQRl5uQFOtME38TdAnRRUHlnuy7fxDTxLcOo8l+bklNX/zH1UDtYcXdSfJonyVRbZ L/8A== 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=jQ7anEgsKTXSI0JC0fK+0Sq6mGbkY0ArWO40A+8431Y=; b=NqrBeGjTANjwXs0vO0p+WJX1x7xFBTbQOY1DaCYfcFKZf1YqtmrywVH3tcMg6CVWU0 PGPyFP+2vATD7l8LhsaYI/Q/XGcxfnBf+IMCVBRmcVwwOjpTo3UXO5sFOyK/pFuBT2JX u3X20gGn8Mm9nkK0QDv4Hl9FtB/uvFDOTIOXPawfFRIihLHC7+3yoOTy5B+i3gWFTnaY 38RH5pHgMrJ5sdK7TSfGweEUyatkK8prUZilGuKpCBDAgBsaXEdE3tRGMGPqHHHtUeTZ s1meo7LbDbhKyRU3dX9b0aUdQNYlASe5Gh1ssl/lU4rpOO3P//gZVEkj0LSA7f3n9RK2 8ZMg== X-Gm-Message-State: APjAAAXoF/i52eBkgG2ImS2fR51urtzwDKKp2z8+5/OWQjUDUvX0J4GD 8/x3tpxVQ1bwENjZ7FB8YEFRvQxcD2feV1z6hsJMUQ== X-Google-Smtp-Source: APXvYqzWNCeSKZjMzbHcsL0yvKmJanpI11DGsFx5LHOlrWWHk4HYUpZXFfppkVdb89XLJzTT4QRtnjxYgmvIM3JlLYs= X-Received: by 2002:a37:bce:: with SMTP id 197mr18053852qkl.46.1553474969741; Sun, 24 Mar 2019 17:49:29 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> In-Reply-To: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> From: Warner Losh Date: Sun, 24 Mar 2019 18:49:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 69D6F6FAFE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:49:32 -0000 On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran wrote: > On 3/24/19 5:57 PM, Warner Losh wrote: > > > He's asking for stopping doing a make install in src/stand. I'm thinking > that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, > but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader > phase. Again, only if the ESP is mounted, and we have a default spot for > it. For this script, I don't think hunting for the ESP is the right way to > go... which means we need to define a standard place for the ESP to be > mounted, which we should do before we turn on any of these features. > > We have the start of a generic script to update things in > src/tools/boot/install-boot.sh which was supposed to install boot blocks on > everything known to run FreeBSD. > > > Only updating \efi\freebsd\loader.efi is the wrong thing to do in my > opinion: there are situations like on ARM where EFI variables aren't > persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could > do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case we > know any changes to BootXXXX variables won't survive a reboot, and we need > BOOTxxxx.efi. > Systems that don't support variables are a super duper weird special case. Let's not let them drive the design. I want to get to (a) a standardized mount point and (b) drive people towards having the boot loader be in /efi/freebsd/loader.efi. our tooling should reflect that first and foremost. The weirdo, special cases that likely won't be updating from source are secondary. Let's get a good design flow down first for the most common case, one that encourages the most people to adopt the standard boot flow as possible. Is it safe to assume there's only a single ESP in the system? Is it not > normal for there to be one ESP per disk for mirrored configurations, in > which case each would need to be updated? > None of those are safe. We shouldn't look for the ESP to mount. It should be mounted and we should only update it if it is. DWIM will get us into a lot of trouble with the boot path, I believe. Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or > remaining where it is? We'd also need to update the ESP for binary installs > using freebsd-update > Eventually, but it has a ways to go. Warner > -- > Rebecca Cran > From owner-freebsd-arch@freebsd.org Mon Mar 25 00:51:28 2019 Return-Path: Delivered-To: freebsd-arch@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 07866154B0AA for ; Mon, 25 Mar 2019 00:51:28 +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 59A506FE84 for ; Mon, 25 Mar 2019 00:51:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 19E9C154B0A6; Mon, 25 Mar 2019 00:51:27 +0000 (UTC) Delivered-To: arch@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 EBD47154B0A4 for ; Mon, 25 Mar 2019 00:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F5F76FE81 for ; Mon, 25 Mar 2019 00:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id d13so3788552qth.5 for ; Sun, 24 Mar 2019 17:51:26 -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=D8cSRfTNV/YycywAIKQPNAQnzVmklsOC9K5kQL7BZBA=; b=GDTCXE6ZcrSh4ehjybToufN1GhCEb4MiKywZXUkO2Y+Lm3tX5nopX5tXiaVyxV0VXU 11JCScXeGyJacFVIqC2sp/zPRf/6ga2cuUvxhwt9+SWzLHtGaSo/uzjEdLybcPatrshk JEB98wNkM33nLghUia03dyA4M3sO2/3QgNTnB0TN8j38NSS1qBSpTWdYcYCb7lIXYutX oPNEG7710VJ3kC9FZaUjuvjd/wxCOx5c/sC+8uhM3J3+BbPhcFahIKroLpMrLkSeuW9L nVm4tyBfRnopI9W+/3RCOvQUOOJ2BkUI+/0IloRN3XnGliKkPYQ/wgMcbtpRusLUu2+9 2RcQ== 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=D8cSRfTNV/YycywAIKQPNAQnzVmklsOC9K5kQL7BZBA=; b=BsE2pxCmuUqmNH4GHFpdzF/gyeECXCD8pJLPWs8u90L3r5ddWYMca5ycEruV+fcW62 yjtYa4D8x9at4OAv7gEi/ALf2K2Mlsxkj7ZHyHgT8eOksTjvvEanv/foJIOYUGG7OGpo VXNMs8gDoT0bIn9IaxeROxrfNa+uHPyULu8/v6vXvdS7fPjvWvaXoumd+3CbxI1/mosc dsP+sUS9vPSD+WDVUdtv0nxd48HWYqdyuBDy4CrRiStopyS8DkdSX0oaU84yHyXaD13z f9lB6nybB0rVLNvpmH3AwP2kclTcV2Ew/nkdWX3r7ZWAehv/pqg+J/5VWZgNWGfTTaKR 1C7w== X-Gm-Message-State: APjAAAWfw27a30A01ZV0mSzkhEUarw3pZQ348fIZrVhd7EekjPYOaSoX vho+HBcO5NWeN3uo8WKchEPLgNFSqk+tveBMuim/fA== X-Google-Smtp-Source: APXvYqwfnjvOdYNY6k1i6jmLE2WUOttXjifPQZfMIrm3I+hZ5quPU+o0dXU5eC3+lEl5c4fXnsBMsMitVmj2PDmge08= X-Received: by 2002:ac8:28d0:: with SMTP id j16mr18553323qtj.15.1553475085947; Sun, 24 Mar 2019 17:51:25 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> In-Reply-To: From: Warner Losh Date: Sun, 24 Mar 2019 18:51:13 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Garrett Cooper Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 8F5F76FE81 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:51:28 -0000 On Sun, Mar 24, 2019, 6:32 PM Enji Cooper wrote: > > > On Mar 24, 2019, at 17:20, Rebecca Cran via freebsd-hackers < > freebsd-hackers@freebsd.org> wrote: > > > >> On 3/24/19 5:57 PM, Warner Losh wrote: > >> > >> > >> He's asking for stopping doing a make install in src/stand. I'm > thinking that's a good thing. We should update the ESP's > \efi\freebsd\loader.efi, but leave the\efi\boot\bootXXXX.efi alone as par= t > of this new installloader phase. Again, only if the ESP is mounted, and w= e > have a default spot for it. For this script, I don't think hunting for th= e > ESP is the right way to go... which means we need to define a standard > place for the ESP to be mounted, which we should do before we turn on any > of these features. > >> > >> We have the start of a generic script to update things in > src/tools/boot/install-boot.sh which was supposed to install boot blocks = on > everything known to run FreeBSD. > > > > > > Only updating \efi\freebsd\loader.efi is the wrong thing to do in my > opinion: there are situations like on ARM where EFI variables aren't > persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could > do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case w= e > know any changes to BootXXXX variables won't survive a reboot, and we nee= d > BOOTxxxx.efi. > > > > Is it safe to assume there's only a single ESP in the system? Is it not > normal for there to be one ESP per disk for mirrored configurations, in > which case each would need to be updated? > > > > Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or > remaining where it is? We'd also need to update the ESP for binary instal= ls > using freebsd-update. > > I was wondering about builds from scratch, as well=E2=80=94images com= pletely > lacking boot blocks like Jenkins builds. > You wouldn't run installloader on those. It's also a reason I don't want to guess too much... Warner > Thanks! > -Enji From owner-freebsd-arch@freebsd.org Mon Mar 25 00:54:16 2019 Return-Path: Delivered-To: freebsd-arch@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 41329154B2E2 for ; Mon, 25 Mar 2019 00:54:16 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 AB39E700F8 for ; Mon, 25 Mar 2019 00:54:15 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6A0F1154B2E0; Mon, 25 Mar 2019 00:54:15 +0000 (UTC) Delivered-To: arch@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 2B0A3154B2DE; Mon, 25 Mar 2019 00:54:15 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEDE700F6; Mon, 25 Mar 2019 00:54:14 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 2D77FC0AA8; Sun, 24 Mar 2019 18:55:17 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xkT3_JHVcEbw; Sun, 24 Mar 2019 18:55:16 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 18:55:16 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh , Garrett Cooper Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> From: Rebecca Cran Message-ID: <49d1a599-b479-edb1-a88f-48cae19b55af@bluestop.org> Date: Sun, 24 Mar 2019 18:54:12 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 9DEDE700F6 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:54:16 -0000 On 3/24/19 6:51 PM, Warner Losh wrote: > > On Sun, Mar 24, 2019, 6:32 PM Enji Cooper > wrote: > > > >     I was wondering about builds from scratch, as well—images > completely lacking boot blocks like Jenkins builds. > > > You wouldn't run installloader on those. It's also a reason I don't > want to guess too much... The script as it is looks for partitions of type 'efi' which have a FreeBSD \efi\boot\boot${arch}.efi or \efi\freebsd\loader.efi, and if they exist it'll update them - the assumption being that booting FreeBSD already works, since it's been installed/configured via the installer or some other method. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Mon Mar 25 00:55:50 2019 Return-Path: Delivered-To: freebsd-arch@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 4FFD1154B47C for ; Mon, 25 Mar 2019 00:55:50 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 E9FB97026F for ; Mon, 25 Mar 2019 00:55:49 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id AD9E2154B476; Mon, 25 Mar 2019 00:55:49 +0000 (UTC) Delivered-To: arch@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 9B08B154B473; Mon, 25 Mar 2019 00:55:49 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3807370264; Mon, 25 Mar 2019 00:55:49 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 15CAFC0AB1; Sun, 24 Mar 2019 18:56:52 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6kJd_QahdH8S; Sun, 24 Mar 2019 18:56:51 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 18:56:51 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Konstantin Belousov Cc: FreeBSD Hackers , arch@freebsd.org References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> From: Rebecca Cran Message-ID: <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> Date: Sun, 24 Mar 2019 18:55:47 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190325000241.GS1923@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 3807370264 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 00:55:50 -0000 On 3/24/19 6:02 PM, Konstantin Belousov wrote: > > Having efi_update_loader alone would be fine, but I doubt that this > script can do much except in situations where a lot of pre-assumptions > are true. I believe that despite all the efforts put into efibootmgr > and installer, it is hard/impossible to make the script not dangerous, > except if the whole configuration was created by our installer. It currently does nothing except if there is one or more partitions of type 'efi' that contain a \efi\boot\boot${arch}.efi or \efi\freebsd\loader.efi that contain strings from the FreeBSD boot1.efi or loader.efi. Perhaps that's too much guessing, and we should only ever update /boot/msdos or /boot/efi or wherever we decide to mount it. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Mon Mar 25 01:34:47 2019 Return-Path: Delivered-To: freebsd-arch@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 633ED154CDDD for ; Mon, 25 Mar 2019 01:34:47 +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 AA6BC71A68 for ; Mon, 25 Mar 2019 01:34:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B1F5D154CDD9; Mon, 25 Mar 2019 01:34:45 +0000 (UTC) Delivered-To: arch@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 8FD72154CDD0 for ; Mon, 25 Mar 2019 01:34:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB6971A3E for ; Mon, 25 Mar 2019 01:34:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82d.google.com with SMTP id z17so8500701qts.13 for ; Sun, 24 Mar 2019 18:34:45 -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=VdvE+KGTsGuE+pmu8fmbNeAK396tsYhHvb0KhY6v+4I=; b=Ofq25uzEk1NlSjQ3rMs7Ozux1kSDdYUTjI3W/6fHHn0ZeJQW9+6hvSfQvtrGFUeD31 nvYhhwGiA4OqA3FIRyMbA++7C4HlccXjdtk3kaqsEKZyBC3pl9t0Wt4UQsW600rlTexZ /vJsbjK1WagIthMetsr1Db6t8HT06k6oROesrB8i0vfCabXVY8Ra1VI0E2jZ04nKCNh2 tvmJU4e5v3llzml2CiUkXQgqjM8Z4aZLsly2g1TElD/RXDz21crXLyFxUkQQEq9YilJ/ lvAB5hwE3Qn2gN21TWJQdKCnGC2UMcYaB+KVS2WCsRlua14YIzdNmlcVec3zDs/RDoEB C5tQ== 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=VdvE+KGTsGuE+pmu8fmbNeAK396tsYhHvb0KhY6v+4I=; b=sWTe94ZaenrGsaODIFe8NZ+c3JIlRrUf4dxEfg60Z8PFBk0L9XJL6SzzPCvmPZkyj+ pl7KZfuIo2e3ZpouBhQ9dMNmQqiVqeWUfHQtP789PbqvQJTa/khWa2MwMCx9Ej+VHNst nK8dof1tuMYLiepu66++y4b6/YunCdSEWirwJIKIxgHAuy8GuIyW+dkgFWusdeImz3DF XUDyeYNjzl5n0Re+Ob4jlg1TuH8d0tw16rDjZX6JnNpBsQyjY19LZwALwjFCwd1XPuur tQ8F2MBghAsyXNjv+EejDW7cMKsmn/FXm+9pNA6mQXWidXkkGrml8ED1tdXZca31NP1C ppWg== X-Gm-Message-State: APjAAAW1YEnSmF4smJqKp4yBx3UlVP53PtasAB1aM/dGybYf23aes7Z3 Q0P7izkEcoTFGm7uRmRB4UOpTP2UR1KNw1SPnxxXZg== X-Google-Smtp-Source: APXvYqyw6NMttqVIpT4q/GN+FUZVdHFkry4svbU5lNqCWmDZlNL4WX98uiS3Znzw3t/0M0PXrtPpAPki+qmtKQyY5Dc= X-Received: by 2002:ac8:4685:: with SMTP id g5mr11735232qto.242.1553477684110; Sun, 24 Mar 2019 18:34:44 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> In-Reply-To: <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> From: Warner Losh Date: Sun, 24 Mar 2019 19:34:33 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 2CB6971A3E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 01:34:47 -0000 On Sun, Mar 24, 2019 at 6:59 PM Rebecca Cran via freebsd-arch < freebsd-arch@freebsd.org> wrote: > On 3/24/19 6:02 PM, Konstantin Belousov wrote: > > > > > Having efi_update_loader alone would be fine, but I doubt that this > > script can do much except in situations where a lot of pre-assumptions > > are true. I believe that despite all the efforts put into efibootmgr > > and installer, it is hard/impossible to make the script not dangerous, > > except if the whole configuration was created by our installer. > > > It currently does nothing except if there is one or more partitions of > type 'efi' that contain a \efi\boot\boot${arch}.efi or > \efi\freebsd\loader.efi that contain strings from the FreeBSD boot1.efi > or loader.efi. Perhaps that's too much guessing, and we should only ever > update /boot/msdos or /boot/efi or wherever we decide to mount it. > Right. We need a standard location (that maybe can be overridden, like you can with /boot, if you really want), and that's likely the first order of business. I don't think we should be second guessing, though. And we shouldn't be touching \efi\boot anything unless specifically instructed to do so. I'm deeply uncomfortable with guessing whether or not to do something... Warner From owner-freebsd-arch@freebsd.org Mon Mar 25 01:52:38 2019 Return-Path: Delivered-To: freebsd-arch@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 B160F154D7F9 for ; Mon, 25 Mar 2019 01:52:38 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 2F4CC725F2 for ; Mon, 25 Mar 2019 01:52:38 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id E230C154D7F5; Mon, 25 Mar 2019 01:52:37 +0000 (UTC) Delivered-To: arch@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 CDCF9154D7F4; Mon, 25 Mar 2019 01:52:37 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 651D7725F1; Mon, 25 Mar 2019 01:52:37 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 920A1C0AF8; Sun, 24 Mar 2019 19:53:39 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D6LG_xGsqKGM; Sun, 24 Mar 2019 19:53:39 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 19:53:39 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> From: Rebecca Cran Message-ID: Date: Sun, 24 Mar 2019 19:52:34 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 651D7725F1 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 01:52:38 -0000 On 3/24/19 7:34 PM, Warner Losh wrote: > > Right. We need a standard location (that maybe can be overridden, like you > can with /boot, if you really want), and that's likely the first order of > business. I don't think we should be second guessing, though. And we > shouldn't be touching \efi\boot anything unless specifically instructed to > do so. I'm deeply uncomfortable with guessing whether or not to do > something... Okay. I'm pretty frustrated at only getting this feedback now: I guess I should post here more often! I thought we'd had this discussion a few months ago and you were against mounting the ESP by default, but I can revisit the installer and have it mount to /boot/msdos or /boot/efi or wherever. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Mon Mar 25 02:02:53 2019 Return-Path: Delivered-To: freebsd-arch@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 C97E0154DCD3 for ; Mon, 25 Mar 2019 02:02:52 +0000 (UTC) (envelope-from chmeeedalf@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 2B7A272B85 for ; Mon, 25 Mar 2019 02:02:52 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E36EC154DCD0; Mon, 25 Mar 2019 02:02:51 +0000 (UTC) Delivered-To: arch@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 A5C54154DCCF; Mon, 25 Mar 2019 02:02:51 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01C4372B84; Mon, 25 Mar 2019 02:02:51 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lj1-x22a.google.com with SMTP id q66so6368171ljq.7; Sun, 24 Mar 2019 19:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aJeu1NTURKy1VWVkLtvE5BtQ2OWfA6tHpBYYJQICpn8=; b=FCLd0ArOzBJvkh22jT0tanZmm9kQj9tDlsbCqaizikpzsl0by6S1liKLmQh1t3iT4h nopUmhtIdOh/3PZ3T0NpHC8S2sKlWm7W0gIP1fxJfKeE4/owD/v4yHBEVcbFX53PocFF UkcH9iChb0HqP03lFOLOGMPx89Mfls4WMf9fPkHVyQAH+aNknf0MsZLUsGDXMObeKxLW YVOectw34807j1gZsT32fiM9iIKwdSgdHQjSja/6sespd4XSRcTmSGisUI2tUl4TE6W3 e7YvxKwSpKcbb80lsHSJEwmYWTaDOY1BPOcj8WdAp8s1luC4PjpgCXErZQbmRiw1uIih MsjQ== 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=aJeu1NTURKy1VWVkLtvE5BtQ2OWfA6tHpBYYJQICpn8=; b=VPK1c2leUgIIx8Q+oHMkEAW3TJTPbLf2ITzin/u4hqtmjWnKZYKm9xWkk/t99K3+4m Z446DS1jdFS0aTknMunLWpmuv6AMS3lyrEYYkC08Hh+oO/1F2nsVEwYSzbX1TMApptyE w3a/73Tv5L1elfznbVR15o+J/RpupFRxpw8Nv6fYMzdiTYwpjKCKtGe0dzHlapRCdRQ6 ShNlqdepaNTIVR7mWbY26I5HiHmUulaP4g0NXFay3UBczxNiH3m/EPpMj5ZOXfNfC9/v 84FH7v62WRHH3CTinPukDUBXE/Twyn2pnuKr2+rbu7ZVMLOoWUo1+cAEnfz1xhmGclmI SUqQ== X-Gm-Message-State: APjAAAUmOg7+Y04v87TmFockyci5cw3KzbMSXxJVDSkjRE0zpxqasby4 fVBTbo4igsnYrueJLGxgHfQ8/qIKHsoSv4xyUoE= X-Google-Smtp-Source: APXvYqwAZTZC0373bARniAumS0NoPfLQzQFvuTl7y7XcfLHMTdHOhvrXp7y1fpWkLczcdQ3g2TK8V68L538K9fAn7cM= X-Received: by 2002:a2e:974d:: with SMTP id f13mr11430479ljj.140.1553479369343; Sun, 24 Mar 2019 19:02:49 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> In-Reply-To: From: Justin Hibbits Date: Sun, 24 Mar 2019 21:02:36 -0500 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 01C4372B84 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 02:02:53 -0000 On Sun, Mar 24, 2019 at 8:38 PM Warner Losh wrote: ... > > Right. We need a standard location (that maybe can be overridden, like you > can with /boot, if you really want), and that's likely the first order of > business. I don't think we should be second guessing, though. And we > shouldn't be touching \efi\boot anything unless specifically instructed to > do so. I'm deeply uncomfortable with guessing whether or not to do > something... > > Warner When I added /boot/uboot, primarily for powerpc, Ian suggested we unify them all into /boot/bootfs, since ARM uses /boot/msdos. With the EFI partition now needed, I think /boot/bootfs is the better solution, and the installer can pick the bootfs to mount there into the fstab. - Justin From owner-freebsd-arch@freebsd.org Mon Mar 25 02:06:40 2019 Return-Path: Delivered-To: freebsd-arch@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 8E36F154DDC1 for ; Mon, 25 Mar 2019 02:06:40 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 0E83472C8D for ; Mon, 25 Mar 2019 02:06:40 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id C0345154DDBE; Mon, 25 Mar 2019 02:06:39 +0000 (UTC) Delivered-To: arch@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 9AF8A154DDBD; Mon, 25 Mar 2019 02:06:39 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3489F72C8B; Mon, 25 Mar 2019 02:06:39 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 72A56C0B1B; Sun, 24 Mar 2019 20:07:41 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AU0hisuNZWnT; Sun, 24 Mar 2019 20:07:40 -0600 (MDT) Received: from [10.0.10.197] (unknown [65.103.231.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 20:07:40 -0600 (MDT) Date: Sun, 24 Mar 2019 20:05:43 -0600 From: rebecca@bluestop.org To: Warner Losh , Justin Hibbits Cc: Konstantin Belousov , "=?utf-8?Q?freebsd-arch=40freebsd.org?=" , FreeBSD Hackers Message-ID: In-Reply-To: References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" X-Readdle-Message-ID: db0955a4-6de5-4c7a-b653-4a17a91042b4@Spark MIME-Version: 1.0 X-Rspamd-Queue-Id: 3489F72C8B X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.945,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 02:06:40 -0000 On Mar 24, 2019, 8:04 PM -0600, Justin Hibbits , wrote: > > When I added /boot/uboot, primarily for powerpc, Ian suggested we > unify them all into /boot/bootfs, since ARM uses /boot/msdos. With > the EFI partition now needed, I think /boot/bootfs is the better > solution, and the installer can pick the bootfs to mount there into > the fstab. I like that. Rebecca From owner-freebsd-arch@freebsd.org Mon Mar 25 02:30:17 2019 Return-Path: Delivered-To: freebsd-arch@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 02694154E6EC for ; Mon, 25 Mar 2019 02:30:17 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 70435736FD for ; Mon, 25 Mar 2019 02:30:16 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 311F0154E6E9; Mon, 25 Mar 2019 02:30:16 +0000 (UTC) Delivered-To: arch@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 1F971154E6E8; Mon, 25 Mar 2019 02:30:16 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABFCA736FC; Mon, 25 Mar 2019 02:30:15 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id B5856C0B40; Sun, 24 Mar 2019 20:31:17 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8FBvfxhnXHbK; Sun, 24 Mar 2019 20:31:17 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 20:31:17 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> From: Rebecca Cran Message-ID: <4cdd585b-2469-fb19-9ac6-5d0af7b9f607@bluestop.org> Date: Sun, 24 Mar 2019 20:30:13 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: ABFCA736FC X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.969,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 02:30:17 -0000 On 3/24/19 7:34 PM, Warner Losh wrote: > > Right. We need a standard location (that maybe can be overridden, like you > can with /boot, if you really want), and that's likely the first order of > business. I don't think we should be second guessing, though. And we > shouldn't be touching \efi\boot anything unless specifically instructed to > do so. I'm deeply uncomfortable with guessing whether or not to do > something... I'd be wary of *not* touching \efi\boot, since both Microsoft and Linux installs \efi\boot\bootx64.efi. And with desktop systems often not having an UEFI Shell built in and no option to browse for a boot loader from the BIOS, if the FreeBSD boot entry gets lost somehow they're stuck. I discovered recently that rEFInd at least knows to look for \efi\freebsd\loader.efi, but otherwise recovery could be pretty tricky for people who aren't familiar with UEFI. Perhaps adding an option to the efi-update-loader script to search for and list potential ESPs could help, along with good documentation of efibootmgr etc. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Mon Mar 25 09:26:50 2019 Return-Path: Delivered-To: freebsd-arch@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 13AFE155884A for ; Mon, 25 Mar 2019 09:26:50 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 5681688685 for ; Mon, 25 Mar 2019 09:26:49 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 101681558844; Mon, 25 Mar 2019 09:26:49 +0000 (UTC) Delivered-To: arch@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 F0187155883F; Mon, 25 Mar 2019 09:26:48 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEBD788681; Mon, 25 Mar 2019 09:26:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2P9QgaN078737; Mon, 25 Mar 2019 02:26:42 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2P9QgYK078736; Mon, 25 Mar 2019 02:26:42 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <20190324090103.GO1923@kib.kiev.ua> To: Konstantin Belousov Date: Mon, 25 Mar 2019 02:26:42 -0700 (PDT) CC: Rebecca Cran , FreeBSD Hackers , arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: AEBD788681 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.14 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.01)[-0.009,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.50)[0.502,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.74)[0.739,0]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.08), ipnet: 69.59.192.0/19(0.04), asn: 13868(0.02), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 09:26:50 -0000 > On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via freebsd-hackers wrote: > > I've been working on EFI support, and have a review > > (https://reviews.freebsd.org/D19588) to add a script, efi-update-loader, > > which will update the ESP containing the FreeBSD boot1.efi or loader.efi. > > > > I'd like to integrate it into the build system so it gets run when users > > do a "make installworld", but I'm lost looking through Makefile.inc1 - I > > have no clue where to add the code. > > > > Does anyone understand where and what to add? > > Can we take use of the opportunity and finally stop installing loader > at installworld target at all, please ? > > Add e.g. installloader target which would do whatever needed to loader. +1 boot code and loaders should always be seperated from the install target. Historically this was casued by the fact that the boot code and loader lived outside the file system and required operations beyond updating /usr/mdec (very ancient) or /boot/boot* (historical). Now that /boot/loader* is an immeditate effect on the bootability of the system it makes since to seperate this from the installworld target. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Mon Mar 25 10:33:32 2019 Return-Path: Delivered-To: freebsd-arch@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 571C6155AC1E for ; Mon, 25 Mar 2019 10:33:32 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 A1A2C8B3E5 for ; Mon, 25 Mar 2019 10:33:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 58472155AC1B; Mon, 25 Mar 2019 10:33:31 +0000 (UTC) Delivered-To: arch@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 45AB6155AC1A; Mon, 25 Mar 2019 10:33:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB9618B3E4; Mon, 25 Mar 2019 10:33:30 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2PAXMuC079241; Mon, 25 Mar 2019 03:33:22 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2PAXMBK079240; Mon, 25 Mar 2019 03:33:22 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903251033.x2PAXMBK079240@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: rebecca@bluestop.org Date: Mon, 25 Mar 2019 03:33:22 -0700 (PDT) CC: Warner Losh , Justin Hibbits , Konstantin Belousov , "=?utf-8?Q?freebsd-arch=40freebsd.org?=" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: BB9618B3E4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 10:33:32 -0000 > On Mar 24, 2019, 8:04 PM -0600, Justin Hibbits , wrote: > > > > When I added /boot/uboot, primarily for powerpc, Ian suggested we > > unify them all into /boot/bootfs, since ARM uses /boot/msdos. With > > the EFI partition now needed, I think /boot/bootfs is the better > > solution, and the installer can pick the bootfs to mount there into > > the fstab. > > > I like that. +1 > Rebecca -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Mon Mar 25 10:33:53 2019 Return-Path: Delivered-To: freebsd-arch@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 ED981155AC73 for ; Mon, 25 Mar 2019 10:33:52 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) 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 094518B45A for ; Mon, 25 Mar 2019 10:33:52 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: by mailman.ysv.freebsd.org (Postfix) id C1F0B155AC6D; Mon, 25 Mar 2019 10:33:51 +0000 (UTC) Delivered-To: arch@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 8AE84155AC6C; Mon, 25 Mar 2019 10:33:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2617D8B44F; Mon, 25 Mar 2019 10:33:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.0.12] (cpc91194-cmbg18-2-0-cust919.5-4.cable.virginm.net [80.6.183.152]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 9A2F04E6E6; Mon, 25 Mar 2019 10:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1553510021; bh=Z8MAmmC/K8A9vCio/5nSFTsKReU1TEGDIP9cGfn8Wts=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=diWjpZWxC203lQ0fMViGvt+ArAmDZbEyj2MxU22WGidLAfXTcvG+J1mLNfglQvLl9 Jli3UZuNxbh12VoLGCeq3XLK/TlqvjsciK1+o7l5ma31zLjkgdWreMtfvMvwnPsRs6 BC6v6r4y7AfutZAW8oCjZLyzkEROlTU8WvzTH87uEwuGDNsUd7CoiwdnFacPUs2xja 29Y2YDZ3mrSPCa8xHQLNMFXFwNb/LDIPQKYDpfhMVN8skRrEFcSl8I3EuqN7rdEm18 c4f081xWBmLrTWA9I4EZZky6oOu8N7vE0Reel/ZRVXf0SAtmyR0BHfxF5wEk5m61bF 9SBaxyr1EZ32fsNnPC8///TF4tv8UEqDWTDSXEK7pKrzo43Pn9iTNnkmT4rMQSLg8C /o/BmY9+DUxPJkR1qoHrTsuvASNLJBtWy+PhpMLtoidK4/vk1xYIkTQhc6oi1JLdcd eMCDz+Vs4b7VKDO6mkQbmZJJsCLnPL+beHh3yGTUta2uiGStGeAJtEspTyERG0Iszj zc1BkcHTHUrwWL04Pm5hc64M0yzo+Na7AzgDXmaV/jzvYiacArTki3ls7EcOtQAyV6 ScakReWiO4llhYOv9BsI+Kr2Y9BHVuFqpzNCZXRX+oaLJAF+RgxGWcdYvJm7L/fbr6 IrPnGVi+v/vPSk0RBCVxdwOE= From: Andrew Turner Message-Id: <2E6E33E9-FF5E-4198-AC48-37C0873CAF95@fubar.geek.nz> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Date: Mon, 25 Mar 2019 10:33:40 +0000 In-Reply-To: Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" To: Warner Losh References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 2617D8B44F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 10:33:53 -0000 > On 25 Mar 2019, at 00:49, Warner Losh wrote: >=20 > On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran > wrote: >=20 >> On 3/24/19 5:57 PM, Warner Losh wrote: >>=20 >>=20 >> He's asking for stopping doing a make install in src/stand. I'm = thinking >> that's a good thing. We should update the ESP's = \efi\freebsd\loader.efi, >> but leave the\efi\boot\bootXXXX.efi alone as part of this new = installloader >> phase. Again, only if the ESP is mounted, and we have a default spot = for >> it. For this script, I don't think hunting for the ESP is the right = way to >> go... which means we need to define a standard place for the ESP to = be >> mounted, which we should do before we turn on any of these features. >>=20 >> We have the start of a generic script to update things in >> src/tools/boot/install-boot.sh which was supposed to install boot = blocks on >> everything known to run FreeBSD. >>=20 >>=20 >> Only updating \efi\freebsd\loader.efi is the wrong thing to do in my >> opinion: there are situations like on ARM where EFI variables aren't >> persistent, and we need \efi\boot\bootxxxx.efi for booting. What we = could >> do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which = case we >> know any changes to BootXXXX variables won't survive a reboot, and we = need >> BOOTxxxx.efi. >>=20 > Systems that don't support variables are a super duper weird special = case. > Let's not let them drive the design. I want to get to (a) a = standardized > mount point and (b) drive people towards having the boot loader be in > /efi/freebsd/loader.efi. our tooling should reflect that first and > foremost. The weirdo, special cases that likely won't be updating from > source are secondary. Let's get a good design flow down first for the = most > common case, one that encourages the most people to adopt the standard = boot > flow as possible. Systems that don=E2=80=99t support reading variables are weird, however = systems that don=E2=80=99t support writing valuables are common for arm = and arm64. The EBBR spec [1] that Arm and others are working on allows = both reading and writing variables via the runtime services as optional = [2]. This is because these variables may be stored on the same media as = the OS. It would be nice if we could support this case, even if it=E2=80=99s not = the default on systems that support setting variables. Andrew [1] https://github.com/ARM-software/ebbr [2] = https://github.com/ARM-software/ebbr/blob/v1.0-rc1/source/chapter2-uefi.rs= t From owner-freebsd-arch@freebsd.org Mon Mar 25 15:06:02 2019 Return-Path: Delivered-To: freebsd-arch@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 D110A1564405 for ; Mon, 25 Mar 2019 15:06:01 +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 09ED4702D5 for ; Mon, 25 Mar 2019 15:06:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B9A591564401; Mon, 25 Mar 2019 15:06:00 +0000 (UTC) Delivered-To: arch@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 9061A1564400 for ; Mon, 25 Mar 2019 15:06:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22EB1702D3 for ; Mon, 25 Mar 2019 15:06:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x833.google.com with SMTP id k2so10685019qtm.1 for ; Mon, 25 Mar 2019 08:06:00 -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=FDfsshC9FKErvG/Uc+ILi7Fjxse6R0055fLkUe05UPQ=; b=kf0HGvprXrrnWEF0viPKHCNtWCxHPd87TfYFZxJ1T+21mgdJi5MgQ+1m9HgP3CHewB SkWPJLRVUDhPs9Qiq468x8AKILZQlT63GnK/+TFBgpsYN0E2g1Od2At0+qXZ5bx9T9Uj Y/t9h7DXK3mHrbLuH+yFLrFbJEbuxTHU0dnlo4QVfwB7A93ItKDLA9hA+v4P75QpLGYz ENpjgjqN8xQWJErf7RBS6Tqy54J1Co8Yn3gwnTc+3z3t0B4+r+D4sudo7DaZ/9a9Odxp C79VxLS4nP8EEIlXJviOmpo3RbVTJr3n+j8YZCZbJlydO/OpMQ/tM5NcbHfYfcw5ErDg J0Zg== 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=FDfsshC9FKErvG/Uc+ILi7Fjxse6R0055fLkUe05UPQ=; b=h+y1mfgohvD2/TRUTapvg3h7LdefnIIEQUd8gjLy3wJ9sENcTa+sst8ddFyW91bvMR ENpVEfUnyl1AziBkoBz0oN9hSPmEjKkF15/nN770RDw1G8FnaYcNaNhdquDyxpxMMlBI a4MIjIZovwtYL01abWZdJEb77jmZu7V6nKsR146VpOFajFK5G4U2ZFtrzbEJ9uGB5sZ9 rMi3YWisdhct1cEsYflyLLhffZvRqhTb/AuiZf89Glb+peJjRd8ut8M/1iwzca61AcZp KDK4SxRgH01tLce4ep+Ct9BcGKMww8fCJrfw7oTIxleyMwZX0CmtnT+Ds/0qJ1XFhfnz AHJA== X-Gm-Message-State: APjAAAWhN1/V5CKE0YmAZ5aGfovlSFD8Oi9htwKwz8ilCyNkMMDlHJ7t npy9PfP+fx3NHQT4XE9WII8kcqpj8M7LZSXJdZS/IQ== X-Google-Smtp-Source: APXvYqzFLUDxjfu0plK9EZWKzOJodrQLiAvkmqamurWgJG4+4IStDM+r4XQeMvhehvqZzjVIXtYQNMqYZtxXj/tlkg4= X-Received: by 2002:a0c:d2fc:: with SMTP id x57mr19537966qvh.214.1553526359472; Mon, 25 Mar 2019 08:05:59 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> In-Reply-To: <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 25 Mar 2019 09:05:45 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Rspamd-Queue-Id: 22EB1702D3 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.979,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:06:02 -0000 On Mon, Mar 25, 2019, 3:28 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via > freebsd-hackers wrote: > > > I've been working on EFI support, and have a review > > > (https://reviews.freebsd.org/D19588) to add a script, > efi-update-loader, > > > which will update the ESP containing the FreeBSD boot1.efi or > loader.efi. > > > > > > I'd like to integrate it into the build system so it gets run when > users > > > do a "make installworld", but I'm lost looking through Makefile.inc1 - > I > > > have no clue where to add the code. > > > > > > Does anyone understand where and what to add? > > > > Can we take use of the opportunity and finally stop installing loader > > at installworld target at all, please ? > > > > Add e.g. installloader target which would do whatever needed to loader. > > +1 boot code and loaders should always be seperated from the > install target. Historically this was casued by the fact that > the boot code and loader lived outside the file system and > required operations beyond updating /usr/mdec (very ancient) > or /boot/boot* (historical). Now that /boot/loader* is an > immeditate effect on the bootability of the system it makes > since to seperate this from the installworld target. > We started installing /boot/loader with install world in FreeBSD -3.x and it has affected the boot ability that whole time... in the early days of loader, the kernel loader handoff protocol was immature enough to need a matched kernel. But that period lasted only a few months... loader has also been weird in other ways as well, since some embedded systems used the one in its, while others needed an extra step. As UEFI support has matured we're finding there are several issues around it as well where updating the ESP needs to be tied to updating /boot for the system to work sometimes. It has grown more complex over time, so we should separate. It's been a little weird on all the non x86 platforms to different degrees, but now that our main platform is affected it's become clear we may need to change. But we need to do so carefully as this violates POLA in a huge way, as well as needing doc changes in a bajillion places. Warner -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Mon Mar 25 18:34:56 2019 Return-Path: Delivered-To: freebsd-arch@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 26081154937F for ; Mon, 25 Mar 2019 18:34:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) 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 A9F5782245 for ; Mon, 25 Mar 2019 18:34:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 697D3154937D; Mon, 25 Mar 2019 18:34:55 +0000 (UTC) Delivered-To: arch@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 4471B154937C; Mon, 25 Mar 2019 18:34:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCD7482243; Mon, 25 Mar 2019 18:34:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id BFB34157B; Mon, 25 Mar 2019 18:34:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh , "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> Date: Mon, 25 Mar 2019 11:34:50 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: DCD7482243 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.962,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 18:34:56 -0000 On 3/25/19 8:05 AM, Warner Losh wrote: > We started installing /boot/loader with install world in FreeBSD -3.x and > it has affected the boot ability that whole time... in the early days of > loader, the kernel loader handoff protocol was immature enough to need a > matched kernel. But that period lasted only a few months... loader has > also been weird in other ways as well, since some embedded systems used the > one in its, while others needed an extra step. As UEFI support has matured > we're finding there are several issues around it as well where updating the > ESP needs to be tied to updating /boot for the system to work sometimes. It > has grown more complex over time, so we should separate. It's been a little > weird on all the non x86 platforms to different degrees, but now that our > main platform is affected it's become clear we may need to change. > > But we need to do so carefully as this violates POLA in a huge way, as well > as needing doc changes in a bajillion places. I think we should treat files on the ESP the same way we treat other boot blocks. installworld should continue to install the latest version into /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other tool is used by the user to copy the updated loader.efi into the ESP. I think the main difference here is that traditionally other boot blocks didn't change very often, so no one really needed to update it them post-install. loader.efi changes often enough we probably need to document updating the ESP as an optional step in the upgrade process. I think having an automagical script will probably go sideways, but standardizing where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means we can provide a script with defaults (or instructions) that work with the standardized approach. -- John Baldwin From owner-freebsd-arch@freebsd.org Mon Mar 25 19:27:37 2019 Return-Path: Delivered-To: freebsd-arch@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 EDDCD154AE71 for ; Mon, 25 Mar 2019 19:27:36 +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 4D2F58435D for ; Mon, 25 Mar 2019 19:27:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 06A17154AE6D; Mon, 25 Mar 2019 19:27:36 +0000 (UTC) Delivered-To: arch@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 C017B154AE6B for ; Mon, 25 Mar 2019 19:27:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61BA284359 for ; Mon, 25 Mar 2019 19:27:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x835.google.com with SMTP id w5so11692826qtb.11 for ; Mon, 25 Mar 2019 12:27:35 -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=TV9WE/1CHx0uhsY0wUvZtlzys+nMywFvBDp7zNPrPNE=; b=CZm3Dd1b604cnUQ3yKbfWheMaVY2PLefzAvRxRoyd+smLYXSJZVnEsY0JkCBGV5gJU JXEynvk55a3LVAZi/La9U5LM9TNpvo61WiqrYYFhevGJuhwgbjr5feIiGGqtmWLPoNJl EV2SZglhyLklCb9QRzDzIExY8tyiiv6fX7YpldOggMM2qDLOgLnF4sIbfULZvE8Pvgre wUzngHI4CmMV9nI6FBN3TRWabWK7+YZA9t0ewgR0sIkjPZgLX0akRp7vlg7o+jqqKrKi JmfMNaqjNalW198l7rqjQgdSDTN4f6wPtnXLIUuG5tii40Y9fWVyrp6uUPG7R/4cgBNS DrLg== 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=TV9WE/1CHx0uhsY0wUvZtlzys+nMywFvBDp7zNPrPNE=; b=VKEVcycKXJ8QbSF4KY/OIsWM/DiLrGTQRsCWMQYNzUYQJNMjrWdEAzRe18vq0vd+PV sxvb+90+0N0leXlHrZQAT/S+bzdLtTn8keZaU+m9s39O6mDeeSfANnz/2LjrXENj1jAR 5YfjPUjPnFqRkMtbIgJoOP3s0T61ExlQohi1ohqP/XtwOlDMx4JeOJQsPgu2zBQ3rSi3 +FzijIn3UmqG/j/syLXVeefVQpnqPEDpY/zJfJtOCoM5fSGcZPizReFK/5B9ICCQoDVE PQPJ+nMfCtbGXKvAza0b1GYsQujTyyXUNPLLT+rMAWL8JEDQfTnmHsCilUTwEz6PvR8V hTrw== X-Gm-Message-State: APjAAAUFjxQbRem39w2I8/mWVdraSBjDZegk93vHtQJuOBKMTfCjPEVH PoQvhwa9kSJR9FHcmJbZeb8JzhhdaNY4L9JToq10Nw== X-Google-Smtp-Source: APXvYqwVR8xULRC2s3FfaOQK7Yg3u/ufj4hCrX0Htgjzu+JFwhmHj25ukrTCBvqgh5sHx8yZ40Ux1F5TLCXMtkQlWjM= X-Received: by 2002:ac8:1aec:: with SMTP id h41mr21143132qtk.345.1553542054660; Mon, 25 Mar 2019 12:27:34 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: Warner Losh Date: Mon, 25 Mar 2019 13:27:21 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: John Baldwin Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: 61BA284359 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 19:27:37 -0000 On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > On 3/25/19 8:05 AM, Warner Losh wrote: > > We started installing /boot/loader with install world in FreeBSD -3.x and > > it has affected the boot ability that whole time... in the early days of > > loader, the kernel loader handoff protocol was immature enough to need a > > matched kernel. But that period lasted only a few months... loader has > > also been weird in other ways as well, since some embedded systems used > the > > one in its, while others needed an extra step. As UEFI support has > matured > > we're finding there are several issues around it as well where updating > the > > ESP needs to be tied to updating /boot for the system to work sometimes. > It > > has grown more complex over time, so we should separate. It's been a > little > > weird on all the non x86 platforms to different degrees, but now that our > > main platform is affected it's become clear we may need to change. > > > > But we need to do so carefully as this violates POLA in a huge way, as > well > > as needing doc changes in a bajillion places. > > I think we should treat files on the ESP the same way we treat other boot > blocks. installworld should continue to install the latest version into > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > tool is used by the user to copy the updated loader.efi into the ESP. > > I think the main difference here is that traditionally other boot blocks > didn't change very often, so no one really needed to update it them > post-install. loader.efi changes often enough we probably need to document > updating the ESP as an optional step in the upgrade process. I think > having an automagical script will probably go sideways, but standardizing > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > we can provide a script with defaults (or instructions) that work with > the standardized approach. > I think we need to have some automation in place. Something very specific and concrete. Otherwise we run the risk of updating the support files without updating loader.efi, possibly breaking boot if we wanted to add a new API to lua that the startup scripts call. Without an update of loader.efi, this generates an error. I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd as fair game to update. So there is some nuance here we need to take into account and avoid absolutes about the BSP. -- > John Baldwin > From owner-freebsd-arch@freebsd.org Mon Mar 25 20:30:16 2019 Return-Path: Delivered-To: freebsd-arch@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 077B3154CEC3 for ; Mon, 25 Mar 2019 20:30:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) 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 8DD32862F7 for ; Mon, 25 Mar 2019 20:30:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4C677154CEC1; Mon, 25 Mar 2019 20:30:15 +0000 (UTC) Delivered-To: arch@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 24DB2154CEC0; Mon, 25 Mar 2019 20:30:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B89C5862F1; Mon, 25 Mar 2019 20:30:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 562E92173; Mon, 25 Mar 2019 20:30:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 25 Mar 2019 13:30:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B89C5862F1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 20:30:16 -0000 On 3/25/19 12:27 PM, Warner Losh wrote: > On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > >> On 3/25/19 8:05 AM, Warner Losh wrote: >>> We started installing /boot/loader with install world in FreeBSD -3.x and >>> it has affected the boot ability that whole time... in the early days of >>> loader, the kernel loader handoff protocol was immature enough to need a >>> matched kernel. But that period lasted only a few months... loader has >>> also been weird in other ways as well, since some embedded systems used >> the >>> one in its, while others needed an extra step. As UEFI support has >> matured >>> we're finding there are several issues around it as well where updating >> the >>> ESP needs to be tied to updating /boot for the system to work sometimes. >> It >>> has grown more complex over time, so we should separate. It's been a >> little >>> weird on all the non x86 platforms to different degrees, but now that our >>> main platform is affected it's become clear we may need to change. >>> >>> But we need to do so carefully as this violates POLA in a huge way, as >> well >>> as needing doc changes in a bajillion places. >> >> I think we should treat files on the ESP the same way we treat other boot >> blocks. installworld should continue to install the latest version into >> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other >> tool is used by the user to copy the updated loader.efi into the ESP. >> >> I think the main difference here is that traditionally other boot blocks >> didn't change very often, so no one really needed to update it them >> post-install. loader.efi changes often enough we probably need to document >> updating the ESP as an optional step in the upgrade process. I think >> having an automagical script will probably go sideways, but standardizing >> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means >> we can provide a script with defaults (or instructions) that work with >> the standardized approach. >> > > I think we need to have some automation in place. Something very specific > and concrete. Otherwise we run the risk of updating the support files > without updating loader.efi, possibly breaking boot if we wanted to add a > new API to lua that the startup scripts call. Without an update of > loader.efi, this generates an error. > > I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd as > fair game to update. So there is some nuance here we need to take into > account and avoid absolutes about the BSP. Hmm, I guess we considered it a bad idea to store all the support scripts (not loader.conf, but all the 4th/lua) on the esp beside the loader? That would make the ESP bits be a self-contained, consistent snapshot. loader.efi could perhaps prefer to find those files on the partition it was loaded from (you know that IIRC since when you are executed as an EFI app you get a pointer to your Image and it has a backpointer to the device you came from I thought) before looking for them on the root filesystem? This would let it still work when boot1.efi lives on the ESP instead, and also in the case that you just copied loader.efi into the ESP without the support scripts. -- John Baldwin From owner-freebsd-arch@freebsd.org Mon Mar 25 20:41:31 2019 Return-Path: Delivered-To: freebsd-arch@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 0A3FD154D646 for ; Mon, 25 Mar 2019 20:41:31 +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 48B7186C95 for ; Mon, 25 Mar 2019 20:41:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0720A154D640; Mon, 25 Mar 2019 20:41:30 +0000 (UTC) Delivered-To: arch@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 D8DF8154D63F for ; Mon, 25 Mar 2019 20:41:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BB8D86C8F for ; Mon, 25 Mar 2019 20:41:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id c1so6260714qkk.4 for ; Mon, 25 Mar 2019 13:41:29 -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=QLkpG0JhvO0oH/Uv5/GxXzCVnUdEo3TcGGtNZrpnLeY=; b=yj6Z+Ar64xjzrNuoZjhKi9VM5NEGuR1Xt9yeZEKnQjFOsGwd1XpQJVn40rrE+HORrq Au5Ducf+YtctWYnRPMAHqvasZR3s2zNb3fDd5flV84kUViorm6/lNkCTtN4MGVcNhHJl bB1KH3Df1PXcNIG3ynJGSeIBi+Rb33oJT4iqwU4Pst9x0gjXKM9eCH1i5ed1q0K6pH2Z D59ZSTdEaG22NEOgys3YEWwzMyZhYE3u/yOnALeeLyHynKeUznqLL1L/l4el0HbSQG0O q44/MMpL+GK29y1UMGHGFN5P7hRGNf2XAB9PtGhsvNa6HVXqwFwl5C7GOmmXn6vmgZm5 fwQA== 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=QLkpG0JhvO0oH/Uv5/GxXzCVnUdEo3TcGGtNZrpnLeY=; b=oqGIjjot2sMAQO581HQCXtUPyASzX//UwKU18pW57aofDOPnvvnANTuupTlpMl1Cus 7mAoZm0i201yooYYrlrpCZSC2hkcU7Hs0OH7sG0VkQDcDlVoY7xymFR5Le/Fujgdz8cQ Gg3V3Um7rmFZO/Fkv19WxXAf3njJilpMFxkyELS9R1AOBmd/jKECEJMudULymGIT/f73 Jcoe48sS/kkvw0UTzX6mQt8Q2/q+fxNpNCvKM96Ju88Z7q6MABuO8NbGCrj5pL9bAM05 ESjYlKrhBcOZFm8hogaAMULnM4+p7iYWjCx8xlwIvUTwP13V8ELzgODzGOQskMrxxPe3 FMMA== X-Gm-Message-State: APjAAAULDwr1iqgk63usiaqdHXWUn07jwL3TDmo1dWRxZeypvndSYV84 XWHXAuwOKt78hFKY4Hty5V7PujtOT4BKLfC9RyCGwA== X-Google-Smtp-Source: APXvYqyTppDY8D8ZcN/rAYyiQccixLSWDC3zZgDIr1m02RFQUvp3WdFnE2vCpHXN1DGemD1bHwhFqpa5EayZOAHSEwU= X-Received: by 2002:a05:620a:132b:: with SMTP id p11mr21713731qkj.279.1553546488966; Mon, 25 Mar 2019 13:41:28 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Mon, 25 Mar 2019 14:41:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: John Baldwin Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: 7BB8D86C8F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 20:41:31 -0000 On Mon, Mar 25, 2019 at 2:30 PM John Baldwin wrote: > On 3/25/19 12:27 PM, Warner Losh wrote: > > On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > > > >> On 3/25/19 8:05 AM, Warner Losh wrote: > >>> We started installing /boot/loader with install world in FreeBSD -3.x > and > >>> it has affected the boot ability that whole time... in the early days > of > >>> loader, the kernel loader handoff protocol was immature enough to need > a > >>> matched kernel. But that period lasted only a few months... loader has > >>> also been weird in other ways as well, since some embedded systems used > >> the > >>> one in its, while others needed an extra step. As UEFI support has > >> matured > >>> we're finding there are several issues around it as well where updating > >> the > >>> ESP needs to be tied to updating /boot for the system to work > sometimes. > >> It > >>> has grown more complex over time, so we should separate. It's been a > >> little > >>> weird on all the non x86 platforms to different degrees, but now that > our > >>> main platform is affected it's become clear we may need to change. > >>> > >>> But we need to do so carefully as this violates POLA in a huge way, as > >> well > >>> as needing doc changes in a bajillion places. > >> > >> I think we should treat files on the ESP the same way we treat other > boot > >> blocks. installworld should continue to install the latest version into > >> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > other > >> tool is used by the user to copy the updated loader.efi into the ESP. > >> > >> I think the main difference here is that traditionally other boot blocks > >> didn't change very often, so no one really needed to update it them > >> post-install. loader.efi changes often enough we probably need to > document > >> updating the ESP as an optional step in the upgrade process. I think > >> having an automagical script will probably go sideways, but > standardizing > >> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > means > >> we can provide a script with defaults (or instructions) that work with > >> the standardized approach. > >> > > > > I think we need to have some automation in place. Something very specific > > and concrete. Otherwise we run the risk of updating the support files > > without updating loader.efi, possibly breaking boot if we wanted to add a > > new API to lua that the startup scripts call. Without an update of > > loader.efi, this generates an error. > > > > I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd > as > > fair game to update. So there is some nuance here we need to take into > > account and avoid absolutes about the BSP. > > Hmm, I guess we considered it a bad idea to store all the support scripts > (not loader.conf, but all the 4th/lua) on the esp beside the loader? That > would make the ESP bits be a self-contained, consistent snapshot. > loader.efi > could perhaps prefer to find those files on the partition it was loaded > from > (you know that IIRC since when you are executed as an EFI app you get a > pointer to your Image and it has a backpointer to the device you came from > I thought) before looking for them on the root filesystem? This would let > it still work when boot1.efi lives on the ESP instead, and also in the case > that you just copied loader.efi into the ESP without the support scripts. > Yea, now we're far into the weeds of dynamic design, and I'm not sure this is a good idea at all. Every time we've tried to pivot with a "just do X" it's burned us on this stuff. I hate the idea of just adding one ore layer of complexity as well, though to be honest, there may be some need to have some standardized fallback for the horrific UEFI implementations that are out there which are deficient in a number of ways that would lead us to needing some not uefi variable fallack mechanism. I'd hate to design that and then have another wart looking for this stuff, as well as users needing to do weird stuff to read in loader.conf and modifying it (more POLA violation if we move it to the ESP, for example). I've not had a chance to connect all the dots, but the few I've tried strong suggest this idea may not hunt. Let's step back and do a complete design doc. I've started writing one up and will post it when I'm done. Warner From owner-freebsd-arch@freebsd.org Mon Mar 25 21:02:02 2019 Return-Path: Delivered-To: freebsd-arch@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 66707154DEED for ; Mon, 25 Mar 2019 21:02:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) 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 E1AC1878B0 for ; Mon, 25 Mar 2019 21:02:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A4DA8154DEEA; Mon, 25 Mar 2019 21:02:01 +0000 (UTC) Delivered-To: arch@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 7D457154DEE9; Mon, 25 Mar 2019 21:02:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C9C4878AE; Mon, 25 Mar 2019 21:02:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2F74C25C8; Mon, 25 Mar 2019 21:02:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 25 Mar 2019 14:01:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 1C9C4878AE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 21:02:02 -0000 On 3/25/19 1:41 PM, Warner Losh wrote: > On Mon, Mar 25, 2019 at 2:30 PM John Baldwin wrote: > >> On 3/25/19 12:27 PM, Warner Losh wrote: >>> On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: >>> >>>> On 3/25/19 8:05 AM, Warner Losh wrote: >>>>> We started installing /boot/loader with install world in FreeBSD -3.x >> and >>>>> it has affected the boot ability that whole time... in the early days >> of >>>>> loader, the kernel loader handoff protocol was immature enough to need >> a >>>>> matched kernel. But that period lasted only a few months... loader has >>>>> also been weird in other ways as well, since some embedded systems used >>>> the >>>>> one in its, while others needed an extra step. As UEFI support has >>>> matured >>>>> we're finding there are several issues around it as well where updating >>>> the >>>>> ESP needs to be tied to updating /boot for the system to work >> sometimes. >>>> It >>>>> has grown more complex over time, so we should separate. It's been a >>>> little >>>>> weird on all the non x86 platforms to different degrees, but now that >> our >>>>> main platform is affected it's become clear we may need to change. >>>>> >>>>> But we need to do so carefully as this violates POLA in a huge way, as >>>> well >>>>> as needing doc changes in a bajillion places. >>>> >>>> I think we should treat files on the ESP the same way we treat other >> boot >>>> blocks. installworld should continue to install the latest version into >>>> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some >> other >>>> tool is used by the user to copy the updated loader.efi into the ESP. >>>> >>>> I think the main difference here is that traditionally other boot blocks >>>> didn't change very often, so no one really needed to update it them >>>> post-install. loader.efi changes often enough we probably need to >> document >>>> updating the ESP as an optional step in the upgrade process. I think >>>> having an automagical script will probably go sideways, but >> standardizing >>>> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) >> means >>>> we can provide a script with defaults (or instructions) that work with >>>> the standardized approach. >>>> >>> >>> I think we need to have some automation in place. Something very specific >>> and concrete. Otherwise we run the risk of updating the support files >>> without updating loader.efi, possibly breaking boot if we wanted to add a >>> new API to lua that the startup scripts call. Without an update of >>> loader.efi, this generates an error. >>> >>> I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd >> as >>> fair game to update. So there is some nuance here we need to take into >>> account and avoid absolutes about the BSP. >> >> Hmm, I guess we considered it a bad idea to store all the support scripts >> (not loader.conf, but all the 4th/lua) on the esp beside the loader? That >> would make the ESP bits be a self-contained, consistent snapshot. >> loader.efi >> could perhaps prefer to find those files on the partition it was loaded >> from >> (you know that IIRC since when you are executed as an EFI app you get a >> pointer to your Image and it has a backpointer to the device you came from >> I thought) before looking for them on the root filesystem? This would let >> it still work when boot1.efi lives on the ESP instead, and also in the case >> that you just copied loader.efi into the ESP without the support scripts. >> > > Yea, now we're far into the weeds of dynamic design, and I'm not sure this > is a good idea at all. Every time we've tried to pivot with a "just do X" > it's burned us on this stuff. I hate the idea of just adding one ore layer > of complexity as well, though to be honest, there may be some need to have > some standardized fallback for the horrific UEFI implementations that are > out there which are deficient in a number of ways that would lead us to > needing some not uefi variable fallack mechanism. I'd hate to design that > and then have another wart looking for this stuff, as well as users needing > to do weird stuff to read in loader.conf and modifying it (more POLA > violation if we move it to the ESP, for example). I've not had a chance to > connect all the dots, but the few I've tried strong suggest this idea may > not hunt. > > Let's step back and do a complete design doc. I've started writing one up > and will post it when I'm done. I think a design doc makes sense. FWIW, I was only suggesting that the support scripts and perhaps /boot/defaults be on the ESP, but the actual loader.conf would still only be read from the rootfs. Right now loader has two special variables: currdev and rootdev. You could imagine a 'bootdev' and that for certain path lookups we try bootdev before currdev, but still fall back to currdev if the open on bootdev fails. But I think it's worth stepping back and walking through the design. My point about installworld is that today it is pretty straight forward what it means in terms of just installing files into / and that works fine for cross-release installs via DESTDIR, etc. Updating the ESP seems to be a bit more fraught with peril such that I'm not really sure I want installworld to try to do that vs having a separate step. The thought about having the "support scripts" live on the ESP is an orthogonal point about trying to have the loader be self-contained when it lives on the ESP. In this case I think of self-contained as being "what are the things equivalent to shared libraries that it needs to run", but not user-editable config files like loader.conf. -- John Baldwin From owner-freebsd-arch@freebsd.org Tue Mar 26 00:40:56 2019 Return-Path: Delivered-To: freebsd-arch@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 ACCC415526C4 for ; Tue, 26 Mar 2019 00:40:56 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 B75F88E522 for ; Tue, 26 Mar 2019 00:40:55 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7158715526C1; Tue, 26 Mar 2019 00:40:55 +0000 (UTC) Delivered-To: arch@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 5E3DD15526C0; Tue, 26 Mar 2019 00:40:55 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED4108E51E; Tue, 26 Mar 2019 00:40:54 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id E2320C1909; Mon, 25 Mar 2019 18:41:49 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id u_ayBvyt48qT; Mon, 25 Mar 2019 18:41:49 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Mon, 25 Mar 2019 18:41:49 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh , John Baldwin Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: Rebecca Cran Message-ID: Date: Mon, 25 Mar 2019 18:40:46 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: ED4108E51E X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.948,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 00:40:56 -0000 On 3/25/19 2:41 PM, Warner Losh wrote: > > Let's step back and do a complete design doc. I've started writing one up > and will post it when I'm done. It's probably worth at least taking a look at what Linux has done to support UEFI, Secure Boot, and its Default Boot Behavior (https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/) to see if there's anything we can learn, or leverage. Also, the shim (https://github.com/rhboot/shim) is BSD licensed, so we could use it if we wanted. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Tue Mar 26 02:08:15 2019 Return-Path: Delivered-To: freebsd-arch@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 5E3E81557FED for ; Tue, 26 Mar 2019 02:08:15 +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 9B3E36C37B for ; Tue, 26 Mar 2019 02:08:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5F1A51557FE3; Tue, 26 Mar 2019 02:08:14 +0000 (UTC) Delivered-To: arch@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 3AEDC1557FE2 for ; Tue, 26 Mar 2019 02:08:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC31B6C379 for ; Tue, 26 Mar 2019 02:08:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id v32so12811869qtc.10 for ; Mon, 25 Mar 2019 19:08:13 -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=ZnlBkrnu7i/35TUdewrxFDbP3xlajBNaP8swvQIpO0E=; b=qYcig7+12MxIMCGSYnRiYVW0vQyikfIZNGzzDKGxzn99WunkxIZvTSpQbczq/GcwyH K0eHIIVmWAtsRrWTIb+1v+wxzgoTg/b3/WuPlTmc05bffLdbseguAUM8Wbkq57BzlCRP Of8MQamvQ8Lb2VvnGO2tKtlAaScXFjdWG4l8/E/fnBTZifzDjbdUkVZR3k4PbonIQY8Z EvIwpnva4eUFN4uDA+3pns4qYQw8M1l97kdM2mcj3jEI5DTCDMrXRqLOlAf9y5louoiF Mn4CqkuTOY3uzFItmKztSrO9V0ofEkQqAQv47gtq1i3moH+9axBjqLqqRBZPUb43/MYz 4/5A== 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=ZnlBkrnu7i/35TUdewrxFDbP3xlajBNaP8swvQIpO0E=; b=fcE4PNdTI+UPlL46jEztPoj+k9W2fL9uuCdcfjgbuUgUo6V+MbIP9uTm7aZkN9DU0r FQj3Ch3gxrRxRM3e23BpXzDdpSCajGJ8WmD3WY6O7gybrQN0FVe178z7xX9K7YKeHwXP tLp1NI/YnelcxeOE4z3APz72X2O3TjaxgfdTaX5YUsRO6OcR9ytN1DMggHe6ahHgRxrF n98+GTe5WkLur5E7WUMSGwDSF1kuSrFCu3xn5Hn9kYiHBqFblEDWF6jzEpB/pq7PdGcs NwcfY9ABbvzgleZYCX+uemTO7RiJO0Pu2liDPPkgIfsVrue6BwH4oj/8z81Bg8eaeebV KmBA== X-Gm-Message-State: APjAAAV++WtB5aQavbaDru+/xd2jW+aP/1tEoypBtp6IAuuoFInvtRX8 APbZuQcQBHafW3vip1jofA/xLmaw2Tl/iIQio2hflQ== X-Google-Smtp-Source: APXvYqyVEaSk++sDoCSkhPCKOxxRrOp+SCmm8Kv1ru3m3j14kJQesDmrzkFHL4JK+HlyRB0od1mFH07SKZHRN76nUU8= X-Received: by 2002:ac8:28d0:: with SMTP id j16mr23881750qtj.15.1553566093181; Mon, 25 Mar 2019 19:08:13 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Mon, 25 Mar 2019 20:08:01 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: John Baldwin , Konstantin Belousov , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers X-Rspamd-Queue-Id: CC31B6C379 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 02:08:15 -0000 On Mon, Mar 25, 2019, 6:40 PM Rebecca Cran wrote: > On 3/25/19 2:41 PM, Warner Losh wrote: > > > > > Let's step back and do a complete design doc. I've started writing one up > > and will post it when I'm done. > > > It's probably worth at least taking a look at what Linux has done to > support UEFI, Secure Boot, and its Default Boot Behavior > (https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/) > > to see if there's anything we can learn, or leverage. Also, the shim > (https://github.com/rhboot/shim) is BSD licensed, so we could use it if > we wanted. > We started moving away from boot1.efi because it was duplicating all the features of loader.efi, but without the interactive features. Different filesystems, crypto, boot order details, etc. It was a pita to maintain two similar things with different enough details :( this starts to move back to that, and I'm not sure that is a good idea. It seemed like the right choice, but maybe we could consider taking another look at that... when it first arrived, boot1.efi could easily fit the install once and forget forever. As the features grew, that assumption changed. This is why I'm putting together a design doc. There is no easy button here. I thought it was no brainer yes to drop it and just use loader.efi, but as things get more complicated I've become less sure... Warner > -- > > Rebecca Cran > > From owner-freebsd-arch@freebsd.org Tue Mar 26 03:45:06 2019 Return-Path: Delivered-To: freebsd-arch@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 0B9DD155FA15 for ; Tue, 26 Mar 2019 03:45:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 0D4A0722BB for ; Tue, 26 Mar 2019 03:45:05 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id C1560155FA12; Tue, 26 Mar 2019 03:45:04 +0000 (UTC) Delivered-To: arch@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 9BE0E155FA11; Tue, 26 Mar 2019 03:45:04 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B220722BA; Tue, 26 Mar 2019 03:45:03 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q3ipRQ082842; Mon, 25 Mar 2019 20:44:51 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q3iolq082841; Mon, 25 Mar 2019 20:44:50 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260344.x2Q3iolq082841@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 20:44:50 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 0B220722BA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.978,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 03:45:06 -0000 > On Mon, Mar 25, 2019, 3:28 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via > > freebsd-hackers wrote: > > > > I've been working on EFI support, and have a review > > > > (https://reviews.freebsd.org/D19588) to add a script, > > efi-update-loader, > > > > which will update the ESP containing the FreeBSD boot1.efi or > > loader.efi. > > > > > > > > I'd like to integrate it into the build system so it gets run when > > users > > > > do a "make installworld", but I'm lost looking through Makefile.inc1 - > > I > > > > have no clue where to add the code. > > > > > > > > Does anyone understand where and what to add? > > > > > > Can we take use of the opportunity and finally stop installing loader > > > at installworld target at all, please ? > > > > > > Add e.g. installloader target which would do whatever needed to loader. > > > > +1 boot code and loaders should always be seperated from the > > install target. Historically this was casued by the fact that > > the boot code and loader lived outside the file system and > > required operations beyond updating /usr/mdec (very ancient) > > or /boot/boot* (historical). Now that /boot/loader* is an > > immeditate effect on the bootability of the system it makes > > since to seperate this from the installworld target. > > > > We started installing /boot/loader with install world in FreeBSD -3.x and > it has affected the boot ability that whole time... in the early days of > loader, the kernel loader handoff protocol was immature enough to need a > matched kernel. But that period lasted only a few months... loader has > also been weird in other ways as well, since some embedded systems used the > one in its, while others needed an extra step. As UEFI support has matured > we're finding there are several issues around it as well where updating the > ESP needs to be tied to updating /boot for the system to work sometimes. It > has grown more complex over time, so we should separate. It's been a little > weird on all the non x86 platforms to different degrees, but now that our > main platform is affected it's become clear we may need to change. > > But we need to do so carefully as this violates POLA in a huge way, as well > as needing doc changes in a bajillion places. So it appears we agree, we sould do this, and we need to wear Nomex clothing while doing so as it is an easy place to get burned badly if we do not end up with a good set of tooling, or make mistakes along the way. > Warner > > Rod Grimes -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Tue Mar 26 03:48:30 2019 Return-Path: Delivered-To: freebsd-arch@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 BE3E0155FCB8 for ; Tue, 26 Mar 2019 03:48:30 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 427C0725BA for ; Tue, 26 Mar 2019 03:48:30 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 02ADE155FCB7; Tue, 26 Mar 2019 03:48:30 +0000 (UTC) Delivered-To: arch@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 E42AB155FCB6 for ; Tue, 26 Mar 2019 03:48:29 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F4CD725B1; Tue, 26 Mar 2019 03:48:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q3mFed082867; Mon, 25 Mar 2019 20:48:15 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q3mFEg082866; Mon, 25 Mar 2019 20:48:15 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> To: John Baldwin Date: Mon, 25 Mar 2019 20:48:15 -0700 (PDT) CC: Warner Losh , "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 1F4CD725B1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 03:48:31 -0000 > On 3/25/19 8:05 AM, Warner Losh wrote: > > We started installing /boot/loader with install world in FreeBSD -3.x and > > it has affected the boot ability that whole time... in the early days of > > loader, the kernel loader handoff protocol was immature enough to need a > > matched kernel. But that period lasted only a few months... loader has > > also been weird in other ways as well, since some embedded systems used the > > one in its, while others needed an extra step. As UEFI support has matured > > we're finding there are several issues around it as well where updating the > > ESP needs to be tied to updating /boot for the system to work sometimes. It > > has grown more complex over time, so we should separate. It's been a little > > weird on all the non x86 platforms to different degrees, but now that our > > main platform is affected it's become clear we may need to change. > > > > But we need to do so carefully as this violates POLA in a huge way, as well > > as needing doc changes in a bajillion places. > > I think we should treat files on the ESP the same way we treat other boot > blocks. installworld should continue to install the latest version into > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > tool is used by the user to copy the updated loader.efi into the ESP. > > I think the main difference here is that traditionally other boot blocks > didn't change very often, so no one really needed to update it them > post-install. loader.efi changes often enough we probably need to document > updating the ESP as an optional step in the upgrade process. I think > having an automagical script will probably go sideways, but standardizing > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > we can provide a script with defaults (or instructions) that work with > the standardized approach. Is there anyway to stash an easy to extract "version" in loader.* so that a Makefile/.sh script could easily check to see that your boot code is == `uname -KU` and just emit a warning at the end of installworld? > John Baldwin -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Tue Mar 26 04:08:45 2019 Return-Path: Delivered-To: freebsd-arch@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 91CC0156097D for ; Tue, 26 Mar 2019 04:08:45 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 CA4A0732B5 for ; Tue, 26 Mar 2019 04:08:44 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 88DB6156097A; Tue, 26 Mar 2019 04:08:44 +0000 (UTC) Delivered-To: arch@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 6637C1560979; Tue, 26 Mar 2019 04:08:44 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01F1F732B2; Tue, 26 Mar 2019 04:08:43 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 13AC9C1ABD; Mon, 25 Mar 2019 22:09:44 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YkMn-4QDMSM8; Mon, 25 Mar 2019 22:09:43 -0600 (MDT) Received: from [10.0.10.197] (unknown [65.103.231.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Mon, 25 Mar 2019 22:09:43 -0600 (MDT) Date: Mon, 25 Mar 2019 22:03:46 -0600 From: rebecca@bluestop.org To: John Baldwin , "Rodney W. Grimes" Cc: FreeBSD Hackers , "=?utf-8?Q?freebsd-arch=40freebsd.org?=" , Konstantin Belousov Message-ID: <3abca0c1-3681-43a5-af21-5a89c8764d0c@Spark> In-Reply-To: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> References: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" X-Readdle-Message-ID: 3abca0c1-3681-43a5-af21-5a89c8764d0c@Spark MIME-Version: 1.0 X-Rspamd-Queue-Id: 01F1F732B2 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 04:08:45 -0000 On Mar 25, 2019, 9:49 PM -0600, Rodney W. Grimes , wrote: > > Is there anyway to stash an easy to extract =22version=22 in > loader.* so that a Makefile/.sh script could easily check > to see that your boot code is =3D=3D =60uname -KU=60 and just emit > a warning at the end of installworld=3F Currently, one of the strings that are embedded in loader*.efi reports th= e loader version 1.1. Though we might want to have something like Linux=E2= =80=99 boot.csv with a version in that file. Rebecca From owner-freebsd-arch@freebsd.org Tue Mar 26 04:10:24 2019 Return-Path: Delivered-To: freebsd-arch@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 666561560AFD for ; Tue, 26 Mar 2019 04:10:24 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail03.asahi-net.or.jp (mail03.asahi-net.or.jp [202.224.55.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAA9733DA for ; Tue, 26 Mar 2019 04:10:21 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from rv515.advok.com (pool-72-76-119-135.nwrknj.fios.verizon.net [72.76.119.135]) (Authenticated sender: NR2Y-OOT) by mail03.asahi-net.or.jp (Postfix) with ESMTPSA id 949B737C9F; Tue, 26 Mar 2019 13:10:10 +0900 (JST) Date: Tue, 26 Mar 2019 00:09:56 -0400 From: Yoshihiro Ota To: freebsd-arch@freebsd.org Cc: ota@j.email.ne.jp Subject: Trying to upgrade zlib in kernel Message-Id: <20190326000956.83bd72411661511656ea1b5d@j.email.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i386-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7BAA9733DA X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 202.224.55.15 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp X-Spamd-Result: default: False [-1.68 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[15.55.224.202.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:202.224.55.0/24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[email.ne.jp]; NEURAL_SPAM_SHORT(0.07)[0.075,0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; RECEIVED_SPAMHAUS_PBL(0.00)[135.119.76.72.zen.spamhaus.org : 127.0.0.10]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[sbmx.asahi-net.or.jp]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.93)[-0.934,0]; IP_SCORE(-0.01)[country: JP(-0.07)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4685, ipnet:202.224.32.0/19, country:JP]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 04:10:24 -0000 Hello, Our zlib in kernel has been quite out-dated. I looked in and started updating. I use contrib/zlib files and sys/contrib/zstd to compile zlib with least amount of changes to zlib side. I split crc32 functions and also added few compile options to distinguish zlib calls. I have to relocate current one as netgraph uses FreeBSD specific implementation. I started wondering if I should move contrib/zlib to sys/contrib/zlib and wanted to get some feed back on some of coding policies. I created https://reviews.freebsd.org/D19706, and noted in new sys/sys/zlib.h: /* * #1 - sys/crc32.h is split out of sys/libkern.h to avoid conflicts * between zlib's crc32 and system crc32. * #2 - Use contrib/zstd/lib/freebsd's stdlib compatible includes. * #3 - ZLIB_C is created con/kern.pre.mk to share compile paths. * -I contrib/zlib * -I sys/contrib/zstd/lib/freebsd * #4 - sys/zlib.h defines these. * Z_PREIFX * NO_GZIP * Z_SOLO - this is for libkern/zlib.c and not needed for clients of zlib. * #5 - opencryptodeflate.c * zfs.state->dummy is an address and doesn't seem to be useful. * Its DTRACE probe is removed. * #6 - netgraph/deflate.c needs and uses FreeBSD enhancements to zlib. * Moved sys/zlib.h to netgraph/zlib.h, sys/libkern/zlib.c to * netgraph/zlib.c, and netgraph/deflate.c includes netgraph/zlib.c * to compile as a part of deflate.c. */ Regards, Hiro From owner-freebsd-arch@freebsd.org Tue Mar 26 04:58:07 2019 Return-Path: Delivered-To: freebsd-arch@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 86A881562A80 for ; Tue, 26 Mar 2019 04:58:07 +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 DD091756DF for ; Tue, 26 Mar 2019 04:58:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id A05F31562A7D; Tue, 26 Mar 2019 04:58:06 +0000 (UTC) Delivered-To: arch@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 7AB1E1562A7B for ; Tue, 26 Mar 2019 04:58:06 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DD96756DC for ; Tue, 26 Mar 2019 04:58:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id v32so13108714qtc.10 for ; Mon, 25 Mar 2019 21:58:06 -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=a67+bSvzKlmkEKTaFgxjooU1ufiuKiUj9IubDgqW8zM=; b=W4sApfGa/Go/PRLdi0Q3E1T4cUD6SVkdM0riskSO1XVWDMlw4z1f8wIpUAj0VgtxPq NiHLhXad3HuZn0vDYwwYiLN75+Uiwfysh65GbSNHvbXJCk3z9WQZEOdv4D6NzimVrFbq aLNLPxBbuWAUhbwqnx49dwG8G5ysNlFicw3BKoebBFNVm5J22i9HQD8D8awyYMCE2Fd1 0lFx6iTclIzd2PIx20zZkUq/q/wFwbd5GhmWkCWkHsMz+pNjov44VHbw/F7mfVBTk2my Nn8L+TGkNVfc56NEvrRWh3dZ3vthDrTMb1nVmpVpXSJYQa+vPXyD4LpNnIIpzl6cQtAf gb+w== 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=a67+bSvzKlmkEKTaFgxjooU1ufiuKiUj9IubDgqW8zM=; b=DO2PWWUvl+Hl4MkGsFTg6yVu5qZbCrg9uKfxRumWEhAkvaYZAHXqI7avOsAm9tMBz9 8KaEvZUtEz8LpB8T5x42KeOY6oCuXXW9pv4JySOum6Q61vxbOY2BMaHu37vncKFdrqOz /HCpdRMpq2qq3LpWOG0b7165peLgTFjrFx2fgroh8N9T7DWyRGblewfNnOPms0Xrd0dx jFD1rscjqSrtniwSdvPaLmkf/UOpTczkPcJEvhIPESOWSWzxVx9uv5t3Q3Pa4/nSzCm4 q2uuc9ekqwuz8I+buOx8LnYsa+JVAslyKcGSejTyMD0N1OicRZ3HHqqN+8GAgu/u7MLV YxFg== X-Gm-Message-State: APjAAAUoq3xKxXqMXlmBLcon6E7xsmOXbUfHXwrRbda8idV76RNjqxDJ vi0ZryOO4DKW9yeCCqhSRZx4QB6l9FvsYPYty3nc3w== X-Google-Smtp-Source: APXvYqzl2kwbYxTQ7T8G+O0F7RSD622lpyiZn1k6YYrQ/GTeCpMNikbqKqQBa7NWJx1at5sTD8iiXyS6suy7ZSrWyMU= X-Received: by 2002:a0c:b501:: with SMTP id d1mr24240075qve.115.1553576285641; Mon, 25 Mar 2019 21:58:05 -0700 (PDT) MIME-Version: 1.0 References: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> In-Reply-To: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 25 Mar 2019 22:57:53 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: John Baldwin , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: 1DD96756DC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 04:58:07 -0000 On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > We started installing /boot/loader with install world in FreeBSD -3.x > and > > > it has affected the boot ability that whole time... in the early days > of > > > loader, the kernel loader handoff protocol was immature enough to need > a > > > matched kernel. But that period lasted only a few months... loader has > > > also been weird in other ways as well, since some embedded systems > used the > > > one in its, while others needed an extra step. As UEFI support has > matured > > > we're finding there are several issues around it as well where > updating the > > > ESP needs to be tied to updating /boot for the system to work > sometimes. It > > > has grown more complex over time, so we should separate. It's been a > little > > > weird on all the non x86 platforms to different degrees, but now that > our > > > main platform is affected it's become clear we may need to change. > > > > > > But we need to do so carefully as this violates POLA in a huge way, as > well > > > as needing doc changes in a bajillion places. > > > > I think we should treat files on the ESP the same way we treat other boot > > blocks. installworld should continue to install the latest version into > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > I think the main difference here is that traditionally other boot blocks > > didn't change very often, so no one really needed to update it them > > post-install. loader.efi changes often enough we probably need to > document > > updating the ESP as an optional step in the upgrade process. I think > > having an automagical script will probably go sideways, but standardizing > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > > we can provide a script with defaults (or instructions) that work with > > the standardized approach. > > Is there anyway to stash an easy to extract "version" in > loader.* so that a Makefile/.sh script could easily check > to see that your boot code is == `uname -KU` and just emit > a warning at the end of installworld? > No. There is no simple version we can check to make sure things are a matched set.. Warner > John Baldwin > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-arch@freebsd.org Tue Mar 26 05:03:43 2019 Return-Path: Delivered-To: freebsd-arch@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 B8CEB1562FA4 for ; Tue, 26 Mar 2019 05:03:43 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 226A275CC3 for ; Tue, 26 Mar 2019 05:03:43 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id D5AFA1562FA1; Tue, 26 Mar 2019 05:03:42 +0000 (UTC) Delivered-To: arch@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 95D181562FA0; Tue, 26 Mar 2019 05:03:42 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C01475CC0; Tue, 26 Mar 2019 05:03:41 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q53Y3k083257; Mon, 25 Mar 2019 22:03:34 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q53Ydo083256; Mon, 25 Mar 2019 22:03:34 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 22:03:34 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 0C01475CC0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 05:03:44 -0000 > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > We started installing /boot/loader with install world in FreeBSD -3.x > > and > > > > it has affected the boot ability that whole time... in the early days > > of > > > > loader, the kernel loader handoff protocol was immature enough to need > > a > > > > matched kernel. But that period lasted only a few months... loader has > > > > also been weird in other ways as well, since some embedded systems > > used the > > > > one in its, while others needed an extra step. As UEFI support has > > matured > > > > we're finding there are several issues around it as well where > > updating the > > > > ESP needs to be tied to updating /boot for the system to work > > sometimes. It > > > > has grown more complex over time, so we should separate. It's been a > > little > > > > weird on all the non x86 platforms to different degrees, but now that > > our > > > > main platform is affected it's become clear we may need to change. > > > > > > > > But we need to do so carefully as this violates POLA in a huge way, as > > well > > > > as needing doc changes in a bajillion places. > > > > > > I think we should treat files on the ESP the same way we treat other boot > > > blocks. installworld should continue to install the latest version into > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > I think the main difference here is that traditionally other boot blocks > > > didn't change very often, so no one really needed to update it them > > > post-install. loader.efi changes often enough we probably need to > > document > > > updating the ESP as an optional step in the upgrade process. I think > > > having an automagical script will probably go sideways, but standardizing > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > > > we can provide a script with defaults (or instructions) that work with > > > the standardized approach. > > > > Is there anyway to stash an easy to extract "version" in > > loader.* so that a Makefile/.sh script could easily check > > to see that your boot code is == `uname -KU` and just emit > > a warning at the end of installworld? > > > > No. There is no simple version we can check to make sure things are a > matched set.. Then I would call that a pretty fatal flaw in design. There needs to be a way to find out what version of "loader" /boot/loader.efi is there. I was also not asking if we have a way now, I was asking if there was a way to implement, and I doubt the answer to that question is no. > Warner > > John Baldwin > > Rod Grimes rgrimes@freebsd.org 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 Why does your mail client wrap my <70 column signature? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Tue Mar 26 05:22:17 2019 Return-Path: Delivered-To: freebsd-arch@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 A38FF15637E1 for ; Tue, 26 Mar 2019 05:22:17 +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 20EDD76787 for ; Tue, 26 Mar 2019 05:22:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id D3E0D15637DF; Tue, 26 Mar 2019 05:22:16 +0000 (UTC) Delivered-To: arch@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 AFB6515637DE for ; Tue, 26 Mar 2019 05:22:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3828376784 for ; Tue, 26 Mar 2019 05:22:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id x12so13171093qts.7 for ; Mon, 25 Mar 2019 22:22:16 -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=X6ZvhkB9+6S+YCbihFHP420W7UtaeGi612fLw1q7tR0=; b=IPHpogiLpTYksb8JDQALhLstJ5DvUpywNAQr3oiIxGenvlm+xCOLrGo2pOEfH3j8Ce 5I3DWZ719yPUVSuyD8oZG73FxYLJ8YLdBhKnu8+0iXQW69Eui6qGoTmBLfBtbIJjLQwg BcFN44sZhtqwwShtiD8yPdO90puwWzEXES9W4ov52//EsPhCL3Cgmrf++ANFOnEjWOt6 GLxzFMEjl45qci2YYNVZq7brzr1btDWo0ZuVXGkA6wGknDjkNd+y5A9HV1TZoV1ws2Dm T4cwjMUUWY7aMZrIY0oYqxQdGrDN9ROENMc6SI/QVwQATIg1nsdGJCwgfTOGoFeFgecz yULw== 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=X6ZvhkB9+6S+YCbihFHP420W7UtaeGi612fLw1q7tR0=; b=ISbxLj6omdPeuNoVDpG1yYg2ahCuB21Y4iql+DpUEHgHTdlgrctrmVQKfRrqiOU3WH vaCfG6t3vhxqwBq3BnMLjNdGH0Y82Mkrm8bB4d4AbxXHgBEcuFfHRWWgRVwgLzOBYBr0 S2KECpIZApaDD+9WBCnajEcTyjhfGVzDEMVwTE6b05a1UlGrM7QTAf6qHM5aucNCTBcn JansFPtYNto6IM+OeIpREDPYcMgC4ED43cb54kIRMgx4NZ57fkMVlW441pv0E6nbeUaH u2vXxvSM/Ayy6ozm5bY92PeH4ZZd13CtvfDLjhBteuTCF9/fBCGBtPbSIMLkC05xcSMn 5J/g== X-Gm-Message-State: APjAAAW2aZR4ep0qK/3lZn8Ozr0RwlLiFfrLuagY5GkrX0h+iWYHX+qx /9hhd6eR/zUH0ktYLYIzucQsB7hMilybPi+agZBgEw== X-Google-Smtp-Source: APXvYqwd/33WqVXC3c/4hwUUnHuZZP+g4pEcbdAc8zGnzTp6dluOViAdJ4PkD/2Y865M91b1KD3i0Xjty8b0Fjkt6XM= X-Received: by 2002:a0c:9ba7:: with SMTP id o39mr23057951qve.153.1553577735560; Mon, 25 Mar 2019 22:22:15 -0700 (PDT) MIME-Version: 1.0 References: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> In-Reply-To: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 25 Mar 2019 23:22:03 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Rspamd-Queue-Id: 3828376784 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 05:22:17 -0000 On Mon, Mar 25, 2019, 11:03 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > > We started installing /boot/loader with install world in FreeBSD > -3.x > > > and > > > > > it has affected the boot ability that whole time... in the early > days > > > of > > > > > loader, the kernel loader handoff protocol was immature enough to > need > > > a > > > > > matched kernel. But that period lasted only a few months... > loader has > > > > > also been weird in other ways as well, since some embedded systems > > > used the > > > > > one in its, while others needed an extra step. As UEFI support has > > > matured > > > > > we're finding there are several issues around it as well where > > > updating the > > > > > ESP needs to be tied to updating /boot for the system to work > > > sometimes. It > > > > > has grown more complex over time, so we should separate. It's been > a > > > little > > > > > weird on all the non x86 platforms to different degrees, but now > that > > > our > > > > > main platform is affected it's become clear we may need to change. > > > > > > > > > > But we need to do so carefully as this violates POLA in a huge > way, as > > > well > > > > > as needing doc changes in a bajillion places. > > > > > > > > I think we should treat files on the ESP the same way we treat other > boot > > > > blocks. installworld should continue to install the latest version > into > > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > other > > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > > > I think the main difference here is that traditionally other boot > blocks > > > > didn't change very often, so no one really needed to update it them > > > > post-install. loader.efi changes often enough we probably need to > > > document > > > > updating the ESP as an optional step in the upgrade process. I think > > > > having an automagical script will probably go sideways, but > standardizing > > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > means > > > > we can provide a script with defaults (or instructions) that work > with > > > > the standardized approach. > > > > > > Is there anyway to stash an easy to extract "version" in > > > loader.* so that a Makefile/.sh script could easily check > > > to see that your boot code is == `uname -KU` and just emit > > > a warning at the end of installworld? > > > > > > > No. There is no simple version we can check to make sure things are a > > matched set.. > > Then I would call that a pretty fatal flaw in design. There needs > to be a way to find out what version of "loader" /boot/loader.efi > is there. > > I was also not asking if we have a way now, I was asking if there > was a way to implement, and I doubt the answer to that question is > no. > I know. We've not needed it before, and I'm having trouble seeing it now how it is connected to uname -UK. The path forward isn't DWIM. There are too many variables. Without DWIM requirements, a tight, buttoned up version isn't needed. Warner > Warner > > > John Baldwin > > > Rod Grimes rgrimes@freebsd.org > > > 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 > Why does your mail client wrap my <70 column signature? > Ask Google. Warner > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-arch@freebsd.org Tue Mar 26 06:21:11 2019 Return-Path: Delivered-To: freebsd-arch@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 219951565798 for ; Tue, 26 Mar 2019 06:21:11 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 821298074D for ; Tue, 26 Mar 2019 06:21:10 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 433291565792; Tue, 26 Mar 2019 06:21:10 +0000 (UTC) Delivered-To: arch@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 1E57E1565791; Tue, 26 Mar 2019 06:21:10 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C86580748; Tue, 26 Mar 2019 06:21:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q6L4AS083616; Mon, 25 Mar 2019 23:21:04 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q6L4x7083615; Mon, 25 Mar 2019 23:21:04 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 23:21:04 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 5C86580748 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 06:21:11 -0000 > On Mon, Mar 25, 2019, 11:03 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > > > We started installing /boot/loader with install world in FreeBSD > > -3.x > > > > and > > > > > > it has affected the boot ability that whole time... in the early > > days > > > > of > > > > > > loader, the kernel loader handoff protocol was immature enough to > > need > > > > a > > > > > > matched kernel. But that period lasted only a few months... > > loader has > > > > > > also been weird in other ways as well, since some embedded systems > > > > used the > > > > > > one in its, while others needed an extra step. As UEFI support has > > > > matured > > > > > > we're finding there are several issues around it as well where > > > > updating the > > > > > > ESP needs to be tied to updating /boot for the system to work > > > > sometimes. It > > > > > > has grown more complex over time, so we should separate. It's been > > a > > > > little > > > > > > weird on all the non x86 platforms to different degrees, but now > > that > > > > our > > > > > > main platform is affected it's become clear we may need to change. > > > > > > > > > > > > But we need to do so carefully as this violates POLA in a huge > > way, as > > > > well > > > > > > as needing doc changes in a bajillion places. > > > > > > > > > > I think we should treat files on the ESP the same way we treat other > > boot > > > > > blocks. installworld should continue to install the latest version > > into > > > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > > other > > > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > > > > > I think the main difference here is that traditionally other boot > > blocks > > > > > didn't change very often, so no one really needed to update it them > > > > > post-install. loader.efi changes often enough we probably need to > > > > document > > > > > updating the ESP as an optional step in the upgrade process. I think > > > > > having an automagical script will probably go sideways, but > > standardizing > > > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > > means > > > > > we can provide a script with defaults (or instructions) that work > > with > > > > > the standardized approach. > > > > > > > > Is there anyway to stash an easy to extract "version" in > > > > loader.* so that a Makefile/.sh script could easily check > > > > to see that your boot code is == `uname -KU` and just emit > > > > a warning at the end of installworld? > > > > > > > > > > No. There is no simple version we can check to make sure things are a > > > matched set.. > > > > Then I would call that a pretty fatal flaw in design. There needs > > to be a way to find out what version of "loader" /boot/loader.efi > > is there. > > > > I was also not asking if we have a way now, I was asking if there > > was a way to implement, and I doubt the answer to that question is > > no. > > > > I know. We've not needed it before, and I'm having trouble seeing it now > how it is connected to uname -UK. The path forward isn't DWIM. There are > too many variables. Without DWIM requirements, a tight, buttoned up version > isn't needed. I attached it to uname -UK as from an operational standpoint the easy semi-unique or matching qualifier for compatibilty is exactly that token. I am not advocating we enforce a version match, but that it would certain of helped me several times in the past to know that my /boot/* files are from 1100122 1100122 and hence need to be updated. The current BTX 1.1 is bit rot, that value has not changed in ages and tells me nothing about what boot code I am running, why do we even output it? > Warner > > Warner > > > > John Baldwin > > > > Rod Grimes rgrimes@freebsd.org > > 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 > > Why does your mail client wrap my <70 column signature? > Ask Google. Your saying gmail is doing this when you reply? Interesting > Warner > > Rod Grimes > > rgrimes@freebsd.org -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Tue Mar 26 09:34:00 2019 Return-Path: Delivered-To: freebsd-arch@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 3EC201548820 for ; Tue, 26 Mar 2019 09:34:00 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 B62A5876EB for ; Tue, 26 Mar 2019 09:33:59 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 77087154881B; Tue, 26 Mar 2019 09:33:59 +0000 (UTC) Delivered-To: arch@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 6423F154881A; Tue, 26 Mar 2019 09:33:59 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB4D6876E6; Tue, 26 Mar 2019 09:33:58 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id A16F9C1D9C; Tue, 26 Mar 2019 03:34:58 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DtKf7IdZBypQ; Tue, 26 Mar 2019 03:34:58 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Tue, 26 Mar 2019 03:34:58 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" , Warner Losh Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers References: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> From: Rebecca Cran Message-ID: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> Date: Tue, 26 Mar 2019 03:33:56 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: CB4D6876E6 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 09:34:00 -0000 On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > The current BTX 1.1 is bit rot, that value has not changed in ages > and tells me nothing about what boot code I am running, why do we > even output it? Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a useful version number. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Tue Mar 26 13:31:31 2019 Return-Path: Delivered-To: freebsd-arch@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 6882B155269E for ; Tue, 26 Mar 2019 13:31:31 +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 D40006A9B2 for ; Tue, 26 Mar 2019 13:31:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8F3A4155269A; Tue, 26 Mar 2019 13:31:30 +0000 (UTC) Delivered-To: arch@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 5258B1552699 for ; Tue, 26 Mar 2019 13:31:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB15C6A9AF for ; Tue, 26 Mar 2019 13:31:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82d.google.com with SMTP id x12so14496945qts.7 for ; Tue, 26 Mar 2019 06:31:29 -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=b/LwgLws8PXDoFdSqOpJx+xXQus+a3WnwBim54+BN0A=; b=IMtKQNVlfJgpyub1wxGBiJ+D7Ak0LzAo6Lxozb8S5Q/v8Oij9NawFm60kUE24t5h/j t58icdNtLhWzo8oTPyA2BO/bpmK4zw0LPGywwit4GkEWVa9NxBz8qENU3l1ztvqVT0eb o6H89cA4EpFf2YJs+TMOq60sJjFcKAJcwf0an94oM7YOC5NDLCKM600ElGWymZ5+91tK pN/8eu8XiVgFIRaCJgDevgvoFR5zGbWuerfrAoQcmKwZUD3H+f05JmOGHhD9kNicZoAK p5q3hUrZAmML6yF+iK0OfrCKrSn+yDZjOyGUgweapfhpaCNHg2yBn3cRdBjisp6Ovu38 Pkrg== 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=b/LwgLws8PXDoFdSqOpJx+xXQus+a3WnwBim54+BN0A=; b=RsbZoAXF/MGNVIPPVUxPA8KYT9SLv5GUfJMrQztWe10UdMc6AfdjjSJe2CRmy9AunZ xNpstpgWcnH6yabMKrJqZZo+/jT4bodeunJybrCf/IYHhQlw/lgnMldyCWpi59g6cMvC 9Lnl6pgbhJiwF79VO2Ar4cnS+2tqOAC5O9MfP+UPf9cq5UNo81pIYHHiUAunRHB8P7mF SZ3DWy6npXhwuVKDd2WM09HCiXzvXmsLCi6/WzYJSu/NSxiUiY+bxXFy+Aw+UVUZFqSm eEOK5HqqOlh4lph3+1WMbUAhQF68AqMrhlZwuIx79nfG9Mxp9d/dx7eM0Ko34E3zKr3l RWxg== X-Gm-Message-State: APjAAAWUi6//XyKUXWpugHMoZNdVVxa+cBY+3HXrYZAuYlBufNvXdd+u nCmNURKG/Ll8eVR/EQtVV5LMkG1Gdkjuazp/BQKS8g== X-Google-Smtp-Source: APXvYqzPizmxhODmL2WChh050Pm/s8UPqzvemSsivlPWzFGqgkZ3FffSp8OgpF975aIhx7rQwwBSFYwgwQfESbe+N8U= X-Received: by 2002:ac8:4685:: with SMTP id g5mr18745190qto.242.1553607089347; Tue, 26 Mar 2019 06:31:29 -0700 (PDT) MIME-Version: 1.0 References: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> In-Reply-To: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> From: Warner Losh Date: Tue, 26 Mar 2019 07:31:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-Rspamd-Queue-Id: DB15C6A9AF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 13:31:31 -0000 On Tue, Mar 26, 2019, 3:33 AM Rebecca Cran wrote: > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > and tells me nothing about what boot code I am running, why do we > > even output it? > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a > useful version number. > It's the useful part that I objected to. We wanted to do it, but haven't for the last 20 years of trying. I doubt we'll do any better in the future, especially with the repeatable build stuff closing many doors of trying to automate it. Warner > From owner-freebsd-arch@freebsd.org Wed Mar 27 08:47:32 2019 Return-Path: Delivered-To: freebsd-arch@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 27A021548303 for ; Wed, 27 Mar 2019 08:47:32 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 8B46C6BCDC for ; Wed, 27 Mar 2019 08:47:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 48BC91548300; Wed, 27 Mar 2019 08:47:31 +0000 (UTC) Delivered-To: arch@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 33A9315482FF; Wed, 27 Mar 2019 08:47:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A27206BCDB; Wed, 27 Mar 2019 08:47:30 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2R8lNtB088824; Wed, 27 Mar 2019 01:47:23 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2R8lMxc088823; Wed, 27 Mar 2019 01:47:22 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> To: Rebecca Cran Date: Wed, 27 Mar 2019 01:47:22 -0700 (PDT) CC: "Rodney W. Grimes" , Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: A27206BCDB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 08:47:32 -0000 > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > and tells me nothing about what boot code I am running, why do we > > even output it? > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a > useful version number. Please go implement the placing of the version that is used to cause uname -U to output 1200086 or whatever from /usr/sbin/uname at build time, which is not an issue at all as far as reproducabile builds as that version number is the same no mater how many times you run the build. This is the current defining value that says your kernel is compatible with userland and should also be the defining value for if your boot code is also compatible. Thanks, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Wed Mar 27 14:20:23 2019 Return-Path: Delivered-To: freebsd-arch@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 3291015512A7 for ; Wed, 27 Mar 2019 14:20:23 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 A587576863 for ; Wed, 27 Mar 2019 14:20:22 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 69B5315512A4; Wed, 27 Mar 2019 14:20:22 +0000 (UTC) Delivered-To: arch@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 551CC15512A3; Wed, 27 Mar 2019 14:20:22 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E139576862; Wed, 27 Mar 2019 14:20:21 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 4F725C2DAC; Wed, 27 Mar 2019 08:21:14 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ya-f8ypkdZ6U; Wed, 27 Mar 2019 08:21:14 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Wed, 27 Mar 2019 08:21:14 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers References: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> From: Rebecca Cran Message-ID: <80ab3ea0-ed02-112c-d013-16aa360a8bf3@bluestop.org> Date: Wed, 27 Mar 2019 08:20:14 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: E139576862 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.97 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 14:20:23 -0000 On 3/27/19 2:47 AM, Rodney W. Grimes wrote: > > Please go implement the placing of the version that is used to > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > at build time, which is not an issue at all as far as reproducabile > builds as that version number is the same no mater how many times you > run the build. > > This is the current defining value that says your kernel is compatible > with userland and should also be the defining value for if your boot > code is also compatible. I do think that'll be useful, so I'll try and get that into the design doc that Warner's writing! -- Rebecca Cran From owner-freebsd-arch@freebsd.org Wed Mar 27 14:25:23 2019 Return-Path: Delivered-To: freebsd-arch@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 F2E201551722 for ; Wed, 27 Mar 2019 14:25:22 +0000 (UTC) (envelope-from kevans@freebsd.org) 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 78A5A76EA4 for ; Wed, 27 Mar 2019 14:25:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3904D155171F; Wed, 27 Mar 2019 14:25:22 +0000 (UTC) Delivered-To: arch@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 2644D155171E; Wed, 27 Mar 2019 14:25:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFB8176EA1; Wed, 27 Mar 2019 14:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 57E7713696; Wed, 27 Mar 2019 14:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f181.google.com with SMTP id j89so14594153ljb.1; Wed, 27 Mar 2019 07:25:21 -0700 (PDT) X-Gm-Message-State: APjAAAUurQXbdqP8vJjYgjo+EPMGzPWVq49BKkrq6waT/sAy1XqFwxpJ EpRQCEjUOyPqZ613EXeKguaL0KFVZRUJfyRoz2c= X-Google-Smtp-Source: APXvYqwS1CUpIdeO07lEN+q/BuhbrAmHzYjuARonsVxmYhE0IVjEdR+5kv0YMJ/ASPqH1AUJhrDBCWQvzlzcnMIKxo0= X-Received: by 2002:a2e:5c7:: with SMTP id 190mr19336874ljf.108.1553696719850; Wed, 27 Mar 2019 07:25:19 -0700 (PDT) MIME-Version: 1.0 References: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> In-Reply-To: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> From: Kyle Evans Date: Wed, 27 Mar 2019 09:25:05 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Rebecca Cran , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BFB8176EA1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 14:25:23 -0000 On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes wrote: > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > > and tells me nothing about what boot code I am running, why do we > > > even output it? > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a > > useful version number. > > Please go implement the placing of the version that is used to > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > at build time, which is not an issue at all as far as reproducabile > builds as that version number is the same no mater how many times you > run the build. > > This is the current defining value that says your kernel is compatible > with userland and should also be the defining value for if your boot > code is also compatible. > This feels slightly wrong/misleading. We change loader -> kernel handoff far, far, far less frequently than we change userland <-> kernel compatibility. I don't have any constructive feedback otherwise, though, and it does at least provide an indicator of how old your boot bits are relative to the rest of the world. From owner-freebsd-arch@freebsd.org Wed Mar 27 15:24:15 2019 Return-Path: Delivered-To: freebsd-arch@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 281C51552D30 for ; Wed, 27 Mar 2019 15:24:15 +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 7150180EFF for ; Wed, 27 Mar 2019 15:24:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 340071552D2F; Wed, 27 Mar 2019 15:24:14 +0000 (UTC) Delivered-To: arch@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 0FD291552D2E for ; Wed, 27 Mar 2019 15:24:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7155480EFD for ; Wed, 27 Mar 2019 15:24:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-lf1-x129.google.com with SMTP id m13so11665525lfb.6 for ; Wed, 27 Mar 2019 08:24:13 -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=Cw8Oj+xmVH3AUxa/tV2nqMXSjCj2kGzimJSuADGVqF4=; b=rqAQq1H4fUE6yMEk8JRD3HTAmtflZEA0iLwv5rxzxpiRoRmrlBSt7fQgN2NtxsbljL ra7FTzwVWFO9P14b/7811LncSHSyx46R2nFjRs/q0AImjREBdtAX0oReen9WExqF7qK/ 9c3pQ8dtDs/CL7s9LwCJdOynJ1qO+NvY7E8GmA5RXnzPZhfJFnqRaSXxkEdhoWUFbkt0 doSOHLB416S8ZHMTBnKXMB3sY9aRWWDtkNVSaji+0dHPDWSkJH0FmbMdq2YSuXxNlHC0 I03z07dfXFfnFHxA7jYBQg7TSV7yeGpW3ESHO9EscxACKCAQPrE3Tl4QyWo/Nw23HZUI Nx8g== 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=Cw8Oj+xmVH3AUxa/tV2nqMXSjCj2kGzimJSuADGVqF4=; b=K30g54wxMzy9B3RNv1Ohe3XkSiNsVkTX1kG4znHahzc4EwI6dS++t0r5rIeSXo8eAh MWHCYZd5jzQHrqpxQQPM2eDLWpzAkTE2Ho1Q0JPr5iU7O8j4Nw6iyapDxW+u/UszDTzh OCrlAd60VViYH0UHopPW4QoYO+55kqCJ0OYTJFC1lXTcs1Otm8/n3HJ8SZH8dVyF7vI0 aSof6FkrPskAYQLiYfDBe+sHebee4BjHmw9lP9filip+1kYNITEYBL/AUtLWQipa7AOS 7OC3+DO5blZbw7Ce3vUd8odEYtyQJpP932UipomaQdf0N7jnx7JOF7d10sbp1fGB67Xd vGeg== X-Gm-Message-State: APjAAAXxn9C5WI8mC10foj01uoFLt0oti99X+heaPOpqFkukxbftWP5j uKMO8X0LvJez9e28wzQy50rVKI/tNLFrqRaPae3xGQ== X-Google-Smtp-Source: APXvYqzLfgNyWtYifyQwpn65JZfx5UcvA6qJ4RokVaefjRetm1OiYbkTcjICFiea6WjMLmaQeW2d/06UrlP+9CBRLoE= X-Received: by 2002:ac2:592f:: with SMTP id v15mr14302952lfi.133.1553700250994; Wed, 27 Mar 2019 08:24:10 -0700 (PDT) MIME-Version: 1.0 References: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Wed, 27 Mar 2019 09:23:59 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Kyle Evans Cc: "Rodney W. Grimes" , Konstantin Belousov , Rebecca Cran , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 7155480EFD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.971,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 15:24:15 -0000 On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > wrote: > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > > > and tells me nothing about what boot code I am running, why do we > > > > even output it? > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed > a > > > useful version number. > > > > Please go implement the placing of the version that is used to > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > at build time, which is not an issue at all as far as reproducabile > > builds as that version number is the same no mater how many times you > > run the build. > > > > This is the current defining value that says your kernel is compatible > > with userland and should also be the defining value for if your boot > > code is also compatible. > > > > This feels slightly wrong/misleading. We change loader -> kernel > handoff far, far, far less frequently than we change userland <-> > kernel compatibility. I don't have any constructive feedback > otherwise, though, and it does at least provide an indicator of how > old your boot bits are relative to the rest of the world. > Right. The loader has nothing to do with the userland (apart from sharing some minor bits of code that are too boring to be versioned). There are two versions we're interested in for the loader. First is the loader <-> kernel handoff. That's not materially changed in decades, so it's version number is still basically 1. there are some fine details here I'm purposely glossing over, but they are far down in the noise. The second is the loader to loader support files version. We don't actually version this, but you can't install /boot/loader* without installing the companion files. This often will work (especially in the FORTH era when the code velocity of the .4th files was so slow and the new FORTH words / loader commands were added so rarely), but not always. In the LUA era, we're still in the up-take phase of things. We've gotten to parity (more or less) with FORTH and now it's time to innovate. That innovation will likely require new lua primitives to be implemented in C, which requires a matched set of the loader and support files. This is nothing new (we had it when FORTH was moving quickly all the time, and had it less often when new features like ZFS booting came in). There's a new wrinkle, though, in all this, which is our desire to get rid of boot1.efi and replace it with loader.efi. This brings the issue of 'cross-threading' of updates to the fore. That's an interesting issue, and that won't be solved by the uname version hack. We could burn the sys/param.h version into loader.efi but it wouldn't detect anything in the lua files we install. We could add a new lua file that's just the version an complain when there's a mismatch, but that seems to just introduce a failure mode that's not effective at solving problems (there will be a lot of false positives, because the loader changes like I'm worried about happen at about 1/50th the rate of version bumps). We could invent something for the boot loader, but that would be fragile, and have all the same issues of 'what to do' when there's a mismatch. We're likely better off wrapping new features in such a way as they can be missing and the code will still work with reduced functionality. This is why it feels wrong to me. It's a poor fit to the problem at hand, the number isn't conveniently encoded in the right places and it's unclear what to do with mismatches. Warner From owner-freebsd-arch@freebsd.org Wed Mar 27 17:31:25 2019 Return-Path: Delivered-To: freebsd-arch@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 D98FD155571A for ; Wed, 27 Mar 2019 17:31:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 1D539850AC for ; Wed, 27 Mar 2019 17:31:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id D4F9D1555719; Wed, 27 Mar 2019 17:31:23 +0000 (UTC) Delivered-To: arch@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 9779F1555718 for ; Wed, 27 Mar 2019 17:31:23 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1688A850A9; Wed, 27 Mar 2019 17:31:22 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2RHVG3F090753; Wed, 27 Mar 2019 10:31:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2RHVGJd090752; Wed, 27 Mar 2019 10:31:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Wed, 27 Mar 2019 10:31:16 -0700 (PDT) CC: Kyle Evans , Konstantin Belousov , Rebecca Cran , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 1688A850A9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.954,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 17:31:25 -0000 > On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > > > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > > wrote: > > > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > > > > and tells me nothing about what boot code I am running, why do we > > > > > even output it? > > > > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed > > a > > > > useful version number. > > > > > > Please go implement the placing of the version that is used to > > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > > at build time, which is not an issue at all as far as reproducabile > > > builds as that version number is the same no mater how many times you > > > run the build. > > > > > > This is the current defining value that says your kernel is compatible > > > with userland and should also be the defining value for if your boot > > > code is also compatible. > > > > > > > This feels slightly wrong/misleading. We change loader -> kernel > > handoff far, far, far less frequently than we change userland <-> > > kernel compatibility. I don't have any constructive feedback > > otherwise, though, and it does at least provide an indicator of how > > old your boot bits are relative to the rest of the world. > > > > Right. The loader has nothing to do with the userland (apart from sharing > some minor bits of code that are too boring to be versioned). There are two > versions we're interested in for the loader. > > First is the loader <-> kernel handoff. That's not materially changed in > decades, so it's version number is still basically 1. there are some fine > details here I'm purposely glossing over, but they are far down in the > noise. > > The second is the loader to loader support files version. We don't actually > version this, but you can't install /boot/loader* without installing the > companion files. This often will work (especially in the FORTH era when the > code velocity of the .4th files was so slow and the new FORTH words / > loader commands were added so rarely), but not always. In the LUA era, > we're still in the up-take phase of things. We've gotten to parity (more or > less) with FORTH and now it's time to innovate. That innovation will likely > require new lua primitives to be implemented in C, which requires a matched > set of the loader and support files. This is nothing new (we had it when > FORTH was moving quickly all the time, and had it less often when new > features like ZFS booting came in). There's a new wrinkle, though, in all > this, which is our desire to get rid of boot1.efi and replace it with > loader.efi. This brings the issue of 'cross-threading' of updates to the > fore. That's an interesting issue, and that won't be solved by the uname > version hack. We could burn the sys/param.h version into loader.efi but it > wouldn't detect anything in the lua files we install. We could add a new > lua file that's just the version an complain when there's a mismatch, but > that seems to just introduce a failure mode that's not effective at solving > problems (there will be a lot of false positives, because the loader > changes like I'm worried about happen at about 1/50th the rate of version > bumps). We could invent something for the boot loader, but that would be > fragile, and have all the same issues of 'what to do' when there's a > mismatch. We're likely better off wrapping new features in such a way as > they can be missing and the code will still work with reduced functionality. > > This is why it feels wrong to me. It's a poor fit to the problem at hand, > the number isn't conveniently encoded in the right places and it's unclear > what to do with mismatches. I care nothing about miss matches, I care to know from witch sources my loader.* /boot/* files come from and that is just a royal PITA to figure out without something like this. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Thu Mar 28 04:08:59 2019 Return-Path: Delivered-To: freebsd-arch@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 C127F15299E7 for ; Thu, 28 Mar 2019 04:08:58 +0000 (UTC) (envelope-from ota@j.email.ne.jp) 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 427A18226B for ; Thu, 28 Mar 2019 04:08:58 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: by mailman.ysv.freebsd.org (Postfix) id 0389715299D7; Thu, 28 Mar 2019 04:08:58 +0000 (UTC) Delivered-To: arch@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 D2AE915299D6; Thu, 28 Mar 2019 04:08:57 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail01.asahi-net.or.jp (mail01.asahi-net.or.jp [202.224.55.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACB982269; Thu, 28 Mar 2019 04:08:53 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from rv515.advok.com (pool-72-76-119-135.nwrknj.fios.verizon.net [72.76.119.135]) (Authenticated sender: NR2Y-OOT) by mail01.asahi-net.or.jp (Postfix) with ESMTPSA id A33AA10DB1C; Thu, 28 Mar 2019 13:08:41 +0900 (JST) Date: Thu, 28 Mar 2019 00:08:26 -0400 From: Yoshihiro Ota To: Cy Schubert Cc: FreeBSD X11 mailing list , "freebsd-arch@freebsd.org" Subject: Re: DRM removal soon - crash with PAE kernel Message-Id: <20190328000826.2f88f1b723703d0384f6464a@j.email.ne.jp> In-Reply-To: <201903010645.x216jT7Y005464@slippy.cwsent.com> References: <20190301005009.4457f46f10c3a8229b5dd7fc@j.email.ne.jp> <201903010645.x216jT7Y005464@slippy.cwsent.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i386-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4ACB982269 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 202.224.55.13 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp X-Spamd-Result: default: False [-1.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.77)[-0.775,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:202.224.55.0/24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[email.ne.jp]; NEURAL_SPAM_SHORT(0.35)[0.348,0]; NEURAL_HAM_LONG(-0.99)[-0.988,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[sbmx.asahi-net.or.jp]; IP_SCORE(-0.01)[country: JP(-0.07)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[13.55.224.202.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4685, ipnet:202.224.32.0/19, country:JP]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[135.119.76.72.zen.spamhaus.org : 127.0.0.10] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 04:08:59 -0000 Hi Cy and all, I've been using drm-kmod okay on FreeBSD 12.0-RELEASE i386 GENERIC based kernel with multiple machines since the last post. I switched to use PAE kernel (12.0-RELEASE) on one of machines and then this module started panicing kernel. Given addressing is different, this crash isn't something surprise to see, though... Hiro On Thu, 28 Feb 2019 22:45:29 -0800 Cy Schubert wrote: > In message <20190301005009.4457f46f10c3a8229b5dd7fc@j.email.ne.jp>, > Yoshihiro O > ta writes: > > Hi, all and Cy. > > > > I trimmed most of old posts. > > > > On Thu, 28 Feb 2019 11:22:52 -0800 > > Cy Schubert wrote: > > > > > > Yes. drm-legacy-kmod should be removed from ports sooner than later. drm-cu > > rrent-kind works > > > perfectly on older gear like my 13 year old Pentium-M, which was repurposed > > as an i386 test > > > platform years ago. > > > > Don't worry. > > You are still talking in the unit of years. > > I still occasionally use a laptop from the last century. :) > > Jokes aside, I have 2 questions. > > > > I have a 12.0-RELEASE base system and 12.0 pkg configuration. > > Looking back my operational log, pkg install was like this. > > > > # pkg install drm-kmod > > Updating FreeBSD repository catalogue... > > FreeBSD repository is up to date. > > All repositories are up to date. > > The following 3 package(s) will be affected (of 0 checked): > > > > New packages to be INSTALLED: > > drm-kmod: g20180930 > > drm-legacy-kmod: g20181031_1 > > gpu-firmware-kmod: g20180825 > > > > Question #1: > > drm-current-kmod was mentioned in your reply. Have I installed wrong kmod? > > The drm-kmod meta-port installs the correct drm-*-kmod for you. It > appears the package installed the legacy kmod. If you want to install > drm-current-kmod or drm-fbsd12.0-kmod you'd need to specify either > instead of drm-kmod. > > Does it work? If it works, stay with it. > > > > > > > I do not setup X to come up as a part of boot process. So, I login via conso > > le and may stay there or decide to startx depending on what I want to do. I > > can see the driver switching and my kld_list="/boot/modules/radeonkms.ko" loa > > ds these modules as expected. > > X loads the correct kernel modules for you. I don't pre-load any drm > modules. I let X handle everything for me. Yours does as well. It > simply works. > > > > > On the other hand, I still see the following in dmesg. > > > > drmn0: ======================================================= > > drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmo > > d p > > kg > > drmn0: ======================================================= > > drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers > > drmn0: ======================================================= > > drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmo > > d pkg > > drmn0: ======================================================= > > drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers > > drmn0: on vgapci0 > > info: [drm] RADEON_IS_PCIE > > info: [drm] initializing kernel modesetting (PALM 0x1002:0x9806 0x144D:0xC589 > > ). > > info: [drm] register mmio base: 0xFEB00000 > > info: [drm] register mmio size: 262144 > > info: [drm] radeon_atrm_get_bios: ===> Try ATRM... > > The deprecated DRM2 was removed from current after 12 was branched. You > could alter the module_path kenv environment variable to put > /boot/modules before /boot/kernel, but frankly don't mess with it if it > works. > > > > > kldstat -v reports this: > > > > 5 1 0x1900d000 10c000 radeonkms.ko (/boot/modules/radeonkms.ko) > > Contains modules: > > Id Name > > 529 vgapci/radeonkms > > 534 drmn/radeon_atom_hw_i2c > > 531 radeon_iicbb/iicbb > > 533 radeon_hw_i2c/iicbus > > 530 drmn/radeon_iicbb > > 532 drm/radeon_hw_i2c > > 6 1 0x19119000 4e000 drm2.ko (/boot/kernel/drm2.ko) > > Contains modules: > > Id Name > > 525 drmn/drm_iic_dp_aux > > 526 drmn > > > > Question #2. > > Am I loading the right driver set? > > In your case installing the package is a NOP because the base drm is > loaded because it's first in the kld search path. If X works, then > don't worry about it. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > 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 Thu Mar 28 20:43:58 2019 Return-Path: Delivered-To: freebsd-arch@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 815F81568CEF for ; Thu, 28 Mar 2019 20:43:58 +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 CA3018B37E for ; Thu, 28 Mar 2019 20:43:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 096E51568CD6; Thu, 28 Mar 2019 20:43:56 +0000 (UTC) Delivered-To: arch@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 AFBBC1568CD5 for ; Thu, 28 Mar 2019 20:43:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A1008B324 for ; Thu, 28 Mar 2019 20:43:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82f.google.com with SMTP id k2so182654qtm.1 for ; Thu, 28 Mar 2019 13:43:55 -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=NIKQRQJT2zh/ZMuYCTx1k5eOO+fJ/n8sHhrGG3B8ziw=; b=C9XqRH3psXobpYln6E9BSVAVobF+f2V+gDrGoE+BNVpz11IkzE3aAd9dfd4SxrBr3+ NIgixS+7QOHRySj1AeigerL4CmURmHJSDbjzC8S5OT+oFGDNMZ97zmCzDsCfYfzSKY2B +WSm5uvWIMtkR0WarxPLWgoR3/kaxdoqscDanDXtmLr/97H+fMjsapYnfiFVGNavQMBj h20uGuCvyCA/EBb0mJVbkb/RO3pQGa5Hg4L4HaRTo4DbE8Ykf9/Q/Meoa5CNKB5ZBSib JIReKaNB2rRmI4RKbShQly1KQlB1Hae7eO70cTCE4lCwqErsmZfKp4BN8ccUiOMqsHKj l4hg== 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=NIKQRQJT2zh/ZMuYCTx1k5eOO+fJ/n8sHhrGG3B8ziw=; b=cz2KlowTxA2+QJngxuUmIybbQxPR1lmSJ7CYvmnkmljUq/CMPsvz93st1+LSPaPK2u wyrq8T47Y5pHHFNdEi4sbnrXGxRGaTzfkM7GqKsbO/DTGc31u2aULOqFO0dRdgDTEocZ 7VogtYLjWFA8C/JZn6NqGGSudjO3JnJiu+bL7G96ojTI1ThadYo9QE4VJ/I1gkqhrBAt c6GpOzdknlylnvOohWBuwIeZbGem3xtvF/fg9CexGe4f5C0g4SAtXkYhTQuzLAyRn2K4 DHvyT9nhmB+H54KWMPcTxU6ZloIT6lgn/qWywxyUadVZeeLsTIiIwTuO/1B2qcpGAQMk QKjw== X-Gm-Message-State: APjAAAWb2SclDd7tJpiUA9oK/nlBhAE7ahgndINjGoBLEyrNNza3FJMd QFoalSis9BdOBC76gkY3xS//GG1PfA9bYp+lWHLTOQ== X-Google-Smtp-Source: APXvYqxopW3gKF4oP8VLxK7oP0iY/IzFQ4uNK5fX54bMds67hZhegJgUuKOnCMQEjeRhd4dTBT+suOo4/Q5rB4d3/fQ= X-Received: by 2002:a0c:9838:: with SMTP id c53mr38308482qvd.242.1553805833388; Thu, 28 Mar 2019 13:43:53 -0700 (PDT) MIME-Version: 1.0 References: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> In-Reply-To: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> From: Warner Losh Date: Thu, 28 Mar 2019 14:43:41 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Kyle Evans , Konstantin Belousov , Rebecca Cran , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-Rspamd-Queue-Id: 0A1008B324 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=C9XqRH3p X-Spamd-Result: default: False [-5.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[f.2.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]; NEURAL_HAM_SHORT(-0.83)[-0.834,0]; 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.79)[ip: (-8.89), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.15), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 20:43:58 -0000 On Wed, Mar 27, 2019 at 11:31 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > > > > > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > > > wrote: > > > > > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in > ages > > > > > > and tells me nothing about what boot code I am running, why do we > > > > > > even output it? > > > > > > > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, > Revision > > > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily > embed > > > a > > > > > useful version number. > > > > > > > > Please go implement the placing of the version that is used to > > > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > > > at build time, which is not an issue at all as far as reproducabile > > > > builds as that version number is the same no mater how many times you > > > > run the build. > > > > > > > > This is the current defining value that says your kernel is > compatible > > > > with userland and should also be the defining value for if your boot > > > > code is also compatible. > > > > > > > > > > This feels slightly wrong/misleading. We change loader -> kernel > > > handoff far, far, far less frequently than we change userland <-> > > > kernel compatibility. I don't have any constructive feedback > > > otherwise, though, and it does at least provide an indicator of how > > > old your boot bits are relative to the rest of the world. > > > > > > > Right. The loader has nothing to do with the userland (apart from sharing > > some minor bits of code that are too boring to be versioned). There are > two > > versions we're interested in for the loader. > > > > First is the loader <-> kernel handoff. That's not materially changed in > > decades, so it's version number is still basically 1. there are some fine > > details here I'm purposely glossing over, but they are far down in the > > noise. > > > > The second is the loader to loader support files version. We don't > actually > > version this, but you can't install /boot/loader* without installing the > > companion files. This often will work (especially in the FORTH era when > the > > code velocity of the .4th files was so slow and the new FORTH words / > > loader commands were added so rarely), but not always. In the LUA era, > > we're still in the up-take phase of things. We've gotten to parity (more > or > > less) with FORTH and now it's time to innovate. That innovation will > likely > > require new lua primitives to be implemented in C, which requires a > matched > > set of the loader and support files. This is nothing new (we had it when > > FORTH was moving quickly all the time, and had it less often when new > > features like ZFS booting came in). There's a new wrinkle, though, in all > > this, which is our desire to get rid of boot1.efi and replace it with > > loader.efi. This brings the issue of 'cross-threading' of updates to the > > fore. That's an interesting issue, and that won't be solved by the uname > > version hack. We could burn the sys/param.h version into loader.efi but > it > > wouldn't detect anything in the lua files we install. We could add a new > > lua file that's just the version an complain when there's a mismatch, but > > that seems to just introduce a failure mode that's not effective at > solving > > problems (there will be a lot of false positives, because the loader > > changes like I'm worried about happen at about 1/50th the rate of version > > bumps). We could invent something for the boot loader, but that would be > > fragile, and have all the same issues of 'what to do' when there's a > > mismatch. We're likely better off wrapping new features in such a way as > > they can be missing and the code will still work with reduced > functionality. > > > > This is why it feels wrong to me. It's a poor fit to the problem at hand, > > the number isn't conveniently encoded in the right places and it's > unclear > > what to do with mismatches. > > I care nothing about miss matches, I care to know from witch sources > my loader.* /boot/* files come from and that is just a royal PITA to > figure out without something like this. > You do have the $FreeBSD$ tags for most of that today. For some of the boot pieces you'll never know more than the date it was installed because we're using 7.45kb of the 7.5kb available in boot2 and there's no room. For the other things, there's not really been requests to have more than we have today and it would come at a cost of additional space at a time when we're feeling space pressure in most of the components due to the new features that have rolled in since FreeBSD 10.x or so (secure boot, crypto signing, more filesystems, encrypted filesystems, etc). It all adds up... Warner From owner-freebsd-arch@freebsd.org Sat Mar 30 16:25:32 2019 Return-Path: Delivered-To: freebsd-arch@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 9DCC51556EC5 for ; Sat, 30 Mar 2019 16:25:32 +0000 (UTC) (envelope-from rebecca@bluestop.org) 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 DC3488E292 for ; Sat, 30 Mar 2019 16:25:31 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9AF4C1556EC3; Sat, 30 Mar 2019 16:25:31 +0000 (UTC) Delivered-To: arch@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 757F51556EC2; Sat, 30 Mar 2019 16:25:31 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E04B8E291; Sat, 30 Mar 2019 16:25:30 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id CDE29C5039; Sat, 30 Mar 2019 10:26:21 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id etS3ViRfcMeW; Sat, 30 Mar 2019 10:26:21 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sat, 30 Mar 2019 10:26:21 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> From: Rebecca Cran Message-ID: Date: Sat, 30 Mar 2019 10:25:27 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 8E04B8E291 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.72 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bluestop.org:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.98)[ip: (-9.86), ipnet: 65.100.0.0/14(-4.90), asn: 209(-0.06), country: US(-0.07)]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bluestop.org:+]; MX_GOOD(-0.01)[cached: mail.bluestop.org]; DMARC_POLICY_ALLOW(-0.50)[bluestop.org,quarantine]; NEURAL_HAM_SHORT(-0.73)[-0.732,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:209, ipnet:65.100.0.0/14, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 16:25:33 -0000 On 3/24/19 5:57 PM, Warner Losh wrote: > > He's asking for stopping doing a make install in src/stand. I'm thinking > that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, > but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader > phase. Again, only if the ESP is mounted, and we have a default spot for > it. For this script, I don't think hunting for the ESP is the right way to > go... which means we need to define a standard place for the ESP to be > mounted, which we should do before we turn on any of these features. I booted openSUSE Tumbleweed last night on my ASUS ROG Zenith Extreme board for the first time in a while and updated it to the latest revision. This morning I went to boot into FreeBSD and the "FreeBSD" boot entry had disappeared! Fortunately I have rEFInd installed so I could select the "UEFI OS" entry and get back into FreeBSD, but that's another reason we need to be really careful about relying too heavily on the boot manager variables. -- Rebecca Cran From owner-freebsd-arch@freebsd.org Sat Mar 30 17:06:30 2019 Return-Path: Delivered-To: freebsd-arch@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 7327615585E4 for ; Sat, 30 Mar 2019 17:06:30 +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 BB8638FA16 for ; Sat, 30 Mar 2019 17:06:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7F96815585DE; Sat, 30 Mar 2019 17:06:29 +0000 (UTC) Delivered-To: arch@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 5D6A015585DB for ; Sat, 30 Mar 2019 17:06:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F23CA8FA13 for ; Sat, 30 Mar 2019 17:06:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x833.google.com with SMTP id v20so5952235qtv.12 for ; Sat, 30 Mar 2019 10:06:28 -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=et1HN7DwT/JyZLbP775T3iyUFGmQl0xx+NK+/h0gV2I=; b=g6/7Vkf8iyHZ2rIJcOXHS6XiGSxhkJo2h5Rf0YJeLu0WeC6s43MF6PO3W4n1CPl+Rt 1uufOz7Tmfa/zPgyZy1QovtVHSWj6Mny5kgKc84OLyiwmB7wW3a6OOxI2f5stWIRInSf Ell/aU6ddYb+l7HU6yPGc2K3UADHXdxyOoQhZONUIYAUSo1yQ708ezvzhUmzBKc25We7 bQG3XbFPYCPo+UDdvXTShuf7t8aTgFuB6WnJ4KZHRb5SAoangpUEYSiyBZWieGklKung jZp4LlRcUhpZ3RF4p1ZerKMLwhuWS/u15cd8nWqf9LUpxf0zx9nbCeGA+ECin6bVbFz/ NrhQ== 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=et1HN7DwT/JyZLbP775T3iyUFGmQl0xx+NK+/h0gV2I=; b=ZIXawJoaadBwkj/RKOwB/pUKERA5MhUgaJg27sCXrM9ZaQnN3fTM7PipTu2DCNrG/g 7ZU43zHUfeGSJj4g0sOdqpri+it+XTTbopcfpbUonInwMQEeoQbmN3SJEw+mOvqlwVsW 3tcBKGUJUJszLkP/P89CAwaPrBo8wNq4/D6w7Vv/2DsuyLmPC5q5jl59Mzb+2vDNfZGD gqj+9RB/gNrYVqqa6JnbpWvFpInLmcBXdd0Myb+D+7hpglYlRA2dj3NmF/0M2fiFkZ0C 8Y+81YmSVB3e5jlzajF+okzqB8+TGf7pjvXTL1XqpdvZXV1172prZEwB/pZTFirjNuYX 5BRw== X-Gm-Message-State: APjAAAVRiGnXddZ+VtJ8HxdKCo8qyhTyTgbDAbG3801fUqgvhBBqmWgT VsPg/nv16qQTTr6EQ4qgHkpf3MuhQITc4hvt57em4w== X-Google-Smtp-Source: APXvYqw+D95+G3+bXNsxb12Mpx73isbklS3fQNTeAlrc/qOoW4tYVtGpBRZwiuIfcV33ebVJ8gDCVDCVQTmOYaQrJLY= X-Received: by 2002:a0c:b501:: with SMTP id d1mr46600040qve.115.1553965588180; Sat, 30 Mar 2019 10:06:28 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> In-Reply-To: From: Warner Losh Date: Sat, 30 Mar 2019 11:06:16 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: F23CA8FA13 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.945,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 17:06:30 -0000 On Sat, Mar 30, 2019 at 10:25 AM Rebecca Cran wrote: > On 3/24/19 5:57 PM, Warner Losh wrote: > > > > He's asking for stopping doing a make install in src/stand. I'm thinking > > that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, > > but leave the\efi\boot\bootXXXX.efi alone as part of this new > installloader > > phase. Again, only if the ESP is mounted, and we have a default spot for > > it. For this script, I don't think hunting for the ESP is the right way > to > > go... which means we need to define a standard place for the ESP to be > > mounted, which we should do before we turn on any of these features. > > > I booted openSUSE Tumbleweed last night on my ASUS ROG Zenith Extreme > board for the first time in a while and updated it to the latest > revision. This morning I went to boot into FreeBSD and the "FreeBSD" > boot entry had disappeared! Fortunately I have rEFInd installed so I > could select the "UEFI OS" entry and get back into FreeBSD, but that's > another reason we need to be really careful about relying too heavily on > the boot manager variables. > I understand that. However, boot manager variables are the standard, and are the first thing we should use. Having alternatives has already been established for the crazy arm environments that can't be bothered to implement write. There are limits, however, to how much of the crazy can be contained here, and how far we can go without hitting serious 'make a guess' territory that jeopardizes the ability to do something complicated for people that need to have multiple things that look like they might be bootable, but prefer one over the other (the most common case of this is nanobsd's ping-pong upgrade, though there are others). Do you know why the FreeBSD entry disappeared? Was it something that the BIOS did? Was it a bug / feature in openSUSE? You installer rEFInd, so maybe that did something naughty. It would be great to know how this came to pass by recreating it. But all of that is orthogonal to the ask that we separate out the boot loader installation from the world, which implies we need to finally standardize on an ESP mount point and likely other things as well. Warner From owner-freebsd-arch@freebsd.org Sat Mar 30 19:51:03 2019 Return-Path: Delivered-To: freebsd-arch@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 944151560493 for ; Sat, 30 Mar 2019 19:51:03 +0000 (UTC) (envelope-from steffen@sdaoden.eu) 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 EB3F373381 for ; Sat, 30 Mar 2019 19:51:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by mailman.ysv.freebsd.org (Postfix) id A5381156048D; Sat, 30 Mar 2019 19:51:02 +0000 (UTC) Delivered-To: arch@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 91243156048C; Sat, 30 Mar 2019 19:51:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A80F7337D; Sat, 30 Mar 2019 19:51:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id DEF6F16054; Sat, 30 Mar 2019 20:50:52 +0100 (CET) Date: Sat, 30 Mar 2019 20:51:41 +0100 From: Steffen Nurpmeso To: Rebecca Cran via freebsd-hackers Cc: Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <20190330195141.2HVp7%steffen@sdaoden.eu> In-Reply-To: References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> Mail-Followup-To: Rebecca Cran via freebsd-hackers , Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" User-Agent: s-nail v14.9.13-32-g7e84ad8b OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 2A80F7337D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.91)[-0.907,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 19:51:03 -0000 Rebecca Cran via freebsd-hackers wrote in : |On 3/24/19 5:57 PM, Warner Losh wrote: ... |boot entry had disappeared! Fortunately I have rEFInd installed so I |could select the "UEFI OS" entry and get back into FreeBSD, but that's |another reason we need to be really careful about relying too heavily on |the boot manager variables. Thanks for bringing this name up. Maybe FreeBSD should pass some donations through to this rEFIt successor and start execution where that one ends. I have always been living in fear of using those badly documented Free(and other)BSD boot things, for true multiboot etc. i always had to end up with lilo or (horrors!) grub2. I can tell stories of systems where the Debian grub messed up freebsd booting, and the FreeBSD grub port only found freebsd. This is only fun for i-do-not-know-who, but anyway these have a vivid internet connection and multiple boxes available. I finally have found a home with syslinux and refit/refind. (Which is still very picky when you mess up configuration entries. For example it will find anything and include a manually entered configuration, but if you mess up the latter it will just break.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)