Date: Fri, 8 Aug 2025 07:17:43 -0700 From: David Wolfskill <david@catwhisker.org> To: current@freebsd.org Subject: Unexpected result from "geli attach" attempt Message-ID: <aJYHB48RM2w7Tmea@albert.catwhisker.org>
index | next in thread | raw e-mail
[-- Attachment #1 --]
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
... 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) == G_TYPE_NUMBER) {
if (expand_number(val, &number) == -1) {
err(EXIT_FAILURE, "Invalid value for '%c' argument",
opt->go_char);
}
May I please have the use of a clue?
Peace,
david
--
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.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaJYHB18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy
RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx
5bbhAQDJACZaHlAs8CbV1nNWuyd7yJOt/fOXujbUoUtvQLh+9QD/cL5+hD/3Rily
JG+PppZGjobqJhFwiECmcRSq+9zergk=
=S7yB
-----END PGP SIGNATURE-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aJYHB48RM2w7Tmea>
