From owner-freebsd-current@freebsd.org Mon Mar 30 07:47:49 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59364279E1E for ; Mon, 30 Mar 2020 07:47:49 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 48rPh14kSrz3R9v; Mon, 30 Mar 2020 07:47:43 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 02U7GDFf021894 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 30 Mar 2020 10:16:16 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 02U7GDFf021894 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 02U7GDYP021893; Mon, 30 Mar 2020 10:16:13 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 30 Mar 2020 10:16:13 +0300 From: Konstantin Belousov To: Nathan Whitehorn Cc: "Simon J. Gerraty" , Kyle Evans , Rebecca Cran , Tomoaki AOKI , FreeBSD Current , bsd-lists@bsdforge.com Subject: Re: When will the FreeBSD (u)EFI work? Message-ID: <20200330071613.GF1992@kib.kiev.ua> References: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> <344e85545cfc47c9835fc5918e5b1dc1@udns.ultimatedns.net> <20200329211137.012a8fd62b58525b027bcfb6@dec.sakura.ne.jp> <40bacb99-d463-cbad-3ccf-b3ddd6856d10@bsdio.com> <675a41c7-46c1-f548-b285-e5ede55db76a@freebsd.org> <16728.1585537356@kaos.jnpr.net> <18df34fe-6256-6e68-ead5-481e83a501fe@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18df34fe-6256-6e68-ead5-481e83a501fe@freebsd.org> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48rPh14kSrz3R9v X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.23 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.67)[-0.674,0]; NEURAL_HAM_LONG(-0.56)[-0.558,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 07:47:49 -0000 On Sun, Mar 29, 2020 at 08:11:16PM -0700, Nathan Whitehorn wrote: > > > On 2020-03-29 20:02, Simon J. Gerraty wrote: > > Nathan Whitehorn wrote: > >> It's basically this that has been the problem: we need a way to manage > >> updates of the EFI loader in this situation, which we don't currently > >> have. The ESP needs to be mounted at a standard point, > >> installworld/freebsd-update/etc. need to know to replace files there, we > >> need to fall back cleanly on older systems, etc. The original (failed -- > > Actually if you are doing secure boot, the *last* thing you want is to > > update /efi/boot with an unsigned update. > > > > So I would think it should be done as a unique operation - do you don't > > do it accidentally. > > > > At least that's how I'm handling it for embedded devices. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > The problem then is that we have treated loader as a > continuously-updatable part of the OS, like the kernel, and the update > system and development process assumes they get updated in sync. I do not see problems with boot1.efi. I use it in a way you described: I put it on ESP (in fact manually, but it does not matter) and only update loader.efi on /root. This works quite satisfactory for my updates 11->12-13 CURRENT and stable. I would highly prefer this model was not broken, whatever additional update options for loader are added. It is zero-maintaince for me.