Date: Tue, 14 Jul 2020 07:58:47 -0700 From: John Kennedy <warlock@phouka.net> To: Kyle Evans <kevans@freebsd.org> Cc: Guido van Rooij <guido@gvr.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a Message-ID: <20200714145847.GB11731@phouka1.phouka.net> In-Reply-To: <CACNAnaG3yiZmzHJgRyqVr7JdCuadvzztrVXmXYNCfx0ctbvGww@mail.gmail.com> References: <20200709131201.GA3464@co.gvr.org> <CACNAnaGbCknS18yLv1ow2FFnj5xSMHXQZgxfRPMUMTb5ujB=fw@mail.gmail.com> <20200709211854.GA11731@phouka1.phouka.net> <CACNAnaG3yiZmzHJgRyqVr7JdCuadvzztrVXmXYNCfx0ctbvGww@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200714145847.GB11731>