From nobody Wed Mar 22 20:56:55 2023 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Phgl52L2cz41J23 for ; Wed, 22 Mar 2023 20:57:05 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from mta01.start.ca (mta01.start.ca [162.250.196.97]) (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 "mail.start.ca", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Phgl425Dsz3FCh for ; Wed, 22 Mar 2023 20:57:04 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of 482254ac@razorfever.net designates 162.250.196.97 as permitted sender) smtp.mailfrom=482254ac@razorfever.net; dmarc=none Received: from mta01.start.ca (localhost [127.0.0.1]) by mta01.start.ca (Postfix) with ESMTP id 171A621473 for ; Wed, 22 Mar 2023 16:56:57 -0400 (EDT) Received: from mail.razorfever.net (unknown [45.59.188.50]) by mta01.start.ca (Postfix) with ESMTPSA id 064F621471 for ; Wed, 22 Mar 2023 16:56:56 -0400 (EDT) Received: from [192.168.0.33] (bock.razorfever.net [192.168.0.33]) by mail.razorfever.net (8.15.2/8.15.2) with ESMTP id 32MKutqt008757 for ; Wed, 22 Mar 2023 16:56:55 -0400 (EDT) (envelope-from 482254ac@razorfever.net) X-Authentication-Warning: mail.razorfever.net: Host bock.razorfever.net [192.168.0.33] claimed to be [192.168.0.33] Message-ID: Date: Wed, 22 Mar 2023 16:56:55 -0400 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: FreeBSD Mailing List From: "Derek (freebsd lists)" <482254ac@razorfever.net> Subject: Current best practices: UEFI boot on zfsboot nvme raid? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, FROM_STARTS_WITH_NUMS,RP_MATCHES_RCVD autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.razorfever.net X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-2.21 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.92)[-0.916]; R_SPF_ALLOW(-0.20)[+ip4:162.250.196.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[razorfever.net]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:40788, ipnet:162.250.196.0/22, country:CA]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Phgl425Dsz3FCh X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N Hiya, Wondering what current best practices (13.1-RELEASE) are to make sure a zfsroot UEFI-boot system with a failed boot disk still boots, given the need to have a partition with an msdos filesystem to boot? My first take is that I'll need to manually update each disks' efi code whenever /boot/loader.efi is updated, including after directly after a fresh installation? Something that is irking me though, is that a device name is also hard-coded into /etc/fstab, so if the drive fails, a mounted filesystem also breaks. I don't see how this can be a good thing, and will also interfere with a clean reboot, even if the boot code exists elsewhere. My guess is, like swap, it might be possible to gmirror across my RAID this filesystem and remove all of these considerations. Is this the best practice? I originally tried to revert to BIOS boot where I wouldn't have these concerns, but was unsuccessful at getting my nvme devices to boot. Thoughts appreciated! Derek