From owner-freebsd-stable@freebsd.org Tue Jul 14 15:00:12 2020 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 5C9B3365833 for ; Tue, 14 Jul 2020 15:00:12 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5kG32VmBz4N2x; Tue, 14 Jul 2020 15:00:11 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id 06EEwmaa018398 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Jul 2020 07:58:48 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id 06EEwlBu018397; Tue, 14 Jul 2020 07:58:47 -0700 (PDT) (envelope-from warlock) Date: Tue, 14 Jul 2020 07:58:47 -0700 From: John Kennedy To: Kyle Evans Cc: Guido van Rooij , FreeBSD-STABLE Mailing List Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a Message-ID: <20200714145847.GB11731@phouka1.phouka.net> References: <20200709131201.GA3464@co.gvr.org> <20200709211854.GA11731@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4B5kG32VmBz4N2x X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net X-Spamd-Result: default: False [3.31 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.26)[0.263]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.92)[0.920]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.93)[0.925]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 15:00:12 -0000 On Fri, Jul 10, 2020 at 02:25:02PM -0500, Kyle Evans wrote: > > So one recipe doesn't even seem to make the freebsd-boot partition, so is it > > optional for a pure UEFI boot? Should we always gpart-bootcode it if it exists > > and upgrade BOOTx64.efi when the EFI partition exists, or is there a few more > > wrinkles we need to worry about? > > Correct, freebsd-boot is not needed for a pure UEFI boot. I wouldn't > necessarily bother updating the freebsd-boot partition unless you > suspect you may need to switch back to legacy boot at some point; UEFI > is now rock-solid on all of my systems, so I've personally found no > such need and on many of them I've removed the old freebsd-boot bits. > > If you've got an ESP, you should update that manually. If you want to > maintain the option of legacy boot, you should use gpart-bootcode for > that but don't use it on the ESP with boot1.efifat. I don't know why I would. Its pretty hard to find a non-UEFI motherboard these days and, as you've said, it's been pretty solid. I don't think I said it initially, but this originally started off of 12.0 boot media (~2019/5/31), rather than me partitioning it by hand or some more modern 12.1+ stick. > > In any case, is it a logical theory that my possible boot-order problem > > is because drive order got swapped and maybe one wasn't properly updated? > > They seem to be the same: > > > > # md5 /dev/nvd[01]p2 > > MD5 (/dev/nvd0p2) = 2ded438a2c97ea551446cc2d1d3b498e > > MD5 (/dev/nvd1p2) = 2ded438a2c97ea551446cc2d1d3b498e > > > > Ideally I'd like to have not boot through the UEFI boot menu every time. > > > > I'm not sure why the drive order seems to matter right now. > > > > When you get booted back to the UEFI menu, is it a specific drive that > you must select or do both equally work from that point? My options are basically M.2_1 and M.2_2 (not sure what labeled them, I think that is the exact name, can confirm later). #2 is currently the "first" drive, and changing boot order in the BIOS to favor #1 doesn't seem to fix that. As I said, the motherboard died and the drives were moved to a new system and I suspect that the order was swapped. I never had a reason to question my ability to boot from the 2nd disk, and hadn't done anything that merited an upgrade that made me look at it this closely. Before I figured out what was going on, it would work some of the time. I suspect a race condition (where sometimes #1 would "win"), but I can't find something that makes #2 a bad initial boot disk. I don't see anything in the boot messages that say which drive it had glommed onto. I can't say that I've tried to select #2. I can try that later on today. It's doing my weekly upgrade-build right now.