From nobody Mon Jun 26 17:13:26 2023 X-Original-To: freebsd-fs@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 4QqZDy1326z4kMWn for ; Mon, 26 Jun 2023 17:13:38 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QqZDx38Jmz3HB0 for ; Mon, 26 Jun 2023 17:13:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D2BB28D4A17C; Mon, 26 Jun 2023 17:13:29 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C4DDF5C3A831; Mon, 26 Jun 2023 17:13:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id V8bNpgNn8bqH; Mon, 26 Jun 2023 17:13:27 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 922425C3A82F; Mon, 26 Jun 2023 17:13:27 +0000 (UTC) Date: Mon, 26 Jun 2023 17:13:26 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: freebsd-fs@freebsd.org Subject: Re: nvd -> nda change (breaks geli)? In-Reply-To: Message-ID: <53o9rrr4-83op-9q4q-s26s-1on9n6r85117@yvfgf.mnoonqbm.arg> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1098556516-916571740-1687799607=:31353" X-Rspamd-Queue-Id: 4QqZDx38Jmz3HB0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-916571740-1687799607=:31353 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 26 Jun 2023, Warner Losh wrote: > On Mon, Jun 26, 2023 at 10:01 AM Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> Hi, >> >> some laptops had only /dev/nvd* nodes in the past. >> These now show up as /dev/nda*. >> Not sure when the symlinks are created for compat. >> >> I had to help rescue someone's geli setup manually as there were >> no keys loaded for nda but only for nvd. At least loading the key >> again for nda made things work. A bit painful remotely ... >> >> Should this at least be in UPDATING? >> > > Well, we have this already: > > 20230612: Doh! I think I looked in the wrong tree. Sorry. > Can you send me more details about what failed? It should be a no-op, but I > am > aware of one issue with libgeom that I need to fix. The change was to switch: geli_nvd0p2_keyfile0_load="YES" geli_nvd0p2_keyfile0_type="nvd0p2:geli_keyfile0" geli_nvd0p2_keyfile0_name="/boot/keys/geli.key" to this: geli_nda0p2_keyfile0_load="YES" geli_nda0p2_keyfile0_type="nda0p2:geli_keyfile0" geli_nda0p2_keyfile0_name="/boot/keys/geli.key" in loader.conf and things worked again. Not sure if this is really needed or the right fix but that's as much as I got remotely. -- Bjoern A. Zeeb r15:7 --1098556516-916571740-1687799607=:31353--