From owner-freebsd-stable@freebsd.org Fri Feb 19 21:26:19 2021 Return-Path: Delivered-To: freebsd-stable@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 94C5B53FC9C for ; Fri, 19 Feb 2021 21:26:19 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dj4Q33wWtz3Ldl for ; Fri, 19 Feb 2021 21:26:19 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by fc.opsec.eu with local (Exim 4.94 (FreeBSD)) (envelope-from ) id 1lDDHz-0006T7-CN; Fri, 19 Feb 2021 22:26:15 +0100 Date: Fri, 19 Feb 2021 22:26:15 +0100 From: Kurt Jaeger To: Warner Losh Cc: David Marec , freebsd-stable Subject: Re: FreeBSD 13/stable and zpool upgrade Message-ID: References: <7c9810fe-6960-0ec7-cab3-2f0c344471f4@lapinbilly.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Dj4Q33wWtz3Ldl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 21:26:19 -0000 Hi! > We can't do that. gptzfsboot is for something else that we can't get rid > of: BIOS/CMS booting. It's never been used for EFI booting at all. There's > no way to for EFI to use it, nor is there anyway for us to build it to just > work. You have to copy BOOTx64.efi to your ESP. What we could do, but don't > currently, is automate this process. We do not need it automated. We need it to be described in enough detail that we can write that BOOTx64.efi to the proper place. If there are some steps to find out where to write it etc., fine. Describe those steps. But mentioning a vague solution without more details lets far more unexperienced people try to fix complex issues, which will end in desasters. > That's been bogged down in > implementation details. It's easy if there's only one, but if you have a > USB stick installed, you don't want that to accidentally be upgraded, for > example... and I have test boxes with a dozen ESPs to test different boot > scenarios... And multiboot systems also can be screwed up by automatically > copying things into the ESP... Then, before automating it, give us enough details so that we can at least do it manually. -- pi@FreeBSD.org +49 171 3101372 Now what ?