From nobody Fri Aug 08 14:17:43 2025 X-Original-To: current@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 4bz5hw2dmfz63wWb for ; Fri, 08 Aug 2025 14:17:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4bz5ht2C8sz40sm for ; Fri, 08 Aug 2025 14:17:50 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org; dmarc=none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 578EHhUT010358 for ; Fri, 8 Aug 2025 14:17:43 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 578EHheh010357 for current@freebsd.org; Fri, 8 Aug 2025 07:17:43 -0700 (PDT) (envelope-from david) Date: Fri, 8 Aug 2025 07:17:43 -0700 From: David Wolfskill To: current@freebsd.org Subject: Unexpected result from "geli attach" attempt Message-ID: Mail-Followup-To: David Wolfskill , current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="csAYNpueTlrhLtv4" Content-Disposition: inline X-Spamd-Result: default: False [-5.37 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[david]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[catwhisker.org]; MLMMJ_DEST(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4bz5ht2C8sz40sm X-Spamd-Bar: ----- --csAYNpueTlrhLtv4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable TL;DR: I attempted "/sbin/geli attach -k - /dev/ada0s4j"; result was: geli: Invalid value for 'n' argument: Result too large Background: Yesterday afternoon (UTC-0700), a colleague ... mentioned =2E.. thaht after updating a machine to [that] morning's -current, he was unable to use the Yubikey (that work requires for authentication). While I had updated some machines that day, I had not attempted to do much more than an initial "smoke-test" for head/current -- I normally depend on stable (and had updated stable/14, which was working). So after today's update, I thought I would test the Yubikey under head. So after having updated my laptop from main-n279413-8ae1d55bfcd0 to main-n279471-f4744b8acb93 (which is now called "15.0-PRERELEASE" instead of "15.0-CURRENT"), I needed to mount the (GELI-encrypted) file system on my laptop that I use for work-related stuff. This is something that I have done sufficiently often that it's nearly all "muscle memory" ... in stable/14 (and earlier, in stable/12 and stable/11; probably stable/10, as well, but I wouldn't swear to it). So getting that response from the attempt was ... surprising. And I found the response singularly unhelpful: I have no idea what the source of the complaint is. I see in the code (in src/sbin/geom/core/geom.c, So after having updated my laptop from main-n279413-8ae1d55bfcd0 to main-n279471-f4744b8acb93 (which is now called "15.0-PRERELEASE" instead of "15.0-CURRENT"), I needed to mount the (GELI-encrypted) file system on my laptop that I use for work-related stuff. This is something that I have done sufficiently often that it's nearly all "muscle memory" ... in stable/14 (and earlier, in stable/12 and stable/11; probably stable/10, as well, but I wouldn't swear to it). So getting that response from the attempt was ... surprising. And I found the response singularly unhelpful: I have no idea what the source of the complaint is. I see (in src/sbin/geom/core/geom.c, in set_option()) that the message is emitted from: if (G_OPT_TYPE(opt) =3D=3D G_TYPE_NUMBER) { if (expand_number(val, &number) =3D=3D -1) { err(EXIT_FAILURE, "Invalid value for '%c' argument", opt->go_char); } May I please have the use of a clue? Peace, david --=20 David H. Wolfskill david@catwhisker.org Of course firing the statistician will force the statistics to conform! See https://www.catwhisker.org/~david/publickey.gpg for my public key. --csAYNpueTlrhLtv4 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaJYHB18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5bbhAQDJACZaHlAs8CbV1nNWuyd7yJOt/fOXujbUoUtvQLh+9QD/cL5+hD/3Rily JG+PppZGjobqJhFwiECmcRSq+9zergk= =S7yB -----END PGP SIGNATURE----- --csAYNpueTlrhLtv4--