From nobody Mon Sep 1 00:01:28 2025 X-Original-To: freebsd-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 4cFTYh46cTz65N9m; Mon, 01 Sep 2025 00:01:28 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFTYh3PyJz4GcD; Mon, 01 Sep 2025 00:01:28 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756684888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=GqnjX5wO3V1OMET4a3AkNWtv954YwRpHfUSTPNCamc4=; b=KdmWVtrklc4myIUvqAPxWWfOFZf3K4l1TeTRAIlMf47tn8t4gZPHVZ+9t+Dagff1/WDWgi I5O0I0pLPmqwZb6u/H0TKl3F90KIB05861wUCH+BaJYWwOvqiuZbqWmviaVg0gpzu0JpUT F938uFqxzEeJ0k0XZSEUQWTO07YO5OMfvHW6smusOOkQ1mBm5fkMHjNof4AodC0fHAeRJv YnO0RZoMrIhIyOPIHB31kI1nLJ6RrUfqo4KysKUCDgc/U5IYF3HSS13J816/HUPMKYIYOA l+JVuWnjfeDlEnNLZIyihyYmBimACbB6JpmmdWuSiPI2vnzSKeMnYE2uDHihlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756684888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=GqnjX5wO3V1OMET4a3AkNWtv954YwRpHfUSTPNCamc4=; b=BLp8VuYelR7dbfEmK177Aae1YmHEVidQSjFh/696604DhvW+J6Jx1MnaTbM6SnIo+Nfp4Q 566i75pXFXuwmZdGaOb2C7t0CtZfVLK/UhzQG4dlqoOYbuNo+7IcrSCeoL3ITWddSvnj2C aMfQPrtSz5XdH87yYfC+0FPCO+chgJvUPGZHtBjgRUXg5tnnEuZBDLY8ddSHFiYTOzZsqa 2n1Hhh0qQNR+SpoMstms7u3M2KPbaez8kxRsqmGh07LUcMUmPCZtfdE5oBnxP8pGK0joQE TUdjES6MsgS5cpuCJ5wfx62BFHmj7NXXD74C86HO3AHAU4OI3h1f7QMfjJSKpA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756684888; a=rsa-sha256; cv=none; b=e26qQgeEe/J3Tcn6RwVV2fCglA2QZxQbuZEvf1qRyEAFjKysA7h/Fc5ZB/glXdFHFbgIbE vufIBwxFwwSOyPm92xDEvkAM/bJaBRY6qpH7cAzts6ijtchcl0rtNgSYbeJKGD7/V1cgzm wQ1lYKDrAsLHXI98QNHDGTa68PATqH1p2scNMFYJBJHCG0cEf1DPmZldUTINAE4nT9h0hH X7tDANGOHhPe75el9YfNbt8zOixH7SiBcq0YWOH4h6e7vIIHHijKnHVDphQ/TtyECdlFul FWap8cich6Vt36A8wUGG2u4DMJev8tcLey3yfipWwh+oRfVzZBjfhAMpqDVLMQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1472) id 2496B4643; Mon, 01 Sep 2025 00:01:28 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: Call for 2025Q3 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20250901000128.2496B4643@freefall.freebsd.org> Date: Mon, 01 Sep 2025 00:01:28 +0000 (UTC) From: Lorenzo Salvadore 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 Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is September, 30th 2025 for work done since the last round of quarterly reports: July 2025 - September 2025. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2025-07-2025-09/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2025-07-2025-09/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2025Q3 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Mon Sep 1 00:41:45 2025 X-Original-To: freebsd-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 4cFVSZ5SQ9z65S5b for ; Mon, 01 Sep 2025 00:42:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFVSZ02yFz4Mg5; Mon, 01 Sep 2025 00:42:05 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DNr1Jf3E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61cb4374d2fso5312637a12.2; Sun, 31 Aug 2025 17:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756687318; x=1757292118; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QT2RAk2cN+XkoS6hsh8ecS70ykt3m3+EtxtglhBTySo=; b=DNr1Jf3Ez6+zjzo7P8stUIbHniSHMds4NmevdcDAhDWJ9PnmKZlVxnlRqF2IenFeBf E2gJuuEvU4VbF7SYB3KaRFHgIOSZU/ffIK19yD55Hrx4TOt53QQGtswKrzkW70qDKB28 kAHanOj/LOX0bVX4MkjttBvJMQWY9K3hmqVQi+CSr9FgpQWlA1/kFPiklcX9t5yzUN+/ KmqNmINMNwuIUc9c/O8DEM/ykj7uH+1jDgGQNLPkqPVefzDcM1zawjiN82VBGApefnqS ev/16bRe2sqljctszZbyL1u3adxDV7C/+XDtpMYy/I6cm9mMSXNnzrDM4z1AcdxNv+F9 U8IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756687318; x=1757292118; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QT2RAk2cN+XkoS6hsh8ecS70ykt3m3+EtxtglhBTySo=; b=JWiB39w0nFANhFprFXOISBO7CAogAOeELrK+frx+3a/2Vq/EF10mSnejIZO4yzYzzA fbUIIvoRN2H5HCHl2MqlFizEoFl1douyzve//vvI3AioTdQz7z1tfQv/NkqphcPAx24E uEqTHgPyIb87LcmJNtmm8P5BEtaSkECGfYsAZlDdfkFhR9gWMU96R4dDR3O9x26/I1Hm 1PPCrXlqk6uGLO8rRPy6ot31fNCzEMZ1xhgZ0OaM9XX8LU4DW0B4BEZvMHw3xEqiX+ar mtw692fekH1N9pGUrUpSY3HYcE2eq5qipV/a3OtH6mKizgk5hvA+bk8rZIWBYKH1FB3Z 5qmQ== X-Forwarded-Encrypted: i=1; AJvYcCVUDqHNcwikHMMRdAufD0X21LCRe3BfjGS1+aTxChMQNyYvMy5BTDYXWZOs3lDiCNWEz2OKkEERKmGj94Bdk7E=@freebsd.org X-Gm-Message-State: AOJu0YzBshES7d4FvbNracFh23KismAGCbf9JGDaG3OQnuLPzTBVFYFe jn0OBPkKAsmtH7LN7nPutDa3Tx0G5x1Tal/dph2QZ+9LipRWja/IRpA31X73H1OXSs5TusxIdFf TmGIinTGhQQp4NF5taS2y7uiboRZtLLu9UzM= X-Gm-Gg: ASbGnct2JcJzdxCwoGKi9vQtNMuyCYDB7yviVCFF5r7Cz21OJ5QMQlpHaSrHnc/Q86T pVOM2w95YpSe+vmv9+2r+y+2YlQ7B7FQs2WiEwmzq/Otm1vhTaVRMkSt9YxtMBXOOjNY3wxN6mV 8bWiQULvFMNrWJJK+G4L2hGjJ4HevG3mqr3UkLjng3qRAozN1FJaIa9nrekreK4E27E91w1Scyf /tK5HmPP5RZuzpqc3NY5hjNEOXk6+t13FXyL+Ih/quZd1TDSA== X-Google-Smtp-Source: AGHT+IFGCH02Iy92hGbSSKa0zMs2+jAaEIuXv9LKNd/wK8lQ6qIywwdX6Ru9io6fN2Bpk6oScuZ5v9KWAXFJVwnCfQQ= X-Received: by 2002:a05:6402:51c8:b0:61e:3b86:aaba with SMTP id 4fb4d7f45d1cf-61e3b86ab31mr2781085a12.30.1756687317394; Sun, 31 Aug 2025 17:41:57 -0700 (PDT) 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 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Sun, 31 Aug 2025 17:41:45 -0700 X-Gm-Features: Ac12FXxvp3Awea9-fovvi3JrzHpW4OJevPMAQjOqkW96Elb3s2WyZDjnC3n8O1c Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="000000000000898d10063db2a36f" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cFVSZ02yFz4Mg5 --000000000000898d10063db2a36f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 30, 2025 at 9:47=E2=80=AFPM Rick Macklem wrote: > > On Sat, Aug 30, 2025 at 4:22=E2=80=AFPM Rick Macklem wrote: > > > > On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem wrote: > > > > > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wro= te: > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem w= rote: > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install= heimdal", you get a > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > T> R> > > > > > > > > T> R> Now, I have another challenge. Fixing the master pass= words. > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > T> > > > > > > > > T> I have applied two commits from Heimdal from 2012 that a= dd 'kadmin dump -f MIT' > > > > > > > > T> feature to our base heimdal and polished them to compile= . So far it doesn't > > > > > > > > T> work yet, either create an empty dump or create a core d= ump, instead of > > > > > > > > T> database dump :) I'll see how difficult it is going to f= urther resolve that to > > > > > > > > T> a working condition. If I succeed, then having 'dump -f = MIT' in base without > > > > > > > > T> any ports would be the best solution. Can also be merge= d to FreeBSD 14.4. > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my change = incorrectly - threw > > > > > > > > the new binary on a system running unpatched libraries. Wh= en run correctly, > > > > > > > > it successfully produced something that looks like a correc= t dump in MIT format. > > > > > > > > I haven't yet tried to load it into MIT kdc yet, though. > > Well, would you like the not so bad news or the bad news??;-) > > Your patch works, in that it produces a dump that "kdb5_util load > > -update" can load. > > After loading, if the principal only has keys for the newer encryption = types of > > aes256-cts-hmac-sha1-96 > > aes128-cts-hmac-sha1-96 > > then you can look at the principal via kadmin.local, but the password m= ust > > be changed before it works. > > --> This is the same behaviour as you get if you use Heimdal-7.8 to do = the > > dump conversion. > > So far, so good... > > > > Now, the not so good news. Once you update the Heimdal libraries > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the system > > running the old KDC. "kadmin -l dump" works, but something like: > > # kadmin -l > > kadmin> get rmacklem > > kadmin: get rmacklem: Service key not available > > - I have not yet looked in your patched sources to see where this > > failure comes from? > > > > Now, more not so good news... > > My patch doesn't help. > > It does re-encrypt the key in the master key from the MIT KDC > > system, but that doesn't make the password work. > > When I compared the dump generated via kadmin with both > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > is 34bytes long. > > After doing the change_password so that it works, a dump > > generated by "kdb5_util dump -r13" (the same dump format) > > has a key that is 62bytes long. > > --> So, there is more to converting the key than just re-ecrypting > > it. (I'll try and find where the MIT code encrypts a key in a mas= ter > > key to see why it ends up at 62bytes and whether that can be done > > in the old code.) > > > > So, if we are going to continue with this... > > - We need to figure out why your patch breaks "kadmin" for other > > things and fix that. > > - I/we need to figure out how to convert the 34byte key to the MIT > > 62byte key (and then maybe the password won't need to be changed?). > > > > Or do we just say "When you convert the KDC database, all the passwords > > must be changed to get them to work?". > All I've got sofar is this patch... > https://people.freebsd.org/~rmacklem/print.patch > > It tweaks entry2mit_string_int() so that it skips over the keys for > old encryption types and fills in a fake "modified by" entry if none > exists. > > These changes at least make the MIT dump such that the records > don't end up "incomplete or corrupted" when you try to do something > like "get_principal " in kadmin.local. > > As noted, your patch makes "kadmin -l" break for most things, > reporting "Service key not available". The failures go away if > you revert back to the non-patched libraries. > I have not located the problem yet. > > As for the passwords...no luck yet, rick Finally..it works. (First off, apologies for all the posts, just ignore them.;-) The patch is at: https://people.freebsd.org/~rmacklem/kadmin.patch It goes on top of glebius@'s kadmin-dump-MIT branch of https://github.com/glebius/FreeBSD. Once built with "WITHOUT_MITKRB5=3D"yes" in /etc/src.conf and installed, there is a new option for "kadmin -l dump" called "-f" and my patch modifies "-f" so it can take a filename instead of "MIT" or "Heimdal". Here's how you test it (once your Heimdal KDC system has been patched): On the MIT KDC system: # mkdir /var/db/krb5kdc <-- maybe the installer should do this? - copy kdc.conf and kadm5.acl into this directory and edit them for your Realm, etc. - copy an MIT krb5.conf in /etc/krb5.conf and edit this one as well. (I've attached the three files I use as very basic examples.) Once you've done this: # kdb5_util create -s should work. Now, copy /var/db/krb5kdc/.k5.YOUR.REALM over to the Heimdal KDC system. Then go to the Heimdal KDC system and... # kadmin -l dump -f .k5.YOUR.REALM mit.dump Now, copy mit.dump over to the MIT KDC system and on the MIT KDC system... # kdb5_util load -update mit.dump And, at least if the principals on the Heimdal KDC have keys for at least one of: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 they should work. For principals that do not have keys for either of the above two etypes, you should still be able to see the principal via "get_principal " in kadmin.local. If you can see it, a change_password in kadmin.local should get it working. Hopefully people with Heimdal KDCs can test this? rick > > > > > > rick > > > > > > > > Oh, and one more thing... > > > > > > - If there are keys for old encryption types like des.. or arcf= our.. > > > > > > in the MIT dump, > > > > > > those will screw up the load. (You can check and delete them = in the > > > > > > Heimdal-1.5.2 > > > > > > kdc system via.. > > > > > > # kadmin -l > > > > > > get > > > > > > - if old keys are listed in Keytypes: > > > > > > del_enctype > > > > > > exit > > > > > > > > > > > > Ideally the conversion code would skip over these and not put = them in the dump. > > > > > > > > > > > > rick > > > > > > ps: If you don't do this, when you "get_principal" in kadmin.lo= cal on > > > > > > the MIT KDC > > > > > > system, it will give you a "Database record is incomplete= or corrupted..". > > > > > > > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The abov= e experience also > > > > > > > > indicated that I need to do a library version bump. > > > > > > > I don't know if you are enthusiastic about pursuing this, but= hopefully this > > > > > > > works and gets the principals in (although I doubt the passwo= rds will > > > > > > > work without changing them). > > > > > > > > > > > > > > To get the passwords to work, I think the following *might* d= o it: > > > > > > > - If you look in the Heimdal sources, when "--decrypt" is spe= cified, > > > > > > > I think it finds its way down into a function called hdb_un= seal_key_mkey() > > > > > > > which decrypts the key using the master key by calling _hdb= _mkey_decrypt(). > > > > > > > To get the passwords to work, I think the call to _hdb_mkey= _decrypt() would > > > > > > > need to be followed by a call to _hdb_mkey_encrypt() with t= he "key" > > > > > > > argument being the master key for the MIT database. (It it = a keytab > > > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when yo= u do a > > > > > > > "kdb5_util create -s" on the system that will be the MIT KD= C.) > > > > > > > - Just to make it even more fun, there is a flag called HDB= _KU_MKEY > > > > > > > which is set to the Heimdal way and not for the MIT way (= whatever > > > > > > > that really means?). > > > > > > > - There is also some stuff about padding in hdb_unseal_key_= mkey(), > > > > > > > but hopefully that won't be a problem? > > > > > > > > > > > > > > I think hdb_read_master_key() can be used to read in the MIT = master > > > > > > > key from the file you provide as an argument to it. > > > > > > > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > > > > > > > I'll admit since the hardware I have takes forever to "make b= uildworld" > > > > > > > and I don't know a quick way to build/test these changes, I'm= not > > > > > > > inspired to try it. > > > > > Although not inspired, I have taken a stab at it. > > > > > I am still trying to figure out how to build/test it, but I have = forked > > > > > glebius@'s github and added some code to... > > > > > - Not dump the weak encryption keys (they just cause MIT's kadmin= .local > > > > > to complain that the principal's database entry is corrupted. > > > > > - If the argument to "kadmin -l dump" is "-f " instead > > > > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I hop= e that will > > > > > make the passwords work. > > > > > (Basically, someone will "kdb5_util create -s" on the MIT KDC s= ystem > > > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to t= he > > > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mi= t.dump" > > > > > then copy "mit.dump" over to the MIT KDC system and > > > > > "kdb5_util load -update mit.dump". Then, hopefully, the princi= pals will > > > > > work??) > > > > > > > > > > Anyhow, it is currently sitting here: > > > > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > > > > (I'm as unconversant with git and github as anyone, so if you hav= e > > > > > trouble finding it, just let me know.) > > > > Actually, it hasn't made it there yet. For some reason (I think it = is > > > > glebius@s large # of branches) it takes a very long time to "git pu= sh" > > > > a patch involving 4 files. It failed after over an hour with an une= xpected > > > > TCP disconnect. I am running it again. > > > > > > > > I will stick the patch here, in case the push fails again. > > > > (It needs to be applied on top of glebius@'s kadmin-dump-MIT branch= . > > > The patch is here. (For some reason, I couldn't push so I deleted the > > > github fork.) > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > > > > I haven't yet been able to test it, but will be able to do so later t= o-day, rick > > > > > > > > > > > Meanwhile I've given up trying to build it on a universe system and > > > > an now trying the "make buildworld" locally. This will take days, > > > > so I guess I'll go do something else.;-) > > > > > > > > rick > > > > > > > > > > > > > > I'll keep updating this github fork as I get to test it, but if o= thers > > > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Gleb Smirnoff --000000000000898d10063db2a36f Content-Type: application/octet-stream; name="kadm5.acl" Content-Disposition: attachment; filename="kadm5.acl" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf0e8riu0 Ki9hZG1pbkBIT01FLlJJQ0sJKgo= --000000000000898d10063db2a36f Content-Type: application/octet-stream; name="krb5.conf" Content-Disposition: attachment; filename="krb5.conf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf0e93d01 W2xpYmRlZmF1bHRzXQoJZGVmYXVsdF9yZWFsbSA9IEhPTUUuUklDSwoKW3JlYWxtc10KCUhPTUUu UklDSyA9IHsKCQlrZGMgPSAxOTIuMTY4LjEuMTUKCQlhZG1pbl9zZXJ2ZXIgPSAxOTIuMTY4LjEu MTUKCX0KCltkb21haW5fcmVhbG1dCgkuaG9tZS5yaWNrID0gSE9NRS5SSUNLCgpbbG9nZ2luZ10K CWtkYyA9IEZJTEU6L3Zhci9sb2cva3JiNWtkYy5sb2cKCWFkbWluX3NlcnZlciA9IEZJTEU6L3Zh ci9sb2cva2FkbWluLmxvZwoJZGVmYXVsdCA9IEZJTEU6L3Zhci9sb2cva3JiNWxpYi5sb2cKCg== --000000000000898d10063db2a36f Content-Type: application/octet-stream; name="kdc.conf" Content-Disposition: attachment; filename="kdc.conf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf0e9fki2 W2tkY2RlZmF1bHRzXQoJa2RjX2xpc3RlbiA9IDg4CglrZGNfdGNwX2xpc3RlbiA9IDg4CglkZWZh dWx0X3JlYWxtID0gSE9NRS5SSUNLCgpbcmVhbG1zXQoJSE9NRS5SSUNLID0gewoJCWRhdGFiYXNl X25hbWUgPSAvdmFyL2RiL2tyYjVrZGMvcHJpbmNpcGFsCgkJYWNsX2ZpbGUgPSAvdmFyL2RiL2ty YjVrZGMva2FkbTUuYWNsCgkJa2V5X3N0YXNoX2ZpbGUgPSAvdmFyL2RiL2tyYjVrZGMvLms1LkhP TUUuUklDSwoJCWtkY19saXN0ZW4gPSA4OAoJCWtkY190Y3BfbGlzdGVuID0gODgKCQltYXhfbGlm ZSA9IDEwaCAwbSAwcwoJCW1heF9yZW5ld2FibGVfbGlmZSA9IDdkIDBoIDBtIDBzCgl9Cg== --000000000000898d10063db2a36f-- From nobody Mon Sep 1 00:58:40 2025 X-Original-To: freebsd-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 4cFVr40tmbz65T5W for ; Mon, 01 Sep 2025 00:59:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFVr334j9z4PcT; Mon, 01 Sep 2025 00:58:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="C4GB/C4K"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-6188b5ad4f0so4967663a12.0; Sun, 31 Aug 2025 17:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756688333; x=1757293133; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RsDA0Gd/BPYH72IV0x+kMgqdbZSmyJPPBHdeYpaJExQ=; b=C4GB/C4K+zWfILUU9w7KmeZuRITtIGWEDM9Zixji0mTkt+aFNWqOfbAM5T00S+7Uag A3AcdqxxDOo+V1zSIfLYTX6/plOFOSSUpiytTME4+nXY0bEzWH4QcyyJ+Uh7oLV+rkWM 3KCIGOD6wliG1xo22RH/TDfZ6UAC8vF6rnOhYjcyiVwboRrfBBiDRiT7sTxews3ml5SU IbU7TUmrRm2mlMyUNI0JvISkUSlZgpPGMnNouw1X4P3P2Fbijluv3SUYYXgq2AGmDy+P GEFBdnlVfwehllP8H7MeXfBFJtp0zDjq8OcbsDD2P46idBjOU/IQ+rMew0G3qv9G2G/k sxkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756688333; x=1757293133; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RsDA0Gd/BPYH72IV0x+kMgqdbZSmyJPPBHdeYpaJExQ=; b=R/YbGlQ6xCNDfhR+zaM98fTN9PYRpWiapzAntlGfpw37YwywwxrXcIulqgGMqpyHE1 Njg9T26nC/ApFE10hwzTvnjy4eCB6kJm7LJHnK4m8xxbl/dumcK6trtszI8lQT//4rVX p/FmE7RsPH+WZAQPBH5omehyzMJtKaaZ9xYNhNHLT+7LDZvnaIPconhiiF3/7GthLKLl AOjUfL01p4K7/XejyEERBSCS/v0+mKCwfouyzr0WAToRfWYzk0uLDRGH5zyFZso2qwDR Aa3HG/EQmP0EGsuapxvwfXWS4/SKBaINBhtRMyiJQRL/Ikh8n+TNXLLbRTEFf5xImspQ J+/A== X-Forwarded-Encrypted: i=1; AJvYcCXGM8VUcBfaq/dvs2wxy9dbQYe0wCrVBAlMmdEGje6Vm1vfKo4M+O/oPMny2zPL9O1kyBoGrFMYQgymeC+0EkY=@freebsd.org X-Gm-Message-State: AOJu0Yybx0BYGDzDMM4tnX92jkUDSj8P7j1GD18GkFVaJ+k8hbS0huw1 6OJK6Hxb+mECKMiIcJd/2dhIv/b0RueXGQp11buVbKeASUvf3FmnFSvAj6xMq14dUsNJ3g+BlXm 8fo6qFkkYT8KF2Q7Txg91qJGCjSX0g9MZ X-Gm-Gg: ASbGncsO/2XT9UbsVkUNjdlF+rwdoXIbEoDnevsJaekCKEOoCEj9bkb9Uq1dGeJcRjX JPMFtzF5DU3NDuIxCts7MQf3dqI1H06y0C/waQcT0xWTY6t9N/Pa5Z5DpUMGVVrLtGWMunEt20/ tWNczFvHxMIOV19SBToucWVlq7yW1+YdtndjgT/zhuhGWsg/tQBylnOtTjikrgIQeT0sUdNzoLx 4dkfhAaihK80UOO2qf8IVaOklssftIMOsoqzTl47HLdBMDT8w== X-Google-Smtp-Source: AGHT+IHjvqG9piytpNS1Y/uKgmUzBH3DvtAoyqxs5RVQ+R/dpKZJBb5enG67v0rpcjcS39k2Aahi3vfE4QbPlKY77mI= X-Received: by 2002:a05:6402:5252:b0:61d:12df:75c7 with SMTP id 4fb4d7f45d1cf-61d26ec99d9mr5659429a12.35.1756688332497; Sun, 31 Aug 2025 17:58:52 -0700 (PDT) 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 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Sun, 31 Aug 2025 17:58:40 -0700 X-Gm-Features: Ac12FXwf7ywG04qM3PavrWluHLw7W7qivrrf-exg79Px8ZKgdGG3ObGaO79Ttn4 Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cFVr334j9z4PcT On Sun, Aug 31, 2025 at 5:41=E2=80=AFPM Rick Macklem wrote: > > On Sat, Aug 30, 2025 at 9:47=E2=80=AFPM Rick Macklem wrote: > > > > On Sat, Aug 30, 2025 at 4:22=E2=80=AFPM Rick Macklem wrote: > > > > > > On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem wrote: > > > > > > > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff w= rote: > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem= wrote: > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg insta= ll heimdal", you get a > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > T> R> > > > > > > > > > T> R> Now, I have another challenge. Fixing the master pa= sswords. > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > T> > > > > > > > > > T> I have applied two commits from Heimdal from 2012 that= add 'kadmin dump -f MIT' > > > > > > > > > T> feature to our base heimdal and polished them to compi= le. So far it doesn't > > > > > > > > > T> work yet, either create an empty dump or create a core= dump, instead of > > > > > > > > > T> database dump :) I'll see how difficult it is going to= further resolve that to > > > > > > > > > T> a working condition. If I succeed, then having 'dump -= f MIT' in base without > > > > > > > > > T> any ports would be the best solution. Can also be mer= ged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my chang= e incorrectly - threw > > > > > > > > > the new binary on a system running unpatched libraries. = When run correctly, > > > > > > > > > it successfully produced something that looks like a corr= ect dump in MIT format. > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, though. > > > Well, would you like the not so bad news or the bad news??;-) > > > Your patch works, in that it produces a dump that "kdb5_util load > > > -update" can load. > > > After loading, if the principal only has keys for the newer encryptio= n types of > > > aes256-cts-hmac-sha1-96 > > > aes128-cts-hmac-sha1-96 > > > then you can look at the principal via kadmin.local, but the password= must > > > be changed before it works. > > > --> This is the same behaviour as you get if you use Heimdal-7.8 to d= o the > > > dump conversion. > > > So far, so good... > > > > > > Now, the not so good news. Once you update the Heimdal libraries > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the system > > > running the old KDC. "kadmin -l dump" works, but something like: > > > # kadmin -l > > > kadmin> get rmacklem > > > kadmin: get rmacklem: Service key not available > > > - I have not yet looked in your patched sources to see where this > > > failure comes from? > > > > > > Now, more not so good news... > > > My patch doesn't help. > > > It does re-encrypt the key in the master key from the MIT KDC > > > system, but that doesn't make the password work. > > > When I compared the dump generated via kadmin with both > > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > > is 34bytes long. > > > After doing the change_password so that it works, a dump > > > generated by "kdb5_util dump -r13" (the same dump format) > > > has a key that is 62bytes long. > > > --> So, there is more to converting the key than just re-ecrypting > > > it. (I'll try and find where the MIT code encrypts a key in a m= aster > > > key to see why it ends up at 62bytes and whether that can be do= ne > > > in the old code.) > > > > > > So, if we are going to continue with this... > > > - We need to figure out why your patch breaks "kadmin" for other > > > things and fix that. > > > - I/we need to figure out how to convert the 34byte key to the MIT > > > 62byte key (and then maybe the password won't need to be changed?). > > > > > > Or do we just say "When you convert the KDC database, all the passwor= ds > > > must be changed to get them to work?". > > All I've got sofar is this patch... > > https://people.freebsd.org/~rmacklem/print.patch > > > > It tweaks entry2mit_string_int() so that it skips over the keys for > > old encryption types and fills in a fake "modified by" entry if none > > exists. > > > > These changes at least make the MIT dump such that the records > > don't end up "incomplete or corrupted" when you try to do something > > like "get_principal " in kadmin.local. > > > > As noted, your patch makes "kadmin -l" break for most things, > > reporting "Service key not available". The failures go away if > > you revert back to the non-patched libraries. > > I have not located the problem yet. > > > > As for the passwords...no luck yet, rick > Finally..it works. (First off, apologies for all the posts, just ignore > them.;-) > > The patch is at: > https://people.freebsd.org/~rmacklem/kadmin.patch > > It goes on top of glebius@'s kadmin-dump-MIT branch of > https://github.com/glebius/FreeBSD. > > Once built with "WITHOUT_MITKRB5=3D"yes" in /etc/src.conf > and installed, there is a new option for "kadmin -l dump" called > "-f" and my patch modifies "-f" so it can take a filename instead > of "MIT" or "Heimdal". > > Here's how you test it (once your Heimdal KDC system has > been patched): > On the MIT KDC system: > # mkdir /var/db/krb5kdc <-- maybe the installer should do this? > - copy kdc.conf and kadm5.acl into this directory and edit them > for your Realm, etc. > - copy an MIT krb5.conf in /etc/krb5.conf and edit this one as well. > (I've attached the three files I use as very basic examples.) > Once you've done this: > # kdb5_util create -s > should work. > > Now, copy /var/db/krb5kdc/.k5.YOUR.REALM over to the > Heimdal KDC system. > Then go to the Heimdal KDC system and... > # kadmin -l dump -f .k5.YOUR.REALM mit.dump > Now, copy mit.dump over to the MIT KDC system and > on the MIT KDC system... > # kdb5_util load -update mit.dump > > And, at least if the principals on the Heimdal KDC > have keys for at least one of: > aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 > they should work. Maybe there should be an additional option on "kadmin -l dump" that allows weak encryption keys through. (I'm not sure if you can still enable them in the MIT KDC?) This is a little more work than it sounds, since you need to pass the info into entry2mit_string_int() and it currently does not have any argument for stuff like flags. The problem is that, if you let them through (as in onto the mit.dump) and they are not enabled for the KDC, kadmin.local will report the principal entry as "incomplete or corrupted" and you cannot do anything with it. rick > > For principals that do not have keys for either of > the above two etypes, you should still be able to > see the principal via "get_principal " in > kadmin.local. > If you can see it, a change_password in kadmin.local > should get it working. > > Hopefully people with Heimdal KDCs can test this? > > rick > > > > > > > > > > > > rick > > > > > > > > > > Oh, and one more thing... > > > > > > > - If there are keys for old encryption types like des.. or ar= cfour.. > > > > > > > in the MIT dump, > > > > > > > those will screw up the load. (You can check and delete the= m in the > > > > > > > Heimdal-1.5.2 > > > > > > > kdc system via.. > > > > > > > # kadmin -l > > > > > > > get > > > > > > > - if old keys are listed in Keytypes: > > > > > > > del_enctype > > > > > > > exit > > > > > > > > > > > > > > Ideally the conversion code would skip over these and not pu= t them in the dump. > > > > > > > > > > > > > > rick > > > > > > > ps: If you don't do this, when you "get_principal" in kadmin.= local on > > > > > > > the MIT KDC > > > > > > > system, it will give you a "Database record is incomple= te or corrupted..". > > > > > > > > > > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The ab= ove experience also > > > > > > > > > indicated that I need to do a library version bump. > > > > > > > > I don't know if you are enthusiastic about pursuing this, b= ut hopefully this > > > > > > > > works and gets the principals in (although I doubt the pass= words will > > > > > > > > work without changing them). > > > > > > > > > > > > > > > > To get the passwords to work, I think the following *might*= do it: > > > > > > > > - If you look in the Heimdal sources, when "--decrypt" is s= pecified, > > > > > > > > I think it finds its way down into a function called hdb_= unseal_key_mkey() > > > > > > > > which decrypts the key using the master key by calling _h= db_mkey_decrypt(). > > > > > > > > To get the passwords to work, I think the call to _hdb_mk= ey_decrypt() would > > > > > > > > need to be followed by a call to _hdb_mkey_encrypt() with= the "key" > > > > > > > > argument being the master key for the MIT database. (It i= t a keytab > > > > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when = you do a > > > > > > > > "kdb5_util create -s" on the system that will be the MIT = KDC.) > > > > > > > > - Just to make it even more fun, there is a flag called H= DB_KU_MKEY > > > > > > > > which is set to the Heimdal way and not for the MIT way= (whatever > > > > > > > > that really means?). > > > > > > > > - There is also some stuff about padding in hdb_unseal_ke= y_mkey(), > > > > > > > > but hopefully that won't be a problem? > > > > > > > > > > > > > > > > I think hdb_read_master_key() can be used to read in the MI= T master > > > > > > > > key from the file you provide as an argument to it. > > > > > > > > > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > > > > > > > > > I'll admit since the hardware I have takes forever to "make= buildworld" > > > > > > > > and I don't know a quick way to build/test these changes, I= 'm not > > > > > > > > inspired to try it. > > > > > > Although not inspired, I have taken a stab at it. > > > > > > I am still trying to figure out how to build/test it, but I hav= e forked > > > > > > glebius@'s github and added some code to... > > > > > > - Not dump the weak encryption keys (they just cause MIT's kadm= in.local > > > > > > to complain that the principal's database entry is corrupted. > > > > > > - If the argument to "kadmin -l dump" is "-f " instead > > > > > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I h= ope that will > > > > > > make the passwords work. > > > > > > (Basically, someone will "kdb5_util create -s" on the MIT KDC= system > > > > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to= the > > > > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> = mit.dump" > > > > > > then copy "mit.dump" over to the MIT KDC system and > > > > > > "kdb5_util load -update mit.dump". Then, hopefully, the prin= cipals will > > > > > > work??) > > > > > > > > > > > > Anyhow, it is currently sitting here: > > > > > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > > > > > (I'm as unconversant with git and github as anyone, so if you h= ave > > > > > > trouble finding it, just let me know.) > > > > > Actually, it hasn't made it there yet. For some reason (I think i= t is > > > > > glebius@s large # of branches) it takes a very long time to "git = push" > > > > > a patch involving 4 files. It failed after over an hour with an u= nexpected > > > > > TCP disconnect. I am running it again. > > > > > > > > > > I will stick the patch here, in case the push fails again. > > > > > (It needs to be applied on top of glebius@'s kadmin-dump-MIT bran= ch. > > > > The patch is here. (For some reason, I couldn't push so I deleted t= he > > > > github fork.) > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > > > > > > I haven't yet been able to test it, but will be able to do so later= to-day, rick > > > > > > > > > > > > > > Meanwhile I've given up trying to build it on a universe system a= nd > > > > > an now trying the "make buildworld" locally. This will take days, > > > > > so I guess I'll go do something else.;-) > > > > > > > > > > rick > > > > > > > > > > > > > > > > > I'll keep updating this github fork as I get to test it, but if= others > > > > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gleb Smirnoff From nobody Mon Sep 1 01:58:58 2025 X-Original-To: freebsd-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 4cFX9T0VFxz65pwd; Mon, 01 Sep 2025 01:59:09 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFX9S1slHz3GMN; Mon, 01 Sep 2025 01:59:08 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Z3Luh56+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-45b7c01a8c1so30098915e9.2; Sun, 31 Aug 2025 18:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756691940; x=1757296740; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:to:from:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2Lo2UgfECy/4RuaJRdZ3qjRQyUCfpegKXR6MbTbXoC8=; b=Z3Luh56+/Ekbf9KRWjwUNovUDhbMrVWhMgb62quEjWOi32ECnvWiiY3JRO17vtVDzc ImTk7WoZQJ5r0otX7qlL5RLrvP7rCtpX5sV9N/VOmUwdXAq9b206jkWK3IR6yz4mFpAH FQKA8hgbbLDjeGZqcMNnAEfDGyEw9jDYPTeqJReYGmL8lQ4k+plLgc/jUCiE1ulztF6O zB3bFSFHZvqRR24QiHkzMi8smDtpmwfZzLPNVR7hyy/yz7+dZjgeAhUGYeX5MnPjVRkF hLuF/RW8WSZr+8fx8jY60i7gg5qkqTbGDWCM/2dwYv/FMG3qS4XlCQqXbYEYoVSPp2bV LXeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756691940; x=1757296740; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2Lo2UgfECy/4RuaJRdZ3qjRQyUCfpegKXR6MbTbXoC8=; b=Mr0PcvVIzj/eXBiT9gcgGH0Ctik4ABOhKbACxIQ3ruqnZA22NHfc74xL7797Jvo5M7 Cq4WGy/iMw4hOWOQ1n12DcvTC3K5LRJTydVvWpUmR/zG0ah4lPehR0l6Y94PFXltAmu8 UELEcRuhKqQS2SFnLQ8VHrE3Kl9nScYsilgJWgQ5PzXiStS9x5i2nR4AtXxxqam4Xda4 Scv7B7oPSS7d74OQzYRdyp0whPTyoodrcDCqV5ZYjO+RMOeLGzJJph9azkGFMZubJvjd ZlX6KwPw2Di++/SW0GLoZ0J5fRamtLOJl+XTw7SYPB8nGLP1SsFSuS8ZP8MlLYdAknaj rtEQ== X-Forwarded-Encrypted: i=1; AJvYcCWECmV/JtGw+E0pzbF/FfD432IBmFtAHlFWHnRG1BCUqGUVz1ALrIUbKuz6Vw/FJg7L98/kTF8cbYIIjbsvMMU=@freebsd.org X-Gm-Message-State: AOJu0YywZ7VT+6XZnVG3yy1Xpow5+3mzDsOYQbt9AoEF5OLb3SuZAI04 IyXx1qUMWl0wAddmb1Zf5ZZvPqDW4GLHfS8NV3hlW9VX7+YkBm9l48Q4bVoU+A== X-Gm-Gg: ASbGncvGqtDwQN4eR0leadKZmHX6sr7ibrCnXlDNlzoVIx1fddfkzsTDvGyYQ56I1d2 LyZYFLIOqkAA7kjsu8EGmr/hkT1J/Ep03F9/SsDjD0uYQw8KMM/CUYhnmYB6aZAb/rk4/+GnMMK W1QMYjGac9Tj8yKwvVqHw67mrKSOH8nOmQkkqjpTSng5cNaqdw8BQ0E3GXB4qblCM9ivcYIQagS 8kQN4ZjpR/k+YHlSt39zXLeAiwAkjxJchSGxJ2WxArrNouYHn40iWNOd8DHjjB/ubhW2wwvU6Ky vUjvSpPDOwfII5vG+XOfiP9bAKkkdkBTwnFPa+4D2DCokMx45yNMsnOEv3D3C+ZrSVqUbr/Eix0 VNaABCwjKNt07vfPZtG+xIwTxGjre5K+UwCBVN+ik0UEBrQH3ZBfeFtv8CvNk+0966QIsjg== X-Google-Smtp-Source: AGHT+IFGxTsO3hDO23yqb6Aab/cQmDqed29effsOUqhQ867t7Kgkk6dIzeKT+WDAt3wR+fJYygTVOQ== X-Received: by 2002:a05:600c:5303:b0:45b:86ee:415f with SMTP id 5b1f17b1804b1-45b86ee43ebmr46649455e9.6.1756691939757; Sun, 31 Aug 2025 18:58:59 -0700 (PDT) Received: from [192.168.1.4] (host-89-241-205-78.as13285.net. [89.241.205.78]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b8efb280csm2048215e9.3.2025.08.31.18.58.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Aug 2025 18:58:59 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2025 02:58:58 +0100 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 User-Agent: Mozilla Thunderbird Subject: Using a recovery partition to repair a broken installation of FreeBSD From: Graham Perrin To: FreeBSD-CURRENT References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> Content-Language: en-GB Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJoRALAAhsDBQkPEg5ABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQL8YkP/2V1z6XQDyG1QlKAu8TuE8zDWy9QQKjC/G44hlu5zk+2kWSNk4zeExs9ZXOBmVhF EW1d+1J8wDiYIeKYj/rqMoP+gb8o0Au0lSRitvTdLxkZBFGMn0CEzlDOzv+wmiy0ggAV/s+Y EbiHk12fI0LoTy5/ywdmG/uGS7M6p3XOrM0YO1qmLXy1cUyYDsYIpq5/rT0QzpGowsJLoEA3 zz1vfKVY+RTorsL4W8ljXLmcs4c3b3HZG9Xmgtt+Ni/eb9CjzM7kCXOcSMnVzvfscCowPAwB 0ZHlNxNV0MTa61xgvOCk4Zf278ArRgbTm4oOz9Z4ciPMnVue+9P/VdxIxgUuYkAryM0+agGz L9bd8ljn+efNtgZ5dlDLrNnTE+vWnMVlMXgl7BNnhwHg7UYFLrC2xklsICub0qpnNheTGeqo 0N4UongJTQJ6H6LEpgd+KMkCncAHghED/G0/BUdO90VEOoqnIKwKa+F9NqVMvHWc8D58mwCP FghsmxK9FM9pnsjLmG7u+s51Y7++GSRnU4NkI4tHiVk7hcAcvZuc0QbUDwVMTurDUgIqRo6W 80j1tFjEspkrwtMoeVFEkDHktjoc3AoEymXIncZfqIqi3nVseyDVyNByvkV0mutX9hXqac0/ RXMuyK9KniAUZ9+gsWs4rPs/DOdsw4K8/RnjduBrfCYQzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmhEAsACGwwFCQ8SDkAACgkQt2dIb0oY1AvQxw//REWYFK2m4yS/QP5kzfhkWcNqDI/akGT5 /LXmdmbc1s78+mOMXnA4vBY/+X1QatgxWUECkPDOiIwXJMxoBuyY8e7spLRXeyhtfh5aYaJc MO5bARX0c49v+KfZ80u9tG2rkKQvAt/ySo7OXsbDADFFRhlc8RLbb8e7bSctGbYZk9CYa0ya dW5+n3znDNJ6yW1skx9wTH+Y8VlSazRLk3XgXscNqBA2h56v3WS/R5dI++7AQxZxSQacQvfj 9eahq7ATdB4zMQ9MBHEwOvGD3DLlc55FYSDZvNX+mhnK7S0t1Nt2EtGUOmXb5ysMFGnbsce0 woKQ0sLPF1HWDAAf7tBCF8mpPIzU/ViAkupsJ6NYCD0tLFD8pvl0NYU2TjvyWh6ie3e5B/b3 8Daiyme+M92ivfoRQOFKmkPfeT14AI6OW1k7qFbmoIwMWWQdFWAl1CP9hNdF9gRN4rFB0Jy1 90BajZW2zOdVfqdurJZegCzAowZalLm4JEK2MklpPzipibnJqhLOmvJy587pF52KDdM/4rLy BBREIm7uRivnO5k/BY5qS+H/aqv97LC0PVaTsLXbDmTxTnJplUpdlYT9NGidM+x/ioS0iztO Cht7cT8V8jvvKZYvNpst8iqxuIaoV9V7aZ0wAQpkgDGXHmSzwtz6U8xNf/4e4sLn9KPlldSd kvo= In-Reply-To: <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.96)[-0.958]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkgbase@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::330:from] X-Rspamd-Queue-Id: 4cFX9S1slHz3GMN On 17/08/2025 01:55, Graham Perrin wrote to freebsd-pkgbase: > Subject: Using pkgbasify to repair a broken installation of FreeBSD > 14.3-RELEASE > The routine is effective, to the best of my knowledge, however it's not particularly attractive. At least: - the condensed steps will be too long for some users - the first step assumes that the operator will have local access   and a USB memory stick. I love this response to the Foundation's recent Community Check-In: > … it would be nice to have something like 'recovery partition', as some OSes have. or at least some tiny fail-safe feature. having remote machine in some distant datacenter, booting from a flashstick is always a problem. An enhancement to bsdinstall could, before creation of the partition table, allow the user to specify an amount of space to be left free at the end of a device … From nobody Mon Sep 1 08:58:27 2025 X-Original-To: freebsd-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 4cFjTV1QFXz66Wrm for ; Mon, 01 Sep 2025 08:58:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4cFjTT47Rbz43KJ for ; Mon, 01 Sep 2025 08:58:37 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5818wRjq056426; Mon, 1 Sep 2025 17:58:27 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756717107; bh=tHuD1ATt6KHS6H1MPSl5C0gB6ayA5kW49wkMgz1NVBA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=k5d6Y+q6jG6d7BseKrQpPHuNxeZ/OjgKId59m7EOG9g4bPiyZg7E/SdCQOLtSj9Dg S/tFweVKQwp8ga5OlWsVpEfOIi6vf5USeMr+/esvtU9E2AC5axbXWL1kUH3zG6hnMd kl4yGnulS6rpBMVEH2Lpchrnbi2gcpmc1YFMdBpA= Date: Mon, 1 Sep 2025 17:58:27 +0900 From: Tomoaki AOKI To: Graham Perrin Cc: FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cFjTT47Rbz43KJ On Mon, 1 Sep 2025 02:58:58 +0100 Graham Perrin wrote: > On 17/08/2025 01:55, Graham Perrin wrote to freebsd-pkgbase: > > > Subject: Using pkgbasify to repair a broken installation of FreeBSD > > 14.3-RELEASE > > > > > > The routine is effective, to the best of my knowledge, however it's not > particularly attractive. At least: > > - the condensed steps will be too long for some users > > - the first step assumes that the operator will have local access >   and a USB memory stick. > > I love this response to the Foundation's recent Community Check-In: > > > … it would be nice to have something like 'recovery partition', as > some OSes have. or at least some tiny fail-safe feature. having remote > machine in some distant datacenter, booting from a flashstick is always > a problem. > > > > An enhancement to bsdinstall could, before creation of the partition > table, allow the user to specify an amount of space to be left free at > the end of a device … On legacy BIOS boots, using MBR (boot0) of FreeBSD allows selecting which base 4 partition "in the drive" to boot. So keeping this limitation in mind, rescue partition is possible and if there's KVM switch accessible via netowork, selections can be done on boot (not sure about IPMI: no experience). Currently, both UEFI boot1.efi and loader.efi don't have something alike "on stock". Ability to choose BE from loader is available, but IIUC, it can do nothing when the pool itself is causing problem. On the other hand, boot1.efi has patch to choose partition / pool to boot at Bug 207940, which is not landed but I'm always using. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 But unfortunately, boot1.efi is deprecated (no expiration target defined, though) and no merge would be expected. So it would be nice if loader.efi has this kind of feature. Implementing with lua and/or forth shouldn't be an option, as it wouldn't work once the pool / partition loader.efi looks into is somehow broken. So should be implemented as the functionality of loader.efi itself and show its selection menu BEFORE usual boot menu by lua/forth is shown. -- Tomoaki AOKI From nobody Mon Sep 1 09:04:44 2025 X-Original-To: freebsd-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 4cFjcj6kpJz66XLk for ; Mon, 01 Sep 2025 09:04:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4cFjcj4RjDz44j5 for ; Mon, 01 Sep 2025 09:04:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id BB720C43B2; Mon, 01 Sep 2025 09:04:45 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 58194iP2007318; Mon, 1 Sep 2025 09:04:44 GMT (envelope-from phk) Message-Id: <202509010904.58194iP2007318@critter.freebsd.dk> To: Tomoaki AOKI cc: Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD In-reply-to: <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> From: "Poul-Henning Kamp" References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> 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: text/plain; charset="UTF-8" Content-ID: <7316.1756717484.1@critter.freebsd.dk> Content-Transfer-Encoding: 8bit Date: Mon, 01 Sep 2025 09:04:44 +0000 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cFjcj4RjDz44j5 -------- Tomoaki AOKI writes: > > > … it would be nice to have something like 'recovery partition', as > > some OSes have. or at least some tiny fail-safe feature. having remote > > machine in some distant datacenter, booting from a flashstick is always > > a problem. I thought that is what /rescue is for ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Mon Sep 1 09:15:50 2025 X-Original-To: freebsd-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 4cFjsj72ZPz66YDW for ; Mon, 01 Sep 2025 09:16:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFjsj4jMQz46Qv for ; Mon, 01 Sep 2025 09:16:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-b4f1ee2e250so796423a12.2 for ; Mon, 01 Sep 2025 02:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756718163; x=1757322963; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PP5cOhPGF7S6jUEnvyF67QDgqxytj+923+Y84NbOVOM=; b=ANZ/09bLq3tgyZAoQ7iJRmHpDtfiXZOKp4dly2FAPjfjFf0BnEkFYUwFlGw3zYWuBo aJzJJEeMz/W7DhafMgVyRmuvQTSe8kWIuG8q6ULIZZ38WsSp6e9xfyPD66Emyi0FRZNI fp+eG/1gSHwFtG6GEU8l+2jcLdw9wfykVIu3UDxWclLB6ozh5SBiKy9SLuz7V0C+u7Um 9cNOej9dDcIqtj/kp93ITn2Jp/s5DavHPYDNOMAwKbkbfF7oD5o5kuQyNMplubuwSmjR +PcshCo4xWDF90P5GsZoWiiP+fIczL653P1OgBrcnXHIXhMfHBlPer0zc0swRwBZoj53 DiZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756718163; x=1757322963; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PP5cOhPGF7S6jUEnvyF67QDgqxytj+923+Y84NbOVOM=; b=mH0y3JVp5u7Pbv9NtOtp8cAlp6GOdc7tN8/YBi2ZCKKz51yMkJDdl5Rg594r1GZzcD /NikYG3MUf6HKgbZnIB92Uv8Y478cKcT0eMTFntPLbdhfPgfgKzfVJa1GFgptsq6ki26 fwR6V41V/1/hGM8v9RXOKvNwlSZ5mUf7H06Flg7DAo54YmT1ey59Ku94Bz1hxJY5pcZN QdOqiPDrdIdXZwjVce3W4lcg/QMVRBntDSTx/Muu2EHzi/yuj2HSTRc5J165XcCWszb7 m2C4uQoG6oHhY9SOw0NPH0VlAEromqgVH943JIwqlq5nQ02fRWvbw7NVpufKf/uJr+Cq VPsw== X-Forwarded-Encrypted: i=1; AJvYcCX67HOPjUF2xRWJb4SbqBuLUT0CT6Ufh5cPsCTZy/fCehLn2EVrUVbs+eBX6/YOHCAaB7FBnxwmHm6bTKAd6wE=@freebsd.org X-Gm-Message-State: AOJu0YwjqhLjmXwgqnGe0V2auK4ebrlPM8nZoajqDMbxokoAmUbx8Jwj q/7c5/nUT3BnTqsgZNQPYWZQk2sPqosDW4SYtGKB9e+3O5RBRIuufBT4oi5rvaM0/CCX/Qy90Zh JA95wT1dVC+qxrH4AXCp2wirrCzDLaVjrPuahHsdKyA== X-Gm-Gg: ASbGncvjowQ0cdEq0NS2k4pg8Wpm421SJw1upKEFV1wFrdXrem6lIVFlei7eOQLCK9L XcMTTMGYhSSj0jdqTp7zSss/ayLrsDzXksvkcNP5B1QIL+JrX9NEy6+PU8cGoLzF3iRBe2uLsHB /4lxps0L70h+R7MKyVtkloGhwwgjlBa24CMgzEIPVilgZwFjbypu3yz9HR59N2mHnEDlMFqucIl bkbQHqW/cqI/EtLsB8UjfUO/mXRkL0hapaIKXtkkEqUwPQOVfazEqORHtyuo7ywYVq1rA== X-Google-Smtp-Source: AGHT+IGgPvDpPpwZ9RKTT8iCJk910teda0QLWhmR5o2MrPqOcIBZntVhuBCvKTGr5sIwO0vdc6efNmrGqGo3rGyLpO0= X-Received: by 2002:a17:902:cf07:b0:240:3239:21c7 with SMTP id d9443c01a7336-24944aa1e6dmr95274585ad.37.1756718163239; Mon, 01 Sep 2025 02:16:03 -0700 (PDT) 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 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> In-Reply-To: <202509010904.58194iP2007318@critter.freebsd.dk> From: Warner Losh Date: Mon, 1 Sep 2025 03:15:50 -0600 X-Gm-Features: Ac12FXy0utVdLXxEhEvNE61ygFUlVAZeH2Px1CEaUbRXikrgeurtc6vJsfi8EEU Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Poul-Henning Kamp Cc: Tomoaki AOKI , Graham Perrin , FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="000000000000173bc1063db9d294" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cFjsj4jMQz46Qv --000000000000173bc1063db9d294 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp = wrote: > -------- > Tomoaki AOKI writes: > > > > > > =E2=80=A6 it would be nice to have something like 'recovery partit= ion', as > > > some OSes have. or at least some tiny fail-safe feature. having remot= e > > > machine in some distant datacenter, booting from a flashstick is > always > > > a problem. > > I thought that is what /rescue is for ? > That only works if your boot loader can read it... I've thought for a while now that maybe we should move that into a ram disk image that we fall back to if the boot loader can't read anything else... Warner > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > > --000000000000173bc1063db9d294 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 1, 2025, 3:05=E2=80= =AFAM Poul-Henning Kamp <phk@phk.f= reebsd.dk> wrote:
--------=
Tomoaki AOKI writes:


> >=C2=A0 > =E2=80=A6 it would be nice to have something like '= ;recovery partition', as
> > some OSes have. or at least some tiny fail-safe feature. having r= emote
> > machine in some distant datacenter, booting from a flashstick is = always
> > a problem.

I thought that is what /rescue is for ?

That only works if your boot loader = can read it... I've thought for a while=C2=A0now that maybe we should m= ove that into a ram disk image that we fall back to if the boot loader can&= #39;t read anything else...

Warner


--
Poul-Henning Kamp=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 956
FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe=C2=A0 =C2= =A0
Never attribute to malice what can adequately be explained by incompetence.=

--000000000000173bc1063db9d294-- From nobody Mon Sep 1 11:42:43 2025 X-Original-To: freebsd-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 4cFn712jd9z66Hyx for ; Mon, 01 Sep 2025 11:42:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4cFn704xhvz3Q26 for ; Mon, 01 Sep 2025 11:42:52 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 581BghW7078938; Mon, 1 Sep 2025 20:42:44 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756726966; bh=BF57LV+bw0JqRhncQ1YoOdX1+1hUIIZq1VQcmanunCg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=kopqiS6JmNuy37gps4VD0BCaTy18b0xZfI57IBQXthmFjnWaLRg45dcM5cYiijJFj hx43p3oFx/I0ZT54YCGcFr0/zBDp37+KYahDHHC/QmsWMmVxmVx1/ZApogRZbPGSHG 6oZg0DlXiHetg/eT5D2rEJU0Mqi/1MmNjcuiUpQc= Date: Mon, 1 Sep 2025 20:42:43 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Poul-Henning Kamp , Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cFn704xhvz3Q26 On Mon, 1 Sep 2025 03:15:50 -0600 Warner Losh wrote: > On Mon, Sep 1, 2025, 3:05 AM Poul-Henning Kamp wrote: > > > -------- > > Tomoaki AOKI writes: > > > > > > > > > … it would be nice to have something like 'recovery partition', as > > > > some OSes have. or at least some tiny fail-safe feature. having remote > > > > machine in some distant datacenter, booting from a flashstick is > > always > > > > a problem. > > > > I thought that is what /rescue is for ? > > > > That only works if your boot loader can read it... I've thought for a > while now that maybe we should move that into a ram disk image that we fall > back to if the boot loader can't read anything else... > > Warner Exactly. If the loader (or bootcode to kick the loader in the partition/pool) can sanely read the partition/pool to boot from, I think /rescue is enough and no need for rescue "partition / pool". But once the partition / pool to boot is broken (including lost decryption key for encrypted partitions/drives from regular place), something others are needed. And what can be chosen to boot from BIOS/UEFI firmware depends on the implementation (some could restrict per-drive only, instead of every entry in EFI boot manager table). If BIOS/firmware allow to choose "drive" to boot, rescue "drive" is useful, if multiple physical drives are available. Yes, rescue mfsroot embedded into loader.efi would be a candidate, too, if the size of ESP allows. > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. -- Tomoaki AOKI From nobody Mon Sep 1 15:22:13 2025 X-Original-To: freebsd-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 4cFt0J4Z26z66hSr for ; Mon, 01 Sep 2025 15:22:24 +0000 (UTC) (envelope-from woozle@woozle.net) Received: from wzl.woozle.net (wzl.woozle.net [195.54.192.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4cFt0H226Xz3vQd for ; Mon, 01 Sep 2025 15:22:23 +0000 (UTC) (envelope-from woozle@woozle.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=woozle.net; spf=pass (mx1.freebsd.org: domain of woozle@woozle.net designates 195.54.192.66 as permitted sender) smtp.mailfrom=woozle@woozle.net Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by wzl.woozle.net (Postfix) with ESMTP id CD65E72F for ; Mon, 01 Sep 2025 18:22:15 +0300 (MSK) Received: from localhost (woozle.rinet.ru [195.54.192.68]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id 581FMDfq008038 for ; Mon, 1 Sep 2025 18:22:15 +0300 (MSK) (envelope-from woozle@woozle.net) Date: Mon, 1 Sep 2025 18:22:13 +0300 (MSK) From: Dmitry Morozovsky X-X-Sender: marck@woozle.rinet.ru To: freebsd-current@FreeBSD.org Subject: reviving ZFS in broken sm_start+sm_size state Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-ID: 6B691B03 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: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [195.54.192.68]); Mon, 01 Sep 2025 18:22:15 +0300 (MSK) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.63 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[woozle.net,none]; R_SPF_ALLOW(-0.20)[+ip4:195.54.192.66]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:31363, ipnet:195.54.192.0/19, country:RU]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4cFt0H226Xz3vQd Dear colleagues, after some (AFAIR clean) reboot of current with ZFS-on-root I had (OCRed from mobile photo but hopefully good enough) unbootable system with the following panic: --- 8< --- panic: VERIFY3U(entry_offset, <, sm->sm_start + sm->sm_size) failed (1847270282567680 < 92341796864) cpuid = 2 time = 1756738203 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0149c856d0 vpanic at vpanic+0x136/frame 0xfffffe8149c85800 spl_panic at spl_panic+0x3a/frame 0xfffffe0149c85860 space_map_iterate() at space_map_iterate+0x3b1/frame 0xfffffe0149c85920 space_map_load_length() at space_map_load_length+0x5f/frame 0xfffffe8149c85970 metaslab_load() at metaslab_load+0x529/frame 0xfffffe8149c85a40 metaslab_activate() at metaslab_activate+0x46/frame 0xfffffe8149c85a88 metaslab_alloc_dva_range() at metaslab_alloc_dva_range+0x7f9/frame 0xfffffe0149c85bb0 metaslab_alloc_range() at metaslab_alloc_range+8x2c2/frame 8xfffffe8149c85c70 metaslab_alloc() at metaslab_allo zio_dva_allocate() at 0xfffffe0149c85cc0 zio_execute() at zio iraframe 0xfffffe0149c85e10/frame 0xfffffe0149c85e40 taskqueue_run_locked) at taskqueue_run_locked+0x1c2/frame 0xfffffe0149c85ec0 taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe0149c85ef0 fork_exit() at fork_exit+0x82/frame 0xfffffe0149c85f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0149c85f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 0 tid 101011] Stopped at --- 8< --- attempts to boot from last snapshot and/or trying to boot from PRERELEASE and zpool import lead to exactly the same results, even with different '-F' options: pool *seems* to be importable but actually isn't due to mad entry_offset as I can see from source any hints how could I resolve this? the pool content itself is not **very** important, but avoiding recreation would be nice thanks in advance! -- Sincerely, D.Marck [MCK-RIPE] [ FreeBSD committer: marck@FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle@woozle.net *** --------------------------------------------------------------------------- From nobody Mon Sep 1 21:28:28 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 4cG26r0d3Pz65JVB for ; Mon, 01 Sep 2025 21:28:36 +0000 (UTC) (envelope-from brian@sonicboom.org) Received: from sheehan.sonicboom.org (sheehan.sonicboom.org [50.190.118.82]) (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 4cG26p5VD0z3syX for ; Mon, 01 Sep 2025 21:28:34 +0000 (UTC) (envelope-from brian@sonicboom.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brian@sonicboom.org designates 50.190.118.82 as permitted sender) smtp.mailfrom=brian@sonicboom.org Received: from [192.168.4.22] (unknown [50.190.118.81]) by sheehan.sonicboom.org (Postfix) with ESMTPSA id 70CAE3A00083 for ; Mon, 1 Sep 2025 15:28:28 -0600 (MDT) Message-ID: <4f206fc8-45c8-4cdd-8a1f-2c9a48aa1063@sonicboom.org> Date: Mon, 1 Sep 2025 15:28:28 -0600 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 User-Agent: Mozilla Thunderbird Content-Language: en-US To: current@freebsd.org From: Brian Subject: buildworld in current vs stable/14 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.90)[-0.901]; R_SPF_ALLOW(-0.20)[+ip4:50.190.118.82]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7922, ipnet:50.128.0.0/9, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[brian]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sonicboom.org]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cG26p5VD0z3syX I am not sure when this changed, but I often test building the system just to do it, often with ccache. What I am seeing is that in 14.x systems, ccache shows a total number of ccache hits and misses in the low 40k range, whereas in 15 it is much less, often 2-3k. Of course the build moves more quickly. Is this tech to only build what is related to code changes? Brian From nobody Mon Sep 1 23:24:04 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 4cG4h65tvWz65mvq for ; Mon, 01 Sep 2025 23:24:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cG4h65Hplz46SX; Mon, 01 Sep 2025 23:24:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756769046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q5IsJLCgAngZqW+ZUM/GZVIanEiojJMsALZuwkLjfTc=; b=HqAzp88u6GEoGQ2TM7/vosNQBmiiSbTmhCdRaveQCEY3bgUDz452pIDhD5ToHlsOFDpvxW XBczCSX9T6YGLjUU89VTXgWUsUCz3Ydh/ozXWu/3/hZ5E2aqEVd7/JUr62nTs4EELOKL3i +YdsdEX20Cpa/LBzB7s7XGpCGkBrP3pxmOVEOhlw/6zkNDE6nX37PkBe2oBTYS0/R3DRJj t7nGRfbUafyttHBs6F14+ut54XDd+yxlLykbuclSv57ciRMh3m0MG1MWSekOirnzIWFObI 1EmPhOsUkLc90vz51SDi2YyaqTq7H2s+El5VqA76eLqIhWXJHKAf2NsXYUnnqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756769046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q5IsJLCgAngZqW+ZUM/GZVIanEiojJMsALZuwkLjfTc=; b=XMNsKdyc3NMmwUNFAvYKce/4nHUuwJnm32/eEQEwwVGnWmIgjdYORUcqls3pWVWJyy/JUi 8BeuOWPg3m9R4iY9ceZMafD1YC5YasfebYlLf/4BZhhG5JpZgNXumYKr7lKvn26Jp1xCv+ GA9BYIJEChwNIGQpZGTFl0ynxFGNPtgPLncCqm+AX3+YvLwdN5c8tmKomrdR5c2tr++hF7 kavojPAFbFZNtMHQaFeKaYu2k3bsrs9Y7kjTaZ+mSQZbWE+XkeU7/NGQszS0gt9iPw4Kcw O+jNFkHljs4UwVImfOHREn/Co72j3ktsPFfpTPJ+oyxgu3zZgxkk0ExlAvGUQA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756769046; a=rsa-sha256; cv=none; b=D++AGQlbmfK7qch26buo8AklkczaH15xhXTJ8meBErlV6L6zsTYesBIP3dGiFMqujqy+zL rrhw23S/fKIACYHyp9kh1Nb7xT8LxdQR2DCywkNgV6SsO83syTZyZy+S/DmZLfCPhJz9To NHEqXzTSYQ95febNb5eZFRCMTzVHauh7X6Ym5ZeBHSo2K2ZnzKL4hJGdt1YRdqvus/VERm kXRDi6PgILxOd0UzSlhZ5Zk7vsg1N6T0OIbvEutgDIVtLr9TjdeLilXfU0Wn3mZImg1abG STsAlORJbuLhCRCvPyiUW2YvdvbyStF25ei7XcJpacSTYekkHEaGhv6BERdp+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "E8" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cG4h63msHz3lw; Mon, 01 Sep 2025 23:24:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (bladnoch.home.andric.com [192.168.0.20]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D8C1865BD3; Tue, 02 Sep 2025 01:24:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: buildworld in current vs stable/14 From: Dimitry Andric In-Reply-To: <4f206fc8-45c8-4cdd-8a1f-2c9a48aa1063@sonicboom.org> Date: Tue, 2 Sep 2025 01:24:04 +0200 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B6762EE-E309-438E-915F-7863706020CD@FreeBSD.org> References: <4f206fc8-45c8-4cdd-8a1f-2c9a48aa1063@sonicboom.org> To: Brian X-Mailer: Apple Mail (2.3826.700.81) On 1 Sep 2025, at 23:28, Brian wrote: >=20 > I am not sure when this changed, but I often test building the system = just to do it, often with ccache. What I am seeing is that in 14.x = systems, ccache shows a total number of ccache hits and misses in the = low 40k range, whereas in 15 it is much less, often 2-3k. Of course the = build moves more quickly. Is this tech to only build what is related to = code changes? This is probably because 15-CURRENT uses WITHOUT_CLEAN by default, since = 2025-08-19 at least. On 14.x, this is not the case. You might find that = there is less difference between the two, if you put WITHOUT_CLEAN in = your src.conf. -Dimitry From nobody Tue Sep 2 02:00:27 2025 X-Original-To: freebsd-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 4cG88v4Lz5z665yv for ; Tue, 02 Sep 2025 02:00:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cG88t43Rpz3DRn; Tue, 02 Sep 2025 02:00:46 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="GAbs/jUt"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61cf429f4c2so8326259a12.1; Mon, 01 Sep 2025 19:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756778440; x=1757383240; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=I/AW8rfPXr09pHeNW6Fv+2cj700V2cjlYjHCzG1xXo4=; b=GAbs/jUtsnjpmrkbH4T85FpJn8GMicCK8yG75dvIBLwIcIHI81zuBuTOfgid5N+xcV zZ9aZx2eyKsc0ev+BgA+eB09JVQeUlS3QYoM5LmiI5fLzFhu3IORmwu3SVmq++vu4C+t 1X1RJeD5SC4pUPv51DTd2cHWmSVwWTuQiwSBSJzaJjz+scQkTlGeDiXfPi9dxdv9yMEt FDYcVoDHFT6zCJTqjkf35cThBr1JxgxDtZD2m7STc9b8uOszRaIBCrhAtUwPEHoOfhZw q6kYGJp940ycnB0qXoNEIeFBY8POIU31pRfpkDMwtGWoywVOyU2/c7m5/f/2rKHoZfD2 HsIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756778440; x=1757383240; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=I/AW8rfPXr09pHeNW6Fv+2cj700V2cjlYjHCzG1xXo4=; b=r6jqoYV2782v0Kg/x60VMWfPkMODhaN2oN6hoozjhTaEZxU3TEK5Oz0WUHBGuG1PW+ OfnIKtm0HKVVLg+G+rqoL1y3uZnA8B4DNkw8wMGjXB3SOhpOm8o8XytG3fvk1fbFCgmw sFFC/EBOmFWEC8oGU4wX+RregW7D6AZM7OWn7D2uAatCBIY1vzIwBZHrc8OZKYvt920x oYERsAPfVgj6KCLCNYaTFdPDGOIwFQ5AZsToOJDPLwwzolTIdt211c//iOpXYtU2TxnX P3CbCklTNJo9EDbnU26DQ+Xk5KP4yC+83HEU/es/ynBJEgsTY2yXuP7gi8ZRxE8mfh+y IdAw== X-Forwarded-Encrypted: i=1; AJvYcCXwU3CXuXhSMvMuB0QBKG7kaVO3rqa/6nC60+YX3mem3VfCx9OhurlWjr1b3xYaFxYoJbiEQzrHN0AW9Y9nRLE=@freebsd.org X-Gm-Message-State: AOJu0YyayXx1uLxbb1oPaUgRuvDaNyfSOKcJkfVislXZYA3eV8sTGVTC 3Q52zz6G/ZQRyb/JhgZmLNFco92COZtfZT8j4LZBXvu1kzfe2ek0mhGfra8DK6mxCi3WO0+A4+4 J9LvHiiBDC1sbmw0pxPdV9sjVgP8PAWcE X-Gm-Gg: ASbGncsHCzYJHFBHAZQkQxaoMe71p3KNkfREdGaElPAXPvL7oIDs4RVay7dzTWt+Dz+ YVAIc8UZGDFcjuq2IYPfGYWBZLVQNWBhq50oCRmy8vGAUVl3kZf9TZur0riWzIZl801njyoJOkQ jnQWYKMtfsyQufSzvLdIMiAJfNbc6Cabg97oKc2dusJPZt0vjNazVJ6cc7uw/Iu5FO+nChVs5pO +IG3RQUq5TOgEyEoWXyXZHv9zuwimK3ndnoCu4eWLrTp4595A== X-Google-Smtp-Source: AGHT+IGOfJPY+PBacWezYAqpWHI/F1KufRfJ7yt7LS0xLKjLEErIbTBpH5o/k64BeDybVcwt7ptigpgybqeW9Shb+qU= X-Received: by 2002:a05:6402:520b:b0:61c:6855:d92d with SMTP id 4fb4d7f45d1cf-61d270e4601mr8600391a12.31.1756778440175; Mon, 01 Sep 2025 19:00:40 -0700 (PDT) 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 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Mon, 1 Sep 2025 19:00:27 -0700 X-Gm-Features: Ac12FXyniufoCe1HyEVuLVe_4b59sO9SWWe-S7q7yuuewaIDY8UTF5ptXOvRLnU Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.63 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.63)[-0.633]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cG88t43Rpz3DRn On Sun, Aug 31, 2025 at 5:58=E2=80=AFPM Rick Macklem wrote: > > On Sun, Aug 31, 2025 at 5:41=E2=80=AFPM Rick Macklem wrote: > > > > On Sat, Aug 30, 2025 at 9:47=E2=80=AFPM Rick Macklem wrote: > > > > > > On Sat, Aug 30, 2025 at 4:22=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff= wrote: > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Mackl= em wrote: > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg ins= tall heimdal", you get a > > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > > T> R> > > > > > > > > > > T> R> Now, I have another challenge. Fixing the master = passwords. > > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > > T> > > > > > > > > > > T> I have applied two commits from Heimdal from 2012 th= at add 'kadmin dump -f MIT' > > > > > > > > > > T> feature to our base heimdal and polished them to com= pile. So far it doesn't > > > > > > > > > > T> work yet, either create an empty dump or create a co= re dump, instead of > > > > > > > > > > T> database dump :) I'll see how difficult it is going = to further resolve that to > > > > > > > > > > T> a working condition. If I succeed, then having 'dump= -f MIT' in base without > > > > > > > > > > T> any ports would be the best solution. Can also be m= erged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my cha= nge incorrectly - threw > > > > > > > > > > the new binary on a system running unpatched libraries.= When run correctly, > > > > > > > > > > it successfully produced something that looks like a co= rrect dump in MIT format. > > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, though= . > > > > Well, would you like the not so bad news or the bad news??;-) > > > > Your patch works, in that it produces a dump that "kdb5_util load > > > > -update" can load. > > > > After loading, if the principal only has keys for the newer encrypt= ion types of > > > > aes256-cts-hmac-sha1-96 > > > > aes128-cts-hmac-sha1-96 > > > > then you can look at the principal via kadmin.local, but the passwo= rd must > > > > be changed before it works. > > > > --> This is the same behaviour as you get if you use Heimdal-7.8 to= do the > > > > dump conversion. > > > > So far, so good... > > > > > > > > Now, the not so good news. Once you update the Heimdal libraries > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the system > > > > running the old KDC. "kadmin -l dump" works, but something like: > > > > # kadmin -l > > > > kadmin> get rmacklem > > > > kadmin: get rmacklem: Service key not available > > > > - I have not yet looked in your patched sources to see where this > > > > failure comes from? > > > > > > > > Now, more not so good news... > > > > My patch doesn't help. > > > > It does re-encrypt the key in the master key from the MIT KDC > > > > system, but that doesn't make the password work. > > > > When I compared the dump generated via kadmin with both > > > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > > > is 34bytes long. > > > > After doing the change_password so that it works, a dump > > > > generated by "kdb5_util dump -r13" (the same dump format) > > > > has a key that is 62bytes long. > > > > --> So, there is more to converting the key than just re-ecrypting > > > > it. (I'll try and find where the MIT code encrypts a key in a= master > > > > key to see why it ends up at 62bytes and whether that can be = done > > > > in the old code.) > > > > > > > > So, if we are going to continue with this... > > > > - We need to figure out why your patch breaks "kadmin" for other > > > > things and fix that. > > > > - I/we need to figure out how to convert the 34byte key to the MIT > > > > 62byte key (and then maybe the password won't need to be changed?= ). > > > > > > > > Or do we just say "When you convert the KDC database, all the passw= ords > > > > must be changed to get them to work?". > > > All I've got sofar is this patch... > > > https://people.freebsd.org/~rmacklem/print.patch > > > > > > It tweaks entry2mit_string_int() so that it skips over the keys for > > > old encryption types and fills in a fake "modified by" entry if none > > > exists. > > > > > > These changes at least make the MIT dump such that the records > > > don't end up "incomplete or corrupted" when you try to do something > > > like "get_principal " in kadmin.local. > > > > > > As noted, your patch makes "kadmin -l" break for most things, > > > reporting "Service key not available". The failures go away if > > > you revert back to the non-patched libraries. > > > I have not located the problem yet. > > > > > > As for the passwords...no luck yet, rick > > Finally..it works. (First off, apologies for all the posts, just ignore > > them.;-) > > > > The patch is at: > > https://people.freebsd.org/~rmacklem/kadmin.patch I just updated the patch with a fix for the case where the Heimdal principal does not have any keys for string encryption. (That is fixed now and I haven't found any other bugs, so I think I am done playing with it. Yippee!!) Please test when you can find the time, rick > > > > It goes on top of glebius@'s kadmin-dump-MIT branch of > > https://github.com/glebius/FreeBSD. > > > > Once built with "WITHOUT_MITKRB5=3D"yes" in /etc/src.conf > > and installed, there is a new option for "kadmin -l dump" called > > "-f" and my patch modifies "-f" so it can take a filename instead > > of "MIT" or "Heimdal". > > > > Here's how you test it (once your Heimdal KDC system has > > been patched): > > On the MIT KDC system: > > # mkdir /var/db/krb5kdc <-- maybe the installer should do this? > > - copy kdc.conf and kadm5.acl into this directory and edit them > > for your Realm, etc. > > - copy an MIT krb5.conf in /etc/krb5.conf and edit this one as well. > > (I've attached the three files I use as very basic examples.) > > Once you've done this: > > # kdb5_util create -s > > should work. > > > > Now, copy /var/db/krb5kdc/.k5.YOUR.REALM over to the > > Heimdal KDC system. > > Then go to the Heimdal KDC system and... > > # kadmin -l dump -f .k5.YOUR.REALM mit.dump > > Now, copy mit.dump over to the MIT KDC system and > > on the MIT KDC system... > > # kdb5_util load -update mit.dump > > > > And, at least if the principals on the Heimdal KDC > > have keys for at least one of: > > aes256-cts-hmac-sha1-96 > > aes128-cts-hmac-sha1-96 > > they should work. > Maybe there should be an additional option on "kadmin -l dump" > that allows weak encryption keys through. (I'm not sure if you can > still enable them in the MIT KDC?) > > This is a little more work than it sounds, since you need to pass > the info into entry2mit_string_int() and it currently does not have > any argument for stuff like flags. > > The problem is that, if you let them through (as in onto the mit.dump) > and they are not enabled for the KDC, kadmin.local will report the > principal entry as "incomplete or corrupted" and you cannot do > anything with it. > > rick > > > > > For principals that do not have keys for either of > > the above two etypes, you should still be able to > > see the principal via "get_principal " in > > kadmin.local. > > If you can see it, a change_password in kadmin.local > > should get it working. > > > > Hopefully people with Heimdal KDCs can test this? > > > > rick > > > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > Oh, and one more thing... > > > > > > > > - If there are keys for old encryption types like des.. or = arcfour.. > > > > > > > > in the MIT dump, > > > > > > > > those will screw up the load. (You can check and delete t= hem in the > > > > > > > > Heimdal-1.5.2 > > > > > > > > kdc system via.. > > > > > > > > # kadmin -l > > > > > > > > get > > > > > > > > - if old keys are listed in Keytypes: > > > > > > > > del_enctype > > > > > > > > exit > > > > > > > > > > > > > > > > Ideally the conversion code would skip over these and not = put them in the dump. > > > > > > > > > > > > > > > > rick > > > > > > > > ps: If you don't do this, when you "get_principal" in kadmi= n.local on > > > > > > > > the MIT KDC > > > > > > > > system, it will give you a "Database record is incomp= lete or corrupted..". > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The = above experience also > > > > > > > > > > indicated that I need to do a library version bump. > > > > > > > > > I don't know if you are enthusiastic about pursuing this,= but hopefully this > > > > > > > > > works and gets the principals in (although I doubt the pa= sswords will > > > > > > > > > work without changing them). > > > > > > > > > > > > > > > > > > To get the passwords to work, I think the following *migh= t* do it: > > > > > > > > > - If you look in the Heimdal sources, when "--decrypt" is= specified, > > > > > > > > > I think it finds its way down into a function called hd= b_unseal_key_mkey() > > > > > > > > > which decrypts the key using the master key by calling = _hdb_mkey_decrypt(). > > > > > > > > > To get the passwords to work, I think the call to _hdb_= mkey_decrypt() would > > > > > > > > > need to be followed by a call to _hdb_mkey_encrypt() wi= th the "key" > > > > > > > > > argument being the master key for the MIT database. (It= it a keytab > > > > > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created whe= n you do a > > > > > > > > > "kdb5_util create -s" on the system that will be the MI= T KDC.) > > > > > > > > > - Just to make it even more fun, there is a flag called= HDB_KU_MKEY > > > > > > > > > which is set to the Heimdal way and not for the MIT w= ay (whatever > > > > > > > > > that really means?). > > > > > > > > > - There is also some stuff about padding in hdb_unseal_= key_mkey(), > > > > > > > > > but hopefully that won't be a problem? > > > > > > > > > > > > > > > > > > I think hdb_read_master_key() can be used to read in the = MIT master > > > > > > > > > key from the file you provide as an argument to it. > > > > > > > > > > > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > > > > > > > > > > > I'll admit since the hardware I have takes forever to "ma= ke buildworld" > > > > > > > > > and I don't know a quick way to build/test these changes,= I'm not > > > > > > > > > inspired to try it. > > > > > > > Although not inspired, I have taken a stab at it. > > > > > > > I am still trying to figure out how to build/test it, but I h= ave forked > > > > > > > glebius@'s github and added some code to... > > > > > > > - Not dump the weak encryption keys (they just cause MIT's ka= dmin.local > > > > > > > to complain that the principal's database entry is corrupte= d. > > > > > > > - If the argument to "kadmin -l dump" is "-f " instead > > > > > > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I= hope that will > > > > > > > make the passwords work. > > > > > > > (Basically, someone will "kdb5_util create -s" on the MIT K= DC system > > > > > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over = to the > > > > > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename= > mit.dump" > > > > > > > then copy "mit.dump" over to the MIT KDC system and > > > > > > > "kdb5_util load -update mit.dump". Then, hopefully, the pr= incipals will > > > > > > > work??) > > > > > > > > > > > > > > Anyhow, it is currently sitting here: > > > > > > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > > > > > > (I'm as unconversant with git and github as anyone, so if you= have > > > > > > > trouble finding it, just let me know.) > > > > > > Actually, it hasn't made it there yet. For some reason (I think= it is > > > > > > glebius@s large # of branches) it takes a very long time to "gi= t push" > > > > > > a patch involving 4 files. It failed after over an hour with an= unexpected > > > > > > TCP disconnect. I am running it again. > > > > > > > > > > > > I will stick the patch here, in case the push fails again. > > > > > > (It needs to be applied on top of glebius@'s kadmin-dump-MIT br= anch. > > > > > The patch is here. (For some reason, I couldn't push so I deleted= the > > > > > github fork.) > > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > > > > > > > > I haven't yet been able to test it, but will be able to do so lat= er to-day, rick > > > > > > > > > > > > > > > > > Meanwhile I've given up trying to build it on a universe system= and > > > > > > an now trying the "make buildworld" locally. This will take day= s, > > > > > > so I guess I'll go do something else.;-) > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > I'll keep updating this github fork as I get to test it, but = if others > > > > > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gleb Smirnoff From nobody Tue Sep 2 02:43:00 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 4cG95f2KYBz66BNb for ; Tue, 02 Sep 2025 02:43:02 +0000 (UTC) (envelope-from brian@sonicboom.org) Received: from sheehan.sonicboom.org (sheehan.sonicboom.org [50.190.118.82]) (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 4cG95f09q0z3JjQ; Tue, 02 Sep 2025 02:43:02 +0000 (UTC) (envelope-from brian@sonicboom.org) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.4.22] (unknown [50.190.118.81]) by sheehan.sonicboom.org (Postfix) with ESMTPSA id 18F8E3A00198; Mon, 1 Sep 2025 20:43:01 -0600 (MDT) Message-ID: Date: Mon, 1 Sep 2025 20:43:00 -0600 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 User-Agent: Mozilla Thunderbird Subject: Re: buildworld in current vs stable/14 To: Dimitry Andric Cc: current@freebsd.org References: <4f206fc8-45c8-4cdd-8a1f-2c9a48aa1063@sonicboom.org> <8B6762EE-E309-438E-915F-7863706020CD@FreeBSD.org> Content-Language: en-US From: Brian In-Reply-To: <8B6762EE-E309-438E-915F-7863706020CD@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7922, ipnet:50.128.0.0/9, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cG95f09q0z3JjQ This was correct. I saw the notes in the UPDATING file, which I usually don't look at unless something fails :) Thanx Brian On 9/1/2025 5:24 PM, Dimitry Andric wrote: > On 1 Sep 2025, at 23:28, Brian wrote: >> I am not sure when this changed, but I often test building the system just to do it, often with ccache. What I am seeing is that in 14.x systems, ccache shows a total number of ccache hits and misses in the low 40k range, whereas in 15 it is much less, often 2-3k. Of course the build moves more quickly. Is this tech to only build what is related to code changes? > This is probably because 15-CURRENT uses WITHOUT_CLEAN by default, since 2025-08-19 at least. On 14.x, this is not the case. You might find that there is less difference between the two, if you put WITHOUT_CLEAN in your src.conf. > > -Dimitry > From nobody Tue Sep 2 03:02:45 2025 X-Original-To: freebsd-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 4cG9XZ6PD9z66DWD for ; Tue, 02 Sep 2025 03:02:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cG9XZ4RJcz3M5S for ; Tue, 02 Sep 2025 03:02:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-323266d6f57so5334032a91.0 for ; Mon, 01 Sep 2025 20:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756782168; x=1757386968; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JFyXhjqjc4qZxDC9c4L1d9Os+sHmEzZoc6Aba3PX2sE=; b=udNtFCjw58ormMdwXXLOJgdMszppteuryY7Qk5qynBcItII9R5Z57cgFE7skqi8lZe /hQeD53YioWr+30HhfPNqRVhAtHuQQI67Y9yRTP2hwb2VYlrL4d0Iru0PdPNar75269w n+NWrWxEvWQK/WPYDpVwQ9NfhW/jT/mdf33FuCrCmdt7RYI/0yuQp53o5rS2QcK+zJa3 tM+e8lxXLgTVgQN1kL35brxCIpionPsF5KM2hV1JYWaEDevAL8Xa0vIW6embw5c7RKbt jAmtZXmHmyBBmBLU6gECEy7vHLwLYz7Ko9bRemw2yOMnjEnjJuaFPouBXZs3vXVDsZt+ 1/dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756782168; x=1757386968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JFyXhjqjc4qZxDC9c4L1d9Os+sHmEzZoc6Aba3PX2sE=; b=BLvUD/Uc5hk44qtIs6n4n9mBP23OgoIs7w6J4qXhrgyFceE31CI4oebFSJdbOZxWJU 6inL1hH27YOv5WEdhlsKE/Y4VMiEZQrHGz6WIZHnhxBw/icqPDR9Vqvhrr+0TKGPvZrb PGLoVlNMbPcTnne7yck6fH9NRGLJKaLW/RO+4Y9ddBeXLj4fgt8g29T/LniO1OSGnWhs e9MmAgKV2i5VijaHw+Pcbw0tISN0LczIODvgd5drm5+2BvxK2Em2iISOo+sV69rLqOOW 8y+hM9ynOWJHkOEre5KXn4WXWZ6YYvZdJZkMcQzCBK020P9vLv0EvMx7ZHY9liig8EQZ 2pyg== X-Forwarded-Encrypted: i=1; AJvYcCX5fi+kvrDg6GAFNsF6lyTyFio9aMBf6HwjRkKJK9BsKPVZw7JtJoaZUtuBBN/4k6YFNZ5QlBBPfqlMD82zQcs=@freebsd.org X-Gm-Message-State: AOJu0Yzm23F0iSx4uHo0V+u5Ai/Bembvf3gDiPE2OvidpcIBwAtNxc2R SXDGGGQ9OmNstAYeXX+tnSDDMZCgtVIgmz82NEioHJi3j9J4LuloUlE2vovQoV55XAodt32kYcG 5SAQCrqsXjg5PfwSX3xCqeb5y1XbMfOl87DaH1KpJHw== X-Gm-Gg: ASbGncspIHu7tQ6iV97mEjjsyG8Ds39w14Bt2MaBx4IzJ1XIccNNzdTf7fBMwGKaMUS p0c4YxOgdWqyHl75bwyByuhw2l4Oz5rplP1kZ+hX4ZDdG1Ta/Y8VPMpbsazZJwKmEKCCQ08VgPI 7erFfJF/SqvGF6hctNyF7AFP8+OLvUM1u8GqzI5TAbwlI8yaaquCgK5Fpp8nfWLPI1EC9Coo9VJ Wu+hCXGkETidh3oZRBIVinTnENIZi1xHynMFXOri+1adeOAsA== X-Google-Smtp-Source: AGHT+IGHtZX8VPdjsYeYHRenoE1auaNajrVkTrfK6TExZMIg0zd9GeRbZy8AWPN4CZTdTMmqVoD3NAuoQMWKybaPyi0= X-Received: by 2002:a17:90b:4fd0:b0:327:d551:5932 with SMTP id 98e67ed59e1d1-328156c5843mr12370822a91.21.1756782168432; Mon, 01 Sep 2025 20:02:48 -0700 (PDT) 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 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> In-Reply-To: <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> From: Warner Losh Date: Mon, 1 Sep 2025 21:02:45 -0600 X-Gm-Features: Ac12FXxfRSgfEsYI9KDdA0QNh1Mw9Ti2YtJVmZY_rfJVnxNVrsq8ORLidxnqA-8 Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Tomoaki AOKI Cc: Poul-Henning Kamp , Graham Perrin , FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="00000000000018f85d063dc8b91b" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cG9XZ4RJcz3M5S --00000000000018f85d063dc8b91b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2025 at 5:42=E2=80=AFAM Tomoaki AOKI wrote: > On Mon, 1 Sep 2025 03:15:50 -0600 > Warner Losh wrote: > > > On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp > wrote: > > > > > -------- > > > Tomoaki AOKI writes: > > > > > > > > > > > > =E2=80=A6 it would be nice to have something like 'recovery pa= rtition', > as > > > > > some OSes have. or at least some tiny fail-safe feature. having > remote > > > > > machine in some distant datacenter, booting from a flashstick is > > > always > > > > > a problem. > > > > > > I thought that is what /rescue is for ? > > > > > > > That only works if your boot loader can read it... I've thought for a > > while now that maybe we should move that into a ram disk image that we > fall > > back to if the boot loader can't read anything else... > > > > Warner > > Exactly. If the loader (or bootcode to kick the loader in the > partition/pool) can sanely read the partition/pool to boot from, > I think /rescue is enough and no need for rescue "partition / pool". > > But once the partition / pool to boot is broken (including lost > decryption key for encrypted partitions/drives from regular place), > something others are needed. > > And what can be chosen to boot from BIOS/UEFI firmware depends on > the implementation (some could restrict per-drive only, instead of > every entry in EFI boot manager table). > > If BIOS/firmware allow to choose "drive" to boot, rescue "drive" > is useful, if multiple physical drives are available. > > Yes, rescue mfsroot embedded into loader.efi would be a candidate, too, > if the size of ESP allows. Rescue is quite small. On the order of 8MB compressed. The trouble is that the kernel is like 12MB compressed, plus we'd need a few more modules. Still, we could likely get something under 25MB that's an MD image that we could boot into, but it would have to be single user. And It's been a while since I did that... Typically I just run /rescue/init or /rescue/sh, which isn't a full system and still uses the system's /etc. If we customized it per system, we could do better, since the kernel can be a bit smaller (compressed our kernels at work are 6MB), so under 20MB could be possible. We'd not need /boot/loader.efi in there. If we could hook into the arch specific traps that cause segv, etc, we could do a setjmp early and set 'safe mode' and restart. Though that may be trickier than I initially am thinking... maybe the best bet is to let uefi catch that failure and have the next bootable BootXXXX environment on the list specify a safe mode. More investigation might be needed. Warner --00000000000018f85d063dc8b91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 1, = 2025 at 5:42=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Mon, 1 Sep 2025 03:15:50 -0600
Warner Losh <imp@bsd= imp.com> wrote:

> On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp <phk@phk.freebsd.dk> wro= te:
>
> > --------
> > Tomoaki AOKI writes:
> >
> >
> > > >=C2=A0 > =E2=80=A6 it would be nice to have something= like 'recovery partition', as
> > > > some OSes have. or at least some tiny fail-safe feature= . having remote
> > > > machine in some distant datacenter, booting from a flas= hstick is
> > always
> > > > a problem.
> >
> > I thought that is what /rescue is for ?
> >
>
> That only works if your boot loader can read it... I've thought fo= r a
> while now that maybe we should move that into a ram disk image that we= fall
> back to if the boot loader can't read anything else...
>
> Warner

Exactly. If the loader (or bootcode to kick the loader in the
partition/pool) can sanely read the partition/pool to boot from,
I think /rescue is enough and no need for rescue "partition / pool&quo= t;.

But once the partition / pool to boot is broken (including lost
decryption key for encrypted partitions/drives from regular place),
something others are needed.

And what can be chosen to boot from BIOS/UEFI firmware depends on
the implementation (some could restrict per-drive only, instead of
every entry in EFI boot manager table).

If BIOS/firmware allow to choose "drive" to boot, rescue "dr= ive"
is useful, if multiple physical drives are available.

Yes, rescue mfsroot embedded into loader.efi would be a candidate, too,
if the size of ESP allows.

Rescue is quite = small. On the order of 8MB compressed. The trouble is that the kernel is li= ke 12MB compressed, plus we'd need a few more modules. Still, we could = likely get something under 25MB that's an MD image that we could boot i= nto, but it would have to be single user. And It's been a while since I= did that... Typically I just run /rescue/init or /rescue/sh, which isn'= ;t a full system and still uses the system's /etc. If we customized it = per system, we could do better, since the kernel can be a bit smaller (comp= ressed our kernels at work are 6MB), so under 20MB could be possible. We= 9;d not need /boot/loader.efi in there.

If we coul= d hook into the arch specific traps that cause segv, etc, we could do a set= jmp early and set 'safe mode' and restart.=C2=A0 Though that may be= trickier than I initially am thinking... maybe the best bet is to let uefi= catch that failure=C2=A0and have the next bootable BootXXXX environment on= the list specify a safe mode. More investigation might be needed.

Warner
--00000000000018f85d063dc8b91b-- From nobody Tue Sep 2 05:30:35 2025 X-Original-To: freebsd-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 4cGDqH2yMsz66Th8 for ; Tue, 02 Sep 2025 05:30:51 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGDqG2fZcz3flH for ; Tue, 02 Sep 2025 05:30:50 +0000 (UTC) (envelope-from wschnr@googlemail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of wschnr@googlemail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=wschnr@googlemail.com Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-45b7d497abaso32165335e9.0 for ; Mon, 01 Sep 2025 22:30:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756791047; x=1757395847; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mH+aLeVi8uOLO5qLvt2gFnz/Td9QFjc9oafejK20GY8=; b=ZXdnl0lWQAmkZv1IAHXuYqtRsay5zMc7jUyjnToECDAkGNRPFluwRV1P+oa0m9Qk+G IuKHzDW8bu83ws06XN9s5oltnGiRi/iMPthhINna1fERF6dYA0oTWIh/Ba/Vs8jutfnN o3YNMFtqLg1RGUw7YGXJ8FepzSHQcrTp9p2n/2jfFXm4HULq/psZskUGoORdZGB0Xknw fXx2sMfRRKU8nIMGeKbh4Bgyoc50HZKLW92DshOnrJuVliJOU8jqV9U+e/2ZXCng/UMJ 44EEId+kUutBWZGZnRQ7367ge4nVkiLlmQwwC2s2SkzWQGJietk9/i81Mec2fWQGWc8Z EUnw== X-Gm-Message-State: AOJu0YwH6ET83QvlPQA7XZNVGxMmtAIIiZilC12XsxgPJZcp9yp/BYzh ReImPuecMfEytSEBgQcHxxP2ELHgx8OT+L2PUJaqX35Nk7aGBLSDd4oGQKMrakwJr711ns0px70 vWFzsNTX1l0X7SypRClyWI2SlyAyHyKHGOA/O X-Gm-Gg: ASbGncte2sbMq5nMdy1jRMtuYnODkdOhQRVPZCXHcOkVrVYOw0P/iLREqdl4kwu9Slz kcCIjSbhX1QwjP03ph5HvfND0NpfS9Y4w0b0agoJOVRSB1z/wfWg6ystTe6nSeMIw9SiWt+EaXh uxLI4rO/BsBq7OAwCoof69nC2xBaUNZ1tZ5hSIvD5iVKrnQyda80nDH0Xvp13j0ZqD5R9uOTPrZ 5JAFwjdbOLjt+uugfqPf5yh44juFpyJ7PDnaiHEOsVqPYJRY5XAtH9OrW33CZeBdbpyRYHUfwwi /g== X-Google-Smtp-Source: AGHT+IGmbhskHXxBY7TKgUgUYnDPfEMGYG6OnPs6EgLbXO9dOoZvwGfc3PpW8fMrO6f6kGMEFwT0oCJFum7aKhkO3tE= X-Received: by 2002:a05:600c:c87:b0:45b:9912:9f1e with SMTP id 5b1f17b1804b1-45b99732e41mr4036005e9.3.1756791047303; Mon, 01 Sep 2025 22:30:47 -0700 (PDT) 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 From: Wolfram Schneider Date: Tue, 2 Sep 2025 07:30:35 +0200 X-Gm-Features: Ac12FXw8bu_Y-sYeu6ZiwugYbNqyADiZV5AosfEa7989p73aeOM_FeTy0Hvfypo Message-ID: Subject: clang 20 needs the real linker name To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_HAM_SHORT(-0.98)[-0.977]; FORGED_SENDER(0.30)[wosch@freebsd.org,wschnr@googlemail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.47:from]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[wosch@freebsd.org,wschnr@googlemail.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.47:from] X-Rspamd-Queue-Id: 4cGDqG2fZcz3flH I tried to cross compile FreeBSD on macOS. I choose the clang20 from homebrew and got the error message: --- libsys.so.7.full --- Building shared library libsys.so.7 [...] clang: error: invalid linker name in argument '--ld-path=lld' *** [libsys.so.7.full] Error code 1 Apparently, the workaround in share/mk/bsd.sys.mk with mapping ld.lld -> lld no longer works see https://reviews.freebsd.org/D52330 -Wolfram -- Wolfram Schneider https://wolfram.schneider.org From nobody Tue Sep 2 13:51:22 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 4cGRwz1YCvz66lYR for ; Tue, 02 Sep 2025 13:51:31 +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 4cGRwx1Ym6z3cb7 for ; Tue, 02 Sep 2025 13:51:29 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 582DpMXo037900 for ; Tue, 2 Sep 2025 13:51:22 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 582DpMT2037899 for current@freebsd.org; Tue, 2 Sep 2025 06:51:22 -0700 (PDT) (envelope-from david) Date: Tue, 2 Sep 2025 06:51:22 -0700 From: David Wolfskill To: current@freebsd.org Subject: etcupdate whines "Failed to build new tree." 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="ChpKOsy3k/MDPPzu" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.39 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; 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: 4cGRwx1Ym6z3cb7 --ChpKOsy3k/MDPPzu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is during the second etcupdate invocation (without the "-p" flag); I first noticed it today, during the update from: FreeBSD 15.0-PRERELEASE #320 main-n279987-9764aa1ccad0: Mon Sep 1 11:30:06= UTC 2025 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.am= d64/sys/GENERIC amd64 1500063 1500063 to: FreeBSD 15.0-PRERELEASE #321 main-n280001-405cfeef615f: Tue Sep 2 11:03:25= UTC 2025 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.am= d64/sys/GENERIC amd64 1500063 1500063 The log shows: =2E.. installing DIRS ROOTDIR install -N /usr/src/etc -d -m 0750 -o root -g wheel /var/db/s4/etcupdate= /etcupdate-ZO4ftQW/root install -N /usr/src/etc -C -o root -g wheel -m 644 /usr/src/bin/sh/dot.s= hrc /var/db/s4/etcupdate/etcupdate-ZO4ftQW/root/.shrc install -N /usr/src/etc -C -o root -g wheel -m 644 /usr/src/bin/sh/dot.p= rofile /var/db/s4/etcupdate/etcupdate-ZO4ftQW/root/.profile install -N /usr/src/etc -l mr -o root -g wheel -m 644 ,config /var/db/s4/et= cupdate/etcupdate-ZO4ftQW/root/.profile /var/db/s4/etcupdate/etcupdate-ZO4f= tQW/.profile install: target directory `/var/db/s4/etcupdate/etcupdate-ZO4ftQW/.profile'= does not exist usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] [-M log] [-D dest] [-h hash] [-T tags] [-B suffix] [-l linkflags] [-N dbdir] file1 file2 install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] [-M log] [-D dest] [-h hash] [-T tags] [-B suffix] [-l linkflags] [-N dbdir] file1 ... fileN directory install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner] [-M log] [-D dest] [-h hash] [-T tags] directory ... *** Error code 64 Stop. make[5]: stopped making "installconfig" in /usr/src/bin/sh *** Error code 1 [end of log excerpt] This is my "build machine," which (as shown above) just runs GENERIC; I don't even have a custom kernel config to sully the pristine sources. :-} freebeast(15.0-P)[9] git status -vv On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean freebeast(15.0-P)[10] (I tried "etcupdate extract -B" on another machine that I keep updated at the same cadence, and it had a similar whine -- which is how I noticed this one.) Help? 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. --ChpKOsy3k/MDPPzu Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaLb2WV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5VaZAP9DbW3FPDOg9C14t94ljSy0KVbStQhofErXuPDHdgfW7AD+LjW83DLVM/7f 4yOys++6uUC8Z3b5xDtx9A2Zq0FInwE= =AJtT -----END PGP SIGNATURE----- --ChpKOsy3k/MDPPzu-- From nobody Tue Sep 2 13:55:00 2025 X-Original-To: freebsd-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 4cGS1H5FVlz66lXW for ; Tue, 02 Sep 2025 13:55:15 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4cGS1H10y6z3f6F for ; Tue, 02 Sep 2025 13:55:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 582Dt096094243; Tue, 2 Sep 2025 22:55:02 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756821303; bh=WqL1xzAA6EdLksmwJrCHHKEFE2VAX6VYwZP0Mysr5hQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KRw6nK6XQ0wEHIOEnqKIWkMvkK8X+uaAkEmpiwpYzv9cgZ4T++gkdyGfOOI/St8WR FtJF2w4cUOwSRuGg02uv76y3Wbh5l1uVwL6YpnbqzkIro07359TXe47HoRKllprC6n VddObDlIlDvXFZmZd7YTwRZjjul7AAS1vFkG63sY= Date: Tue, 2 Sep 2025 22:55:00 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Poul-Henning Kamp , Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250902225500.70577e08c0584754e743bac9@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGS1H10y6z3f6F On Mon, 1 Sep 2025 21:02:45 -0600 Warner Losh wrote: > On Mon, Sep 1, 2025 at 5:42 AM Tomoaki AOKI > wrote: > > > On Mon, 1 Sep 2025 03:15:50 -0600 > > Warner Losh wrote: > > > > > On Mon, Sep 1, 2025, 3:05 AM Poul-Henning Kamp > > wrote: > > > > > > > -------- > > > > Tomoaki AOKI writes: > > > > > > > > > > > > > > > … it would be nice to have something like 'recovery partition', > > as > > > > > > some OSes have. or at least some tiny fail-safe feature. having > > remote > > > > > > machine in some distant datacenter, booting from a flashstick is > > > > always > > > > > > a problem. > > > > > > > > I thought that is what /rescue is for ? > > > > > > > > > > That only works if your boot loader can read it... I've thought for a > > > while now that maybe we should move that into a ram disk image that we > > fall > > > back to if the boot loader can't read anything else... > > > > > > Warner > > > > Exactly. If the loader (or bootcode to kick the loader in the > > partition/pool) can sanely read the partition/pool to boot from, > > I think /rescue is enough and no need for rescue "partition / pool". > > > > But once the partition / pool to boot is broken (including lost > > decryption key for encrypted partitions/drives from regular place), > > something others are needed. > > > > And what can be chosen to boot from BIOS/UEFI firmware depends on > > the implementation (some could restrict per-drive only, instead of > > every entry in EFI boot manager table). > > > > If BIOS/firmware allow to choose "drive" to boot, rescue "drive" > > is useful, if multiple physical drives are available. > > > > Yes, rescue mfsroot embedded into loader.efi would be a candidate, too, > > if the size of ESP allows. > > > Rescue is quite small. On the order of 8MB compressed. The trouble is that > the kernel is like 12MB compressed, plus we'd need a few more modules. > Still, we could likely get something under 25MB that's an MD image that we > could boot into, but it would have to be single user. And It's been a while > since I did that... Typically I just run /rescue/init or /rescue/sh, which > isn't a full system and still uses the system's /etc. If we customized it > per system, we could do better, since the kernel can be a bit smaller > (compressed our kernels at work are 6MB), so under 20MB could be possible. > We'd not need /boot/loader.efi in there. Oh, much smaller than I've expected! Actually, using boot1.efi (either stock or patched), users of Root on ZFS can have rescue UFS partition on the same drive. This is because it looks for /boot/loader.efi to kick from ZFS pool first, then, UFS. This is per-drive priority and if both are NOT found, boot1.efi looks for another drive with the order that UEFI firmware recognized. (The first to try is the drive boot1.efi itself was kicked.) This is how smh@ implemented when I requested to fix boot issue on UEFI boot (at the moment, loader.efi cannot be kicked directly by UEFI firmware and needed boot1.efi). Maybe Warner would remember, before the fix, boot1.efi always looked for /boot/loader.efi with the order UEFI firmware recognized drives, thus, even if started from USB memstick for rescue, boot1.efi "always" kicked the first "internal" drive and cannot rescue. Yes, fresh installations was OK with it, as there's no /boot/loader.efi in any of internal drives. > If we could hook into the arch specific traps that cause segv, etc, we > could do a setjmp early and set 'safe mode' and restart. Though that may > be trickier than I initially am thinking... maybe the best bet is to let > uefi catch that failure and have the next bootable BootXXXX environment on > the list specify a safe mode. More investigation might be needed. > > Warner Yeah, and it could be (and would actually be) implementation-specific. Maybe chaotic in real world and lots of quirks would be required. -- Tomoaki AOKI From nobody Tue Sep 2 14:57:29 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 4cGTP9625Vz66r6k for ; Tue, 02 Sep 2025 14:57:33 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGTP95JfXz3pXn; Tue, 02 Sep 2025 14:57:33 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756825053; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8ZcvdUOJFYG5v+I+iMnj2/5TDBnsO4Az/Iao7fn44sE=; b=o4PVBz6DRyWv4MNFGTo+rIyh+JMTjtMJwsUY8d6xEs2G1D3ina6wq2eA6qP/j08BS2jFbE StD15kqE0W11IsQSjaqTFAsFZCV08VfPDNBulj+u0wolpYSRKHKYznEx+BoGw8c8ZTaLLa huydREOvVfmmkQVpDpNonxzAoTLxpjP1TcX1qovEKxIr8Q1F4u528QifLlqdTQkllf5hNN 5GKsdzjWNKQZ5bJCcdK3fNybMhHeuEJEuVj2lWpjjf029qyTdpj034Epe6Yc+vNBe6vI5S htoQGpOZqThUx030zfZdL3Qf5yY/MPN2f4tGlMkDUE0gfuLEM7r2l8+tcpWu1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756825053; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8ZcvdUOJFYG5v+I+iMnj2/5TDBnsO4Az/Iao7fn44sE=; b=yv3VCjg4z/ktkekbbnbgrHRglK6elsRGBn/7VX3P6rqkFBBD6D1vow/GuYg5OOba2gze3+ xupg/8YRvHkbcyEd444eqh8ehP0My5F+VhYfURK/k7wj9IhA4VoHh+pNNqmAUklJFAD5Ot MLcUh0Q/gL6zGhzdEBVpO0ZJABPaY6hs7WdG/mjmCiXFS+zf8b7MBv2LKXDvkfs1y01UXy z1edxgqsgZEE1iKs46RZm3pgF/8IIGVrHN96xP72+bIZ+SIfeha5AmqEcIFQiea5AcoYW0 9wVbn/5tuvcttQqBu2U4Elg6BHTiJM2S1bhxdpnzrE9u5fOqX2H3mPvYC+zGTg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756825053; a=rsa-sha256; cv=none; b=CibHooI3XSY3BiLGXjYjqFUN+4p2uJ2Fg+CqUz46s5f5tngKzLPf2P2CEnDb7PwWZopdYK msSSYnKgKVzD+Iyt/eCMCzPT5Vg6uaBntfA8GZFmbaRv3J67LoMjMEmjMhD5IlCHUXKof/ cMX9PxrlHcfAMwz0JWbUiEPI4jos5fuuCxfE+esMQDtpcToOSpeMQkop0dGCmBsekpWT1T LZmxo8L6+XWUeJgQr0OL4f8X4m8z7OxapxC4F7jQ4EW/oqrHSccrWL5uJvNEuqDTa2L4Ry OD/g4WnUR5AAxNLK5Ci4JjHlCt0zSiHNp5POBz2Ju329PTPfp5Dmsm5FRjZvkA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cGTP92dMqzPQC; Tue, 02 Sep 2025 14:57:33 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Tue, 2 Sep 2025 15:57:29 +0100 From: Lexi Winter To: David Wolfskill , current@freebsd.org Subject: Re: etcupdate whines "Failed to build new tree." Message-ID: Mail-Followup-To: David Wolfskill , current@freebsd.org References: 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="85+R1qLACRK9V4Gr" Content-Disposition: inline In-Reply-To: --85+R1qLACRK9V4Gr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi David, David Wolfskill: > install -N /usr/src/etc -l mr -o root -g wheel -m 644 ,config /var/db/s4/= etcupdate/etcupdate-ZO4ftQW/root/.profile /var/db/s4/etcupdate/etcupdate-ZO= 4ftQW/.profile > install: target directory `/var/db/s4/etcupdate/etcupdate-ZO4ftQW/.profil= e' does not exist this should be fixed by b197d2abcb68, could you please update and try again? sorry about that.=20 --85+R1qLACRK9V4Gr Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaLcF0wAKCRD1nT63mIK/ YEDOAQDIfBhPqsEiYA3apx7DU/LbSNM+ykGPgQ8w+Vt48RR0VQEAx5V/kjOrI4XB 1HNfODciahczSYl+4OtwLINJezCcqQI= =HXLn -----END PGP SIGNATURE----- --85+R1qLACRK9V4Gr-- From nobody Tue Sep 2 17:42:50 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 4cGY3w4lPBz674Nw for ; Tue, 02 Sep 2025 17:42: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 4cGY3v5YwBz3CrK for ; Tue, 02 Sep 2025 17:42:51 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 582HgoFO041484 for ; Tue, 2 Sep 2025 17:42:50 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 582HgorD041483 for current@freebsd.org; Tue, 2 Sep 2025 10:42:50 -0700 (PDT) (envelope-from david) Date: Tue, 2 Sep 2025 10:42:50 -0700 From: David Wolfskill To: current@freebsd.org Subject: Re: etcupdate whines "Failed to build new tree." Message-ID: Mail-Followup-To: David Wolfskill , current@freebsd.org References: 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="rV93RaO+AuA7D2Zu" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.35 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.947]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; 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)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: 4cGY3v5YwBz3CrK --rV93RaO+AuA7D2Zu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 02, 2025 at 03:57:29PM +0100, Lexi Winter wrote: > hi David, >=20 > David Wolfskill: > > install -N /usr/src/etc -l mr -o root -g wheel -m 644 ,config /var/db/s= 4/etcupdate/etcupdate-ZO4ftQW/root/.profile /var/db/s4/etcupdate/etcupdate-= ZO4ftQW/.profile > > install: target directory `/var/db/s4/etcupdate/etcupdate-ZO4ftQW/.prof= ile' does not exist >=20 > this should be fixed by b197d2abcb68, could you please update and try > again? Finally(!) had a chance to test; the change fixes the problem: before/after: freebeast(15.0-P)[4] sudo -E etcupdate -n -B Password: Failed to build new tree. freebeast(15.0-P)[5] sudo -E etcupdate -n -B freebeast(15.0-P)[6] > sorry about that.=20 No worries; thanks for the quick fix! 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. --rV93RaO+AuA7D2Zu Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaLcsmV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5YUfAP4qk2KDXP4by9Qj68nko2x+nM9mUuj2NbnMVNv5MGRN2wD8D0cyr0Xb+9PJ ay2z9OyBOiCRJFKAokitG2cyxO3tcAE= =oZLa -----END PGP SIGNATURE----- --rV93RaO+AuA7D2Zu-- From nobody Tue Sep 2 18:32:00 2025 X-Original-To: freebsd-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 4cGZ8n0Tb0z678Qp for ; Tue, 02 Sep 2025 18:32:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGZ8m2kq9z3W0C for ; Tue, 02 Sep 2025 18:32:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=KsWZZOZI; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=mavbsd@gmail.com Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-3d44d734cabso2087047f8f.3 for ; Tue, 02 Sep 2025 11:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756837922; x=1757442722; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=1zepjmsn7hKn86S1oe0tbeMgIq9lJ9a3nkvrLEWeicQ=; b=KsWZZOZIf+/ou/CAHp2n5b0EARSnji51g0KHAK9zHQBhMAj3lbk9KzU7Dh3QJoh/0u 6MytOSgYVNWps3kKcSxW8kc0qkqz67NhLwlxc5w5Y6VbHFnH+BTwfqSHc9I/xk1zENgr xcE6MCtiBenccKehbdvWZvCU+SteQrmlqttLENjtNCGi8pYsjFgFVXb75kTRmJ5RJhpb E5mqJclDAyNdHorH151WYVJCZ8GnVW0T0OXLaqUK2ySW1DhVg6pH1AimTAoPO5+8pv6q ui44SQ6xly+QbioAHOJB5EM29dCryzewFtQtPDwZx61Nk7N+F/suvMsGzfvmknPi94Op 1nRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756837922; x=1757442722; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1zepjmsn7hKn86S1oe0tbeMgIq9lJ9a3nkvrLEWeicQ=; b=hEA3XyqqmqxVSvUP1eUNS9FCtQXfyXYSuPhhDqDPoGxnHR0jl1GHcebx2w2v2YRGkh UfQFNbj28Ng6l/GfkJT8WbyuE9OjLslmoI6ah/A0M2gj3iydWbecqPGecwNVgbMI1RPo k4CUurU2PRw72xn3IGgZaWskzBBXcmgqKuTQ33hKbKxNaeKun9Iu9/jNHQjjtdNO/UfS qbjfNLXQi1KBgwHksIU52whVSZNA63sf+G560FiHkNJGMuXZWHBqCahIWzxQbG7ZtD7N lbadvo8JsV1NrtAoLmDEjZrruVyeMU+qOPZP0F5UNjvbml2omWthejAc+BpOcXXMlCFs w+pw== X-Forwarded-Encrypted: i=1; AJvYcCU6D5jOboJge2daqzGv4hF0U2meJV1Ed2ITAH93TUEvgZctGR+sg2Z/k07nPhRrUYX/5TgJwaUUS03tWBgFSBc=@freebsd.org X-Gm-Message-State: AOJu0YwOoAPKAW6W7+Ien+HCXYEg60JmwrsRIadmW0mbHryyVX166Prk UJ31Ph87exh8Km28vci6WD3h7ui6EK9PXADPdv6FQ2kWYVzoz13sXdCtnLhzKRsgYUZYEQ== X-Gm-Gg: ASbGncuOq0MgA3sK/9sK3Na9/Vjm/TOosP0BMxw8x5JbmH1qGs+ouM6TuX+6TOiVlov hDQxooVHNb+Q2s2SWhZ7whLb1os5uU5q/0e10pyFPSksKz6T0tJ3Ch1+X4xbU44wwVd7+E7j4/D vD4vtZVCwo03olNHzDYvODSNrgJO6SVZ+HhzMLltcJ6KLXajABNazVc82C3KwQnuSGcfhyyK+Yh PIllHEiRzTfvZ6u807+UkVlh+uvHq4R8k/IKrvzTf4dBaVXaY+fz5zTe2ZxK7kvT4FHxvpvOQTw 04gDJ0V0WS30A6d70e7k2vggwvhHOmEJ9X/hb156ntE9478sYdQZEwVHWaqfzRpW0l1sLNkhCsM +f5A21tYLM51N4x+UPvqYQxO1nBGlPUjIDxT+X9e77UKFndxjPPLEPdiEMJII X-Google-Smtp-Source: AGHT+IExwg7xLGGc28lLosbMhwt0ZFOXhGPHPzexNxVrVBZgjbMgDEkRvTfwXiUaij7g3AAQ8P2ijw== X-Received: by 2002:a05:6000:2689:b0:3d4:7657:3a42 with SMTP id ffacd0b85a97d-3d476574ecemr5840613f8f.3.1756837921803; Tue, 02 Sep 2025 11:32:01 -0700 (PDT) Received: from [192.168.1.3] (89-109-102-5.ptr89.nosmadeira.net. [89.109.102.5]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d2250115fdsm15120300f8f.40.2025.09.02.11.32.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 11:32:01 -0700 (PDT) Message-ID: <9d8f3fa4-b550-4d49-9724-a9eaa08ae7c9@FreeBSD.org> Date: Tue, 2 Sep 2025 14:32:00 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: reviving ZFS in broken sm_start+sm_size state To: Dmitry Morozovsky , freebsd-current@FreeBSD.org References: Content-Language: en-US From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from] X-Rspamd-Queue-Id: 4cGZ8m2kq9z3W0C Hi Dmitry, This is a space map corruption, that could happen even some time before the reboot. You should be able to import the pool read-only to evacuate the data, since read-only import does not load space maps. Unfortunately without having any reproduction of the actual corruption we might not be able to understand how it happened. It might be either software of hardware, so unless you have ECC RAM, you may wish to test it. You may also try to use `zdb -emmmm ...` to dump the metaslabs on the pool and look for more corruptions and their patterns, hoping it give any more ideas. On 01.09.2025 11:22, Dmitry Morozovsky wrote: > Dear colleagues, > > after some (AFAIR clean) reboot of current with ZFS-on-root I had (OCRed from > mobile photo but hopefully good enough) unbootable system with the following > panic: > > --- 8< --- > panic: VERIFY3U(entry_offset, <, sm->sm_start + sm->sm_size) failed (1847270282567680 < 92341796864) > > cpuid = 2 > time = 1756738203 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0149c856d0 > vpanic at vpanic+0x136/frame 0xfffffe8149c85800 > spl_panic at spl_panic+0x3a/frame 0xfffffe0149c85860 > space_map_iterate() at space_map_iterate+0x3b1/frame 0xfffffe0149c85920 > space_map_load_length() at space_map_load_length+0x5f/frame 0xfffffe8149c85970 > metaslab_load() at metaslab_load+0x529/frame 0xfffffe8149c85a40 > metaslab_activate() at metaslab_activate+0x46/frame 0xfffffe8149c85a88 > metaslab_alloc_dva_range() at metaslab_alloc_dva_range+0x7f9/frame 0xfffffe0149c85bb0 > metaslab_alloc_range() at metaslab_alloc_range+8x2c2/frame 8xfffffe8149c85c70 > metaslab_alloc() at metaslab_allo > zio_dva_allocate() at 0xfffffe0149c85cc0 > zio_execute() at zio iraframe 0xfffffe0149c85e10/frame 0xfffffe0149c85e40 > taskqueue_run_locked) at taskqueue_run_locked+0x1c2/frame 0xfffffe0149c85ec0 > taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe0149c85ef0 > fork_exit() at fork_exit+0x82/frame 0xfffffe0149c85f30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0149c85f30 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 0 tid 101011] > Stopped at > --- 8< --- > > attempts to boot from last snapshot and/or trying to boot from PRERELEASE and > zpool import lead to exactly the same results, even with different '-F' > options: > > pool *seems* to be importable but actually isn't due to mad entry_offset as I > can see from source > > any hints how could I resolve this? the pool content itself is not **very** > important, but avoiding recreation would be nice -- Alexander Motin From nobody Tue Sep 2 18:53:21 2025 X-Original-To: freebsd-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 4cGZdR085Cz679tD; Tue, 02 Sep 2025 18:53:31 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGZdQ1pjdz3ZcV; Tue, 02 Sep 2025 18:53:30 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XxTyx2YW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-45b8b2712d8so28047955e9.3; Tue, 02 Sep 2025 11:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756839203; x=1757444003; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:to:from:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dT6o6/p2K72t7C4tm9yj4V872NqzOODp9kGA5NolH9w=; b=XxTyx2YWBW9/WUKHj6GXErE5JWJN+Mwe90VFCofFD2z0UI28cOHlWEktvTaMyFnwNi +GkFcW011Nx3bLqlUd7/bFfHVauO9M9qzIC49oPffkaLQWgTSi1jhFBCVJi86ZsKrPHr 0jZT2WeXMtV69s3eE86jWVGih4FBcOfVXl85dqxY4tBYdhRFUDcPuxqA0cdZerZieulr E6tGk8LmeOaqb80FhTlSH6q7WoifLo4Fzo9A4FHaZ5D+ZXX0yyLP4bE3RVHrK5FrXC8s Q+35nUaO65J4d9rTVPijpudzaYkMuFMydQihltTZuVf1llDBNxvZmzmizonxz/07hjTc V8vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756839203; x=1757444003; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dT6o6/p2K72t7C4tm9yj4V872NqzOODp9kGA5NolH9w=; b=J5fUF62K5dkttXuDgPreFP3N+oU6paueVdlgYypO/7N0ghYK6Su2Gx1hFMVQo99PLd j/3uvjDwEMNooCsG70m6f5Gb4Yf37sZHFFFMVUuriRsCv3YPlkja1jIpmo2+GfjeoGri NKZ1G4C15Pr5s6tvwRnEVyWsr3XxKsS2UTJMOowaCJbEaO3/uZ2x8/lPMcRPvJMvVE2h NSQ1ltM8e76KDMB9CfMWGAF2vEjZXAKf5HiFt92Rq4VrR0m9gn1KIii9cz/ZEF5kMuy/ CSXeMlY9e/CDO04igxzVdoqRrDTZzFIY85ZPWRWQBhKPTpDzxOYSj+10WHpl6LqMhJJO 15YA== X-Forwarded-Encrypted: i=1; AJvYcCWcMJOQ2MGw7998paxwVSZIB6HR3Zl+v56wR3ST/y7MRtfJvK9vcxIJXHzR03oAHQ9FWYExCxOgJ8zUKPu+4Ug=@freebsd.org X-Gm-Message-State: AOJu0Yykfps8X4Ep+BTKlYURjK7WO541XFQ+jm0Un3/cc3K7XhsvyIBO d/9UGxElKBA/UC/P+GzK4XQBFxuZhh6ElbouIhlwLdHTlAbfwaK24icx5Qx5mw== X-Gm-Gg: ASbGnctdzT2xUqCD/OHVhziWL3U6UkzPEFTtOHwVA0akEDhJOz81sh7ICy9Igq8OAmO uMIoTIVgTsLsPCCD9kHQAwhovi0QhemZ9BjBn6tTs9KE3WtqOe383aPlJGSWKSRAwQM+co7/dsY ezQ0nvpMNnF3YU6vcHEl3YH+I3R2wdqxMI6pW1768N5TxOw3yE2NDrfwHdt6jYQFxjtTMmQBRoI IBKwzpNN9Z+1DoHl01yaxzCLj+BCw9Oma468xHdaOVr2oLDhM/gTOsFxJrEoKlWr+tKqf/hDV13 gj7sS6n3abTVCNvmksySBqqbGEI30/seHjw2F/hwuHK+tclMvRXXTZ0xxbVUQVGmHi2bRROsToj 5N1DGdkQ+CAtOzE/noYLgNoyLtf0uKc5BcCZCZd30RkqiVkA8OhU1ekInSFY= X-Google-Smtp-Source: AGHT+IEz6EJ8lm6DCJ3GtlTzvcrcPu4G+PtOpAGtWgrz1PQ7l3SQvHghBfEJKbLIFi52O+FqQhmeJA== X-Received: by 2002:a05:600c:c0d1:20b0:45b:9c93:d21d with SMTP id 5b1f17b1804b1-45b9c93d324mr12073095e9.8.1756839202413; Tue, 02 Sep 2025 11:53:22 -0700 (PDT) Received: from [192.168.1.4] (host-89-241-205-78.as13285.net. [89.241.205.78]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e8ab832sm207255965e9.23.2025.09.02.11.53.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Sep 2025 11:53:21 -0700 (PDT) Message-ID: <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> Date: Tue, 2 Sep 2025 19:53:21 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD From: Graham Perrin To: FreeBSD-CURRENT References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> Content-Language: en-GB Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJoRALAAhsDBQkPEg5ABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQL8YkP/2V1z6XQDyG1QlKAu8TuE8zDWy9QQKjC/G44hlu5zk+2kWSNk4zeExs9ZXOBmVhF EW1d+1J8wDiYIeKYj/rqMoP+gb8o0Au0lSRitvTdLxkZBFGMn0CEzlDOzv+wmiy0ggAV/s+Y EbiHk12fI0LoTy5/ywdmG/uGS7M6p3XOrM0YO1qmLXy1cUyYDsYIpq5/rT0QzpGowsJLoEA3 zz1vfKVY+RTorsL4W8ljXLmcs4c3b3HZG9Xmgtt+Ni/eb9CjzM7kCXOcSMnVzvfscCowPAwB 0ZHlNxNV0MTa61xgvOCk4Zf278ArRgbTm4oOz9Z4ciPMnVue+9P/VdxIxgUuYkAryM0+agGz L9bd8ljn+efNtgZ5dlDLrNnTE+vWnMVlMXgl7BNnhwHg7UYFLrC2xklsICub0qpnNheTGeqo 0N4UongJTQJ6H6LEpgd+KMkCncAHghED/G0/BUdO90VEOoqnIKwKa+F9NqVMvHWc8D58mwCP FghsmxK9FM9pnsjLmG7u+s51Y7++GSRnU4NkI4tHiVk7hcAcvZuc0QbUDwVMTurDUgIqRo6W 80j1tFjEspkrwtMoeVFEkDHktjoc3AoEymXIncZfqIqi3nVseyDVyNByvkV0mutX9hXqac0/ RXMuyK9KniAUZ9+gsWs4rPs/DOdsw4K8/RnjduBrfCYQzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmhEAsACGwwFCQ8SDkAACgkQt2dIb0oY1AvQxw//REWYFK2m4yS/QP5kzfhkWcNqDI/akGT5 /LXmdmbc1s78+mOMXnA4vBY/+X1QatgxWUECkPDOiIwXJMxoBuyY8e7spLRXeyhtfh5aYaJc MO5bARX0c49v+KfZ80u9tG2rkKQvAt/ySo7OXsbDADFFRhlc8RLbb8e7bSctGbYZk9CYa0ya dW5+n3znDNJ6yW1skx9wTH+Y8VlSazRLk3XgXscNqBA2h56v3WS/R5dI++7AQxZxSQacQvfj 9eahq7ATdB4zMQ9MBHEwOvGD3DLlc55FYSDZvNX+mhnK7S0t1Nt2EtGUOmXb5ysMFGnbsce0 woKQ0sLPF1HWDAAf7tBCF8mpPIzU/ViAkupsJ6NYCD0tLFD8pvl0NYU2TjvyWh6ie3e5B/b3 8Daiyme+M92ivfoRQOFKmkPfeT14AI6OW1k7qFbmoIwMWWQdFWAl1CP9hNdF9gRN4rFB0Jy1 90BajZW2zOdVfqdurJZegCzAowZalLm4JEK2MklpPzipibnJqhLOmvJy587pF52KDdM/4rLy BBREIm7uRivnO5k/BY5qS+H/aqv97LC0PVaTsLXbDmTxTnJplUpdlYT9NGidM+x/ioS0iztO Cht7cT8V8jvvKZYvNpst8iqxuIaoV9V7aZ0wAQpkgDGXHmSzwtz6U8xNf/4e4sLn9KPlldSd kvo= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkgbase@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4cGZdQ1pjdz3ZcV On 01/09/2025 02:58, Graham Perrin wrote: > An enhancement to bsdinstall could, before creation of the partition > table, allow the user to specify an amount of space to be left free at > the end of a device … For now, short term, is the (simple) free space idea attractive? Longer term: I'm not averse to more complex enhancements around e.g. /rescue/, however I _do_ like the idea of free space. Freedom for the user to do whatever they want. They might, or might not, want to use the space for the content of FreeBSD-15.0-RELEASE-amd64-memstick.img … and so on. Maybe this overlaps with ZFS-specific bsdinstall report . From nobody Tue Sep 2 19:01:39 2025 X-Original-To: freebsd-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 4cGZq15SHYz67Bhj for ; Tue, 02 Sep 2025 19:01:49 +0000 (UTC) (envelope-from woozle@woozle.net) Received: from wzl.woozle.net (wzl.woozle.net [195.54.192.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4cGZq12L2Bz3bwW; Tue, 02 Sep 2025 19:01:49 +0000 (UTC) (envelope-from woozle@woozle.net) Authentication-Results: mx1.freebsd.org; none Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by wzl.woozle.net (Postfix) with ESMTP id 1C69E73B; Tue, 02 Sep 2025 22:01:42 +0300 (MSK) Received: from localhost (woozle.rinet.ru [195.54.192.68]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id 582J1drH031458; Tue, 2 Sep 2025 22:01:41 +0300 (MSK) (envelope-from woozle@woozle.net) Date: Tue, 2 Sep 2025 22:01:39 +0300 (MSK) From: Dmitry Morozovsky X-X-Sender: marck@woozle.rinet.ru To: Alexander Motin cc: freebsd-current@FreeBSD.org Subject: Re: reviving ZFS in broken sm_start+sm_size state In-Reply-To: <9d8f3fa4-b550-4d49-9724-a9eaa08ae7c9@FreeBSD.org> Message-ID: References: <9d8f3fa4-b550-4d49-9724-a9eaa08ae7c9@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-ID: 6B691B03 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: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [195.54.192.68]); Tue, 02 Sep 2025 22:01:41 +0300 (MSK) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:31363, ipnet:195.54.192.0/19, country:RU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGZq12L2Bz3bwW Alexander, nice to hear from ya! On Tue, 2 Sep 2025, Alexander Motin wrote: > Hi Dmitry, > > This is a space map corruption, that could happen even some time before the > reboot. You should be able to import the pool read-only to evacuate the data, ah, that mostly straightforward idea somehow missed my mind! and yes, I confirm zpool import -o readonly=on -R /mnt did not panic, and `find -s /mnt` produced reasonable result > since read-only import does not load space maps. Unfortunately without having > any reproduction of the actual corruption we might not be able to understand > how it happened. It might be either software of hardware, so unless you have > ECC RAM, you may wish to test it. You may also try to use `zdb -emmmm ...` to > dump the metaslabs on the pool and look for more corruptions and their > patterns, hoping it give any more ideas. well, as I said, there's not much data to evacuate, good enough backups are in place, so I'd rather try to do smth to locate and hopefully help to fix underlying bugs output from which commands would be useful? thanks again! > > On 01.09.2025 11:22, Dmitry Morozovsky wrote: > > Dear colleagues, > > > > after some (AFAIR clean) reboot of current with ZFS-on-root I had (OCRed > > from > > mobile photo but hopefully good enough) unbootable system with the following > > panic: > > > > --- 8< --- > > panic: VERIFY3U(entry_offset, <, sm->sm_start + sm->sm_size) failed > > (1847270282567680 < 92341796864) > > > > cpuid = 2 > > time = 1756738203 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe0149c856d0 > > vpanic at vpanic+0x136/frame 0xfffffe8149c85800 > > spl_panic at spl_panic+0x3a/frame 0xfffffe0149c85860 > > space_map_iterate() at space_map_iterate+0x3b1/frame 0xfffffe0149c85920 > > space_map_load_length() at space_map_load_length+0x5f/frame > > 0xfffffe8149c85970 > > metaslab_load() at metaslab_load+0x529/frame 0xfffffe8149c85a40 > > metaslab_activate() at metaslab_activate+0x46/frame 0xfffffe8149c85a88 > > metaslab_alloc_dva_range() at metaslab_alloc_dva_range+0x7f9/frame > > 0xfffffe0149c85bb0 > > metaslab_alloc_range() at metaslab_alloc_range+8x2c2/frame > > 8xfffffe8149c85c70 > > metaslab_alloc() at metaslab_allo > > zio_dva_allocate() at 0xfffffe0149c85cc0 > > zio_execute() at zio iraframe 0xfffffe0149c85e10/frame 0xfffffe0149c85e40 > > taskqueue_run_locked) at taskqueue_run_locked+0x1c2/frame 0xfffffe0149c85ec0 > > taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame > > 0xfffffe0149c85ef0 > > fork_exit() at fork_exit+0x82/frame 0xfffffe0149c85f30 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0149c85f30 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > KDB: enter: panic > > [ thread pid 0 tid 101011] > > Stopped at > > --- 8< --- > > > > attempts to boot from last snapshot and/or trying to boot from PRERELEASE > > and > > zpool import lead to exactly the same results, even with different '-F' > > options: > > > > pool *seems* to be importable but actually isn't due to mad entry_offset as > > I > > can see from source > > > > any hints how could I resolve this? the pool content itself is not **very** > > important, but avoiding recreation would be nice > > -- Sincerely, D.Marck [MCK-RIPE] [ FreeBSD committer: marck@FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle@woozle.net *** --------------------------------------------------------------------------- From nobody Tue Sep 2 19:08:32 2025 X-Original-To: freebsd-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 4cGZyq41k0z67CPg for ; Tue, 02 Sep 2025 19:08:35 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from wzl.woozle.net (wzl.woozle.net [195.54.192.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4cGZyq33WLz3dlX for ; Tue, 02 Sep 2025 19:08:35 +0000 (UTC) (envelope-from marck@rinet.ru) Authentication-Results: mx1.freebsd.org; none Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by wzl.woozle.net (Postfix) with ESMTP id 2D6AB73C; Tue, 02 Sep 2025 22:08:34 +0300 (MSK) Received: from localhost (woozle.rinet.ru [195.54.192.68]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id 582J8Ww4031829; Tue, 2 Sep 2025 22:08:34 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 2 Sep 2025 22:08:32 +0300 (MSK) From: Dmitry Morozovsky To: Graham Perrin cc: FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD In-Reply-To: <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> Message-ID: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-ID: 6B691B03 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: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [195.54.192.68]); Tue, 02 Sep 2025 22:08:34 +0300 (MSK) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:31363, ipnet:195.54.192.0/19, country:RU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGZyq33WLz3dlX On Tue, 2 Sep 2025, Graham Perrin wrote: > On 01/09/2025 02:58, Graham Perrin wrote: > > An enhancement to bsdinstall could, before creation of the partition > > table, allow the user to specify an amount of space to be left free at the > > end of a device ? maybe not at he end, as it would prevent VM disk from grow-in-place, but between EFI and other? (this is also why I think swap should be located before actual data space) > > > For now, short term, is the (simple) free space idea attractive? > > Longer term: I'm not averse to more complex enhancements around e.g. /rescue/, > however I _do_ like the idea of free space. > > Freedom for the user to do whatever they want. They might, or might not, want > to use the space for the content of FreeBSD-15.0-RELEASE-amd64-memstick.img ? > and so on. Maybe this overlaps with ZFS-specific bsdinstall report > . > > -- Sincerely, D.Marck [MCK-RIPE] [ FreeBSD committer: marck@FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle@woozle.net *** --------------------------------------------------------------------------- From nobody Tue Sep 2 19:25:59 2025 X-Original-To: freebsd-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 4cGbMG6ljGz65GHD for ; Tue, 02 Sep 2025 19:26:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGbMG4l3Mz3gmT for ; Tue, 02 Sep 2025 19:26:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-327771edfbbso5802588a91.0 for ; Tue, 02 Sep 2025 12:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756841172; x=1757445972; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ocqLVk+omQbAJc57yq5LEAy7i4YWe4zVt88QZI8IKOI=; b=v19+UedB4yNaZlb/3HvT+yNQHnWd4NahyoTdiNldQU48J/mujiPhaDxz2fT/iWeres rgJWLMDrG9+29g8w4DYaJQaJSw8XEcm49mNrWXzTgxoltpa32DcnbKYvQkBjlUV33Evf zs1AvZtiSPjDwINx6VyFcT52GcIiYsaYfi1ArK2kjPFuIO4f3mmLh/BkQsSvYARJuc/A SMXeW4KFekwP3bObqYeNX/dkfijO5SXhNsqvuRMMIXbZtZebCgMHV1nfKJ+nFB1k5XlH i7p8wanWhIBA4qE0Qq+SmL3cYOeX/KiCK7DepdIqodiIubg/ajBf8JZ2w7brr3oJ7Azn 9wzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756841172; x=1757445972; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ocqLVk+omQbAJc57yq5LEAy7i4YWe4zVt88QZI8IKOI=; b=opFdkOauyouLarOJ29xW0zOJzDBK857Ig408HLvCy0unhx/wEzunlTacis1aT5bi4p r4JntSoaROTNbOLmD9vob+SsIyngZHai1PRlRcaagR3w/82RJ1J5JbiYFxYE49gDMeI8 Ufxbf1V86WMeShljrLfaI409eyL3I2yzdxyvs632PeDVJIPcC+F7iXJ3si2nVHyEtD1H OJX7aYL2KZvyEQajcG7uCKsJjKnVMTSmFa6HSA8atD5gSxjervNgAmrB7XZNry2spYbP JfvjmESEr6/vu3xM0yL+UoE8+3JoR7t+1FW1+/TtXTVoymvwu9JhdebiZ4hi0+Jvr08+ sXtw== X-Forwarded-Encrypted: i=1; AJvYcCXWTKmivu05eQUPcZQq3g0YWq3zzy4WzVVK9k4LtWBmW3Bk2iLHSGCv7nTQwRr4V8ihAzIaO+qOHjyndus7ecA=@freebsd.org X-Gm-Message-State: AOJu0YwWbcsmEqSPlAEHU08xI8+8tkmSicdFCyguitk8zUbwPTYuG+O/ 86lXIs+veukUCoV8XAyavqwGgSOlo3bVUCIfQ9ecFm6cGw5Vo8ikpEaixEzNH37fpv/6+nUN3PQ gvk295C1Y11fxkCKPcIE8car8siteI/vTffiISYdNNg== X-Gm-Gg: ASbGncvP0Sx8JAErZBfdZUV9rtKGL7nSV9vdZ6YcT5/nHeNxDWgiW0GVCJkHh6xMdow NckXfNmZTrJsW3pDv3N/FmNJ6KXgBXz8dmx/X0yPt2497Hxhj20fiF8UgZKD8d1vPABFe9aiytN 4+DBczV83Fq5+HUkjeZceRtCSh2CaqirVO2UOCi20+wwn75a4ne3dFOhGc/wcPtc9hp+nVpuGEo OGRYuxB2ffXyHb0oYvsxZC1VpkIKca4vC63o8TfAk4O7F+A2w== X-Google-Smtp-Source: AGHT+IGKLemKNt5QdOebjjgKgwx512YBxC2n1s0v/+46Hzl2wLc9cwwOBOmmrXRRaQjp9Nhm71SnNVqUAsZgBRhVCDs= X-Received: by 2002:a17:90b:53cc:b0:327:9e88:7714 with SMTP id 98e67ed59e1d1-328156f991bmr16946151a91.37.1756841172110; Tue, 02 Sep 2025 12:26:12 -0700 (PDT) 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 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> <20250902225500.70577e08c0584754e743bac9@dec.sakura.ne.jp> In-Reply-To: <20250902225500.70577e08c0584754e743bac9@dec.sakura.ne.jp> From: Warner Losh Date: Tue, 2 Sep 2025 13:25:59 -0600 X-Gm-Features: Ac12FXykis3u2BNDkHNazu5ONsF3yToZDldPgTL_isFLIgLEFYpIMSaTfxCkajc Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Tomoaki AOKI Cc: Poul-Henning Kamp , Graham Perrin , FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="000000000000fda580063dd675bf" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGbMG4l3Mz3gmT --000000000000fda580063dd675bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 7:55=E2=80=AFAM Tomoaki AOKI wrote: > On Mon, 1 Sep 2025 21:02:45 -0600 > Warner Losh wrote: > > > On Mon, Sep 1, 2025 at 5:42=E2=80=AFAM Tomoaki AOKI > > wrote: > > > > > On Mon, 1 Sep 2025 03:15:50 -0600 > > > Warner Losh wrote: > > > > > > > On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp > > > wrote: > > > > > > > > > -------- > > > > > Tomoaki AOKI writes: > > > > > > > > > > > > > > > > > > =E2=80=A6 it would be nice to have something like 'recover= y > partition', > > > as > > > > > > > some OSes have. or at least some tiny fail-safe feature. havi= ng > > > remote > > > > > > > machine in some distant datacenter, booting from a flashstick > is > > > > > always > > > > > > > a problem. > > > > > > > > > > I thought that is what /rescue is for ? > > > > > > > > > > > > > That only works if your boot loader can read it... I've thought for= a > > > > while now that maybe we should move that into a ram disk image that > we > > > fall > > > > back to if the boot loader can't read anything else... > > > > > > > > Warner > > > > > > Exactly. If the loader (or bootcode to kick the loader in the > > > partition/pool) can sanely read the partition/pool to boot from, > > > I think /rescue is enough and no need for rescue "partition / pool". > > > > > > But once the partition / pool to boot is broken (including lost > > > decryption key for encrypted partitions/drives from regular place), > > > something others are needed. > > > > > > And what can be chosen to boot from BIOS/UEFI firmware depends on > > > the implementation (some could restrict per-drive only, instead of > > > every entry in EFI boot manager table). > > > > > > If BIOS/firmware allow to choose "drive" to boot, rescue "drive" > > > is useful, if multiple physical drives are available. > > > > > > Yes, rescue mfsroot embedded into loader.efi would be a candidate, to= o, > > > if the size of ESP allows. > > > > > > Rescue is quite small. On the order of 8MB compressed. The trouble is > that > > the kernel is like 12MB compressed, plus we'd need a few more modules. > > Still, we could likely get something under 25MB that's an MD image that > we > > could boot into, but it would have to be single user. And It's been a > while > > since I did that... Typically I just run /rescue/init or /rescue/sh, > which > > isn't a full system and still uses the system's /etc. If we customized = it > > per system, we could do better, since the kernel can be a bit smaller > > (compressed our kernels at work are 6MB), so under 20MB could be > possible. > > We'd not need /boot/loader.efi in there. > > Oh, much smaller than I've expected! > > Actually, using boot1.efi (either stock or patched), users of Root on > ZFS can have rescue UFS partition on the same drive. > This is because it looks for /boot/loader.efi to kick from ZFS pool > first, then, UFS. This is per-drive priority and if both are NOT found, > boot1.efi looks for another drive with the order that UEFI firmware > recognized. (The first to try is the drive boot1.efi itself was kicked.) > > This is how smh@ implemented when I requested to fix boot issue > on UEFI boot (at the moment, loader.efi cannot be kicked directly > by UEFI firmware and needed boot1.efi). > This isn't true, at least not generally. We load loader.efi in all new installations by default. I've fixed a number of issues around this from the past... We're not able to use it at netflix to boot off of ZFS, for example... > Maybe Warner would remember, before the fix, boot1.efi always looked for > /boot/loader.efi with the order UEFI firmware recognized drives, > thus, even if started from USB memstick for rescue, boot1.efi > "always" kicked the first "internal" drive and cannot rescue. > Yes, fresh installations was OK with it, as there's no /boot/loader.efi > in any of internal drives. > Yea, I'm not remembering it... > > If we could hook into the arch specific traps that cause segv, etc, we > > could do a setjmp early and set 'safe mode' and restart. Though that m= ay > > be trickier than I initially am thinking... maybe the best bet is to le= t > > uefi catch that failure and have the next bootable BootXXXX environment > on > > the list specify a safe mode. More investigation might be needed. > > > > Warner > > Yeah, and it could be (and would actually be) implementation-specific. > Maybe chaotic in real world and lots of quirks would be required. > I don't understand that part... It would be architecture specific, but why would it be implementation specific? Warner --000000000000fda580063dd675bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 2, = 2025 at 7:55=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Mon, 1 Sep 2025 21:02:45 -0600
Warner Losh <imp@bsd= imp.com> wrote:

> On Mon, Sep 1, 2025 at 5:42=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.ne.jp<= /a>>
> wrote:
>
> > On Mon, 1 Sep 2025 03:15:50 -0600
> > Warner Losh <imp@bsdimp.com> wrote:
> >
> > > On Mon, Sep 1, 2025, 3:05=E2=80=AFAM Poul-Henning Kamp <<= a href=3D"mailto:phk@phk.freebsd.dk" target=3D"_blank">phk@phk.freebsd.dk>
> > wrote:
> > >
> > > > --------
> > > > Tomoaki AOKI writes:
> > > >
> > > >
> > > > > >=C2=A0 > =E2=80=A6 it would be nice to have= something like 'recovery partition',
> > as
> > > > > > some OSes have. or at least some tiny fail-sa= fe feature. having
> > remote
> > > > > > machine in some distant datacenter, booting f= rom a flashstick is
> > > > always
> > > > > > a problem.
> > > >
> > > > I thought that is what /rescue is for ?
> > > >
> > >
> > > That only works if your boot loader can read it... I've = thought for a
> > > while now that maybe we should move that into a ram disk ima= ge that we
> > fall
> > > back to if the boot loader can't read anything else... > > >
> > > Warner
> >
> > Exactly. If the loader (or bootcode to kick the loader in the
> > partition/pool) can sanely read the partition/pool to boot from,<= br> > > I think /rescue is enough and no need for rescue "partition = / pool".
> >
> > But once the partition / pool to boot is broken (including lost > > decryption key for encrypted partitions/drives from regular place= ),
> > something others are needed.
> >
> > And what can be chosen to boot from BIOS/UEFI firmware depends on=
> > the implementation (some could restrict per-drive only, instead o= f
> > every entry in EFI boot manager table).
> >
> > If BIOS/firmware allow to choose "drive" to boot, rescu= e "drive"
> > is useful, if multiple physical drives are available.
> >
> > Yes, rescue mfsroot embedded into loader.efi would be a candidate= , too,
> > if the size of ESP allows.
>
>
> Rescue is quite small. On the order of 8MB compressed. The trouble is = that
> the kernel is like 12MB compressed, plus we'd need a few more modu= les.
> Still, we could likely get something under 25MB that's an MD image= that we
> could boot into, but it would have to be single user. And It's bee= n a while
> since I did that... Typically I just run /rescue/init or /rescue/sh, w= hich
> isn't a full system and still uses the system's /etc. If we cu= stomized it
> per system, we could do better, since the kernel can be a bit smaller<= br> > (compressed our kernels at work are 6MB), so under 20MB could be possi= ble.
> We'd not need /boot/loader.efi in there.

Oh, much smaller than I've expected!

Actually, using boot1.efi (either stock or patched), users of Root on
ZFS can have rescue UFS partition on the same drive.
This is because it looks for /boot/loader.efi to kick from ZFS pool
first, then, UFS. This is per-drive priority and if both are NOT found,
boot1.efi looks for another drive with the order that UEFI firmware
recognized. (The first to try is the drive boot1.efi itself was kicked.)
This is how smh@ implemented when I requested to fix boot issue
on UEFI boot (at the moment, loader.efi cannot be kicked directly
by UEFI firmware and needed boot1.efi).

This isn't true, at least not generally. We load loader.efi in all new= installations by default. I've fixed a number of issues around this fr= om the past... We're not able to use it at netflix to boot off of ZFS, = for example...
=C2=A0
Maybe Warner would remember, before the fix, boot1.efi always looked for /boot/loader.efi with the order UEFI firmware recognized drives,
thus, even if started from USB memstick for rescue, boot1.efi
"always" kicked the first "internal" drive and cannot r= escue.
Yes, fresh installations was OK with it, as there's no /boot/loader.efi=
in any of internal drives.

Yea, I'm= not remembering it...
=C2=A0
> If we could hook into the arch specific traps that cause segv, etc, we=
> could do a setjmp early and set 'safe mode' and restart.=C2=A0= Though that may
> be trickier than I initially am thinking... maybe the best bet is to l= et
> uefi catch that failure and have the next bootable BootXXXX environmen= t on
> the list specify a safe mode. More investigation might be needed.
>
> Warner

Yeah, and it could be (and would actually be) implementation-specific.
Maybe chaotic in real world and lots of quirks would be required.

I don't understand that part... It would be = architecture specific, but why would it be implementation specific?

Warner=C2=A0
--000000000000fda580063dd675bf-- From nobody Tue Sep 2 19:26:53 2025 X-Original-To: freebsd-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 4cGbNC40xWz65GKm for ; Tue, 02 Sep 2025 19:27:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGbNC1ngjz3hhq for ; Tue, 02 Sep 2025 19:27:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-b4c53892a56so4947483a12.2 for ; Tue, 02 Sep 2025 12:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756841224; x=1757446024; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2r5EHqyZ+YZSqXpeBMBR+5ZjBZ66vFlSuk3XmQ2/Yv4=; b=vMX3rCPjZNmMc43dWkesvfmgA/nxkrn7kEaI+aI+X9v6dQ/gYrphc0uzlrvqFRuSH0 8mTLSthjxAl+kDXgk0teU8x+FVGqBSS+Lq84bs5d8iko1Ag/rBtJM6SXmnSoayoWwtFM 0qHQTNsJL6+Q422EvA8Xb8jPHQjB3DrKI9gn+B76epqbObOJHdnvKRPckHSAQGVL7Dlx ArsTtgNS5ZWc0agkdEYXI7PNH+nj+aWbmT1Q5bVXcLf8BHQuA25vUWpg2VaHFcsNxxIl 1RqO8gwImFZ8y3QjirAuilacqA8STJYApQ0EYaYDilLqMWvT+UByzqXNdOj9R2tTTjR5 9uXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756841224; x=1757446024; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2r5EHqyZ+YZSqXpeBMBR+5ZjBZ66vFlSuk3XmQ2/Yv4=; b=nYL3aMGV5bX/OPo/EVz3wqIIBB1Dh+d45iSD2ARvvSYGcWM0VHw6XFgUHX6xu8bNVT ay/rET1pqEdiKG0QHBuOiGh7dRzUQ1Td/PS04aUoq9EZ1wF4kFsZ/bx4Zmr2Tvvi09cf WUIY+fCVmDbkJ0/TD9wC1RVqsCYZw+apDQJPVwC/ufv7ku8YsSxbbz3Fyr5g5FFcMOyt iBkmNmXNBSW8xw+QJLzsibbxy/VPrpqjuxuoVRrKzkXn6MapKzZvvHab0HLSnYCOc3SD WRz1ysvJ+oqEF5bUMXYZXQPfvuynhIJp6g1lssjZboVBdeoyxU+w+eskSKVPTBF1INYY MfwA== X-Gm-Message-State: AOJu0YwDSpOmKxAUmBV3E11hIiDe8tTgFEt6p+38/8optxtNlTAw3t+u wxrQTXtIJtsmRCffIOqfgBFheWj8cpymwzPlOjNY+o3ksosCdckI/Y0r0z6aperdBpvYSnDwXPR VWU+Ab0ugwqEuzm9Mw5aBFJUsRLWZzOjgtruhlER0DSmqq7y99Q5TGRQ= X-Gm-Gg: ASbGncsC3bRDHVWVMF3hoVtBdXXuUQb4ezId08X4R+BA6TFfogE85ZMhvC0p6lILmkB 4Yvicc8TOdGKtxgmqFp2tqaY+IWr4qrfgWVuWvr5RPiMCIaMEOU1/N1+pKgGdvZbbbjP1Xp8MTQ U7LFP772xbSCWHM0szvr5Tlh2ZQly3+MMK0Wye9haauDP7c4FT1v9/RRd6EIgWBRoqXwg+fGv6G VRc4j7AF6ClpPdkDQ4VswnSTC32XMrPpeGqHcs= X-Google-Smtp-Source: AGHT+IFcIixKyEPD+u+PSGPnVCFhge1inIJefD51pxAJmVHxTrpHUuB3Jzv5+Qc+JeCzEYGDvf92fNxHL2BzEneDaH4= X-Received: by 2002:a17:90b:28cf:b0:325:e89:e59d with SMTP id 98e67ed59e1d1-328156c61c7mr17592089a91.23.1756841224626; Tue, 02 Sep 2025 12:27:04 -0700 (PDT) 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 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> In-Reply-To: <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> From: Warner Losh Date: Tue, 2 Sep 2025 13:26:53 -0600 X-Gm-Features: Ac12FXzvicHuL4OF1KMPl9kmziVDWDC8vDQwKv0MiEvs0d2e-muTKzn1y3sYe-s Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Graham Perrin Cc: FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="0000000000001ef6b4063dd679d8" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGbNC1ngjz3hhq --0000000000001ef6b4063dd679d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 12:53=E2=80=AFPM Graham Perrin wrote: > On 01/09/2025 02:58, Graham Perrin wrote: > > An enhancement to bsdinstall could, before creation of the partition > > table, allow the user to specify an amount of space to be left free at > > the end of a device =E2=80=A6 > > > For now, short term, is the (simple) free space idea attractive? > > Longer term: I'm not averse to more complex enhancements around e.g. > /rescue/, however I _do_ like the idea of free space. > > Freedom for the user to do whatever they want. They might, or might not, > want to use the space for the content of > FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Maybe this o= verlaps > with ZFS-specific bsdinstall report > . > Things are small enough, I'd rather just create it in the ESP directly. Special reserved space on disks are nothing but a pain. Warner --0000000000001ef6b4063dd679d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 2, = 2025 at 12:53=E2=80=AFPM Graham Perrin <grahamperrin@gmail.com> wrote:
On 01/09/2025 02:58, Graham Perrin wrote:<= br> > An enhancement to bsdinstall could,=C2=A0before creation of the partit= ion
> table,=C2=A0allow the user to specify an amount of space to be left fr= ee at
> the end of a device =E2=80=A6


For now, short term, is the (simple) free space idea attractive?

Longer term: I'm not averse to more complex enhancements around e.g. /rescue/, however I _do_ like the idea of free space.

Freedom for the user to do whatever they want. They might, or might not, want to use the space for the content of
FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Maybe this ove= rlaps
with ZFS-specific bsdinstall report
<https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D242983>.

Things ar= e small enough, I'd rather=C2=A0just create it in the ESP directly. Spe= cial reserved space on disks are nothing but a pain.

Warner
--0000000000001ef6b4063dd679d8-- From nobody Tue Sep 2 20:47:12 2025 X-Original-To: freebsd-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 4cGd8z6xTPz65Q9b for ; Tue, 02 Sep 2025 20:47:31 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGd8z4rgvz3xPn for ; Tue, 02 Sep 2025 20:47:31 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3d17f24d42fso2519903f8f.1 for ; Tue, 02 Sep 2025 13:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756846044; x=1757450844; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=JAnQMMdkXSMRCg0LvMc+oAvvYcEI487t7mqq74qbQdU=; b=clF2+Li40m/uD8joNaZSlC1lEQkEnFUxNa+SRqMmXBWu35wJgDgmsXmjtTAoRJ3VSB GpUqCGl0HnKySVU7At1QNNYv3bPcliYhflk//mizaBplfv9d4jfO7skghtlKiEfLGkZ6 txOuhUh1yM/Yn+YsDol9cALjWdeWRUA/vLnYqGA6Mvfls79k5f07puKIi0zt39ovum9d Z359EoHXmeoXXJtWNblUMtNbdbCUtKqkP1gE+KJp71c3s2xF+AC+xkf0v73b7/mPD/s/ IxH7aCvgNH1651bk75AJiN4eMjIm1lKVAyOCX4BOEXAZ0wa4YI8nzTLWCuQRXVSXnVIe yuyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756846044; x=1757450844; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JAnQMMdkXSMRCg0LvMc+oAvvYcEI487t7mqq74qbQdU=; b=KlEvKRHVJXuHAXS1zNF9nVPxLuYKAVkgW2KGzaZhxHMSjDwoLHoJ0ccC2Xk/Ikhht3 ZHZJNkkFYjW4jODHzUTJnzylBuDZTkWrkwkzgAF7ptaXsux1XAntMM1qttsdeBb9btXC vJOv54g+v1qcvW3cgqSXV6RdlwRxqHKF/NsjRG2cItqS0whRNvmhXmSHKfeI4OG6YofQ O7jg4hgz3D3nKzc3npNF6TUyynLXIU+9ESffbM9Ude7WdA5riKRz9tmkNwwbzlHNaZhr 8MHb05ag5cbp8LnqsZRDX3lYdDhVE/XnUWFD4KPgMrg2syQ3BELUkwOfB8VW2iWRohjD 2YVA== X-Gm-Message-State: AOJu0YzlDVxmcimsOd0G6I9LfyXdeyz/waZpcl6duk9IIfro9THrep7T 1Lk5bPUkYDqns0yr1BHB0QomfUeBMdtT/RlQjxlm7qA4p+ogtq/wDOtPAGrnIA== X-Gm-Gg: ASbGnctunkxmIKYyTxgeru8n+AZ125fWiT2l+Ydo3Cp6JxwDeIubMtfPqzDHxY4ZJn/ b43k8KA9ahxX910nhFRWcpbQFFRCrvwd4je5UjH3WYwMtCLXkrKG22YkoJXRmS5ldLzSooC7z5l 0h/0OuOypf4oIR+tK7GrULkJyjykUsealhP4SRXTS3b4euiqNaCsU5WcFzWIvHG1bj3ami10Gxv ratavDDr5gMH9/HjDQq9BZB+jlW72HZwGdBqAHjNKOs/gbEvxfG25wyQRCae382BqHEUQOlDpC1 VTZu9ovC3nMk90pK3InowI2kwTDxHMSYcXyLQBUCVj/kYL3xzDQ0YvUyzI9bkAYBI35UmWhkFVC U2LEFpM2f4qCHCoxJ05e66w4fuBVAnyEHF7tcKDrpHpt2VHYmsBtwJMC8Bb1HKwd6enerrlkyWt 0Kbl39fCpL587bv3i+5nU= X-Google-Smtp-Source: AGHT+IEsvKNNU9FqFPQCnGUhp6kQ4YOfS8eERMQXp195ElkjwCL1fbUUZ3oMwYklb2KNRmGW6W5nJg== X-Received: by 2002:a05:6000:2311:b0:3c7:6348:4086 with SMTP id ffacd0b85a97d-3d1dc5a27f6mr8564146f8f.1.1756846044300; Tue, 02 Sep 2025 13:47:24 -0700 (PDT) Received: from smtpclient.apple (77.118.167.247.wireless.dyn.drei.com. [77.118.167.247]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b87632365sm162618205e9.16.2025.09.02.13.47.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Sep 2025 13:47:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Lizbeth Mutterhunt, Ph.D" 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 (1.0) Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Date: Tue, 2 Sep 2025 22:47:12 +0200 Message-Id: References: <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> Cc: FreeBSD-CURRENT In-Reply-To: <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> To: Graham Perrin X-Mailer: iPhone Mail (23A5330a) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGd8z4rgvz3xPn Take an external SSD via USB (decide which size is needful) format it as= ZFS, probably stripe, lock the system in bootloader and encrypt RAM. Then d= efault partition size should be default maybe adjust swap to at least 4g.= =20 > Op 02.09.2025 om 20:53 heeft Graham Perrin het vo= lgende geschreven: >=20 > =EF=BB=BFOn 01/09/2025 02:58, Graham Perrin wrote: >> An enhancement to bsdinstall could, before creation of the partition tabl= e, allow the user to specify an amount of space to be left free at the end o= f a device =E2=80=A6 >=20 >=20 > For now, short term, is the (simple) free space idea attractive? >=20 > Longer term: I'm not averse to more complex enhancements around e.g. /resc= ue/, however I _do_ like the idea of free space. >=20 > Freedom for the user to do whatever they want. They might, or might not, w= ant to use the space for the content of FreeBSD-15.0-RELEASE-amd64-memstick.= img =E2=80=A6 and so on. Maybe this overlaps with ZFS-specific bsdinstall re= port . >=20 >=20 From nobody Tue Sep 2 22:02:38 2025 X-Original-To: freebsd-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 4cGfqr3y1kz65mlP for ; Tue, 02 Sep 2025 22:02:48 +0000 (UTC) (envelope-from jgopensource@proton.me) Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (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 (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGfqp4lYgz3DqL for ; Tue, 02 Sep 2025 22:02:46 +0000 (UTC) (envelope-from jgopensource@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=Hxw0sDOc; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of jgopensource@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=jgopensource@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1756850562; x=1757109762; bh=pdbZCQbLs1AqxZgx2VNFpxyvM0+J778NEiIsIfbHE+I=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Hxw0sDOcSxkbve1+iWGiV+ZLeqkaIXhpwtB7KK0gFJ6+g0sbsqp+hWBQuqeNjnB0u Z0B0Ouxy3+fxVZ8Uz1Zgb2x4ZmHfwQe/TPJb91DqzoTmdj0jtQVeMOxO4eZTjW8byC 5NgkfjoZ/Z5RMHIDEcgTTPcVWN1zXRrqI1WWlTf00mLh7UOmWpUYOqH8vFMQXwuJ15 fFi/qvKqOYCi7RnzEvOCqRfOiT4O4Y4x4VGtqXdTBDTSGGsNoY498YORiyKeLDyZcm L2UvjGJFD2kTXkLH0A9mXrIDKQ/wJrwsXSco3WX6N1GanHH8+LmdcPnoT8sbB4rT+y nFcZ6BrP6WqIg== Date: Tue, 02 Sep 2025 22:02:38 +0000 To: FreeBSD-CURRENT From: Jordan Gordeev Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-ID: In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> Feedback-ID: 125078299:user:proton X-Pm-Message-ID: f1ddf0e8108e6744e70bd79153a6fe13bb872562 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.43.16:from]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_NONE(0.00)[185.70.43.16:from]; DKIM_TRACE(0.00)[proton.me:+] X-Rspamd-Queue-Id: 4cGfqp4lYgz3DqL On Tuesday, 2 September 2025 at 22:27, Warner Losh wrote: >=20 >=20 > On Tue, Sep 2, 2025 at 12:53=E2=80=AFPM Graham Perrin wrote: >=20 > > On 01/09/2025 02:58, Graham Perrin wrote: > > > An enhancement to bsdinstall could, before creation of the partition > > > table, allow the user to specify an amount of space to be left free a= t > > > the end of a device =E2=80=A6 > >=20 > >=20 > > For now, short term, is the (simple) free space idea attractive? > >=20 > > Longer term: I'm not averse to more complex enhancements around e.g. > > /rescue/, however I _do_ like the idea of free space. > >=20 > > Freedom for the user to do whatever they want. They might, or might not= , > > want to use the space for the content of > > FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Maybe this= overlaps > > with ZFS-specific bsdinstall report > > . >=20 >=20 > Things are small enough, I'd rather just create it in the ESP directly. S= pecial reserved space on disks are nothing but a pain. >=20 I think the user should have a choice between a small rescue image residing= as a file in the EFI System Partition and a big rescue image with more fea= tures residing in its own dedicated partition. On some machines the ESP wil= l be too small for the first option so the option for a separate partition = should definitely be supported. I want to suggest an enhancement to the default loader.efi (the one with th= e Lua interpreter) which will work for all styles of rescue images. Let's a= dd a "rescue" command to the loader which will read and execute the script = /efi/freebsd/rescue.lua from the ESP. The user can place a small rescue ima= ge in the ESP and write there a suitable rescue.lua script that can activat= e it, or they can create a whole rescue partition and write a different res= cue.lua script to the ESP that knows how to activate the rescue partition. = It will be a small change to the loader but at the same time it will be qui= te flexible. >From the user's perspective, if the boot fails and you are left at the load= er's prompt, you just type "rescue". Users will probably pick from ready-ma= de rescue images, each one coming with the necessary rescue.lua script, so = there will be nothing difficult for the user to do. Best regards, Jordan Gordeev From nobody Tue Sep 2 22:16:21 2025 X-Original-To: freebsd-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 4cGg7l3Pktz65p8C for ; Tue, 02 Sep 2025 22:16:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGg7l0XTMz3H6g for ; Tue, 02 Sep 2025 22:16:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-7726c7ff7e5so1502630b3a.3 for ; Tue, 02 Sep 2025 15:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1756851392; x=1757456192; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m6CgK5eqQCIFGukDdKwFfo3pcR+SCRcWc77+WxUwhZY=; b=VQZb5ysW6wXUQC0JZEOJMh4Oks89PXwEXTRxjjWarU/SJGYtH+1x15TcmytxK0Oycp UKaxEHoidukdeijJ4+86tb2VaBdwQcZd04Q3O9RXRKCwTjBHVDsOlAXQ7JUkurR5j7k2 fv0nYhaLwuksPE4vRsqryoAsCkbrEWfhk5ZmTNfBWgVgW7+fWBukhejScFbM+W3FO/IK dE7PWP8IyKtm3NP1mVYn/kRVPFLEU15bD0bZ2eD1K0fLok9v2ZHhOEuCOI4GDeLXL1TP RjH9Fc4lORhp5Hy/8Cf3nPJ/RGWpfvRfbw9zS2sogaDVa9rnARxjvid7Jux5f1tRAeup tRXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756851393; x=1757456193; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m6CgK5eqQCIFGukDdKwFfo3pcR+SCRcWc77+WxUwhZY=; b=C80RwEiKVv+JsfhdOmaHIklkBt7vxxnCL+g7txx84tH/3yG0IBnWGdDRiBkDgrvMyb 1XZAi8ap83ys0imih/+LjCKMLBOIrAmI/439f6BFF+9xZqe2kdMjtfAnm6DzdEWk+9WP ZLRFwKneOlVMwPA3I3JKuQN8ErQY9UcCkdAHFtslLCDAd1swf2/mccO4lDPUnQFtBL8y qjQ/OoatzgbpDoeygQqqoE1Qw1aH1yY6QJ3Hq/zogQo0h4wAzlsSTgf78nZ3utFs5uJU 8dCpWWyeURRx+8x9kchpI6j9vKoCmXTGGTNrktmfMZ+8e2ObFpyx8tXghs9J8IDPlbUf xqew== X-Gm-Message-State: AOJu0Yxy3kgUisg2qvkNsd8bNUd6kAngM8KCNF5Pt7rXKNeL1kOVSg6U HQm2cn8hN3eszIeOd6xgORLZkyqeaigGElCPELFP7FUIfA1My5kXYVPsazXubl1P6YuVqNeh71+ DolwE/pmTLzpJNPoidfHyzl9WwVsCWk5lUzLmtFfFkA== X-Gm-Gg: ASbGnctv1Vh+CW/X4b/5LUQi+pmHXjkjMaIwq64Ie2Qy7Nqc6mbGnPdJnPGDqpN1jdw NYQisDrhkL5q8yhangV4dS3vhC9I8aV3UejfkJIQTBpaiuZDoEP6Oxsb2EElxNyEtyKRDKuzLzO xaeZB69psvULwSgZCZn8PAy2xgtB0kvF2VPofup03LbLdAbD5ghFyIYwzz6fuhU1cEadvTKj0Vq EgWIwWkFnDK7BvN0YkyjmR9RFU0XHztZEUNFTY= X-Google-Smtp-Source: AGHT+IFDqHJoWaaby81sdbpQ0v5hKDaqL/jSyeje8lpoo1IUuChLB1qqJDuC1SdpB6mOuzWcrLPyeded5vH4w9u8x5E= X-Received: by 2002:a05:6a20:394b:b0:240:489:be9a with SMTP id adf61e73a8af0-243d6e0110emr16919438637.23.1756851392483; Tue, 02 Sep 2025 15:16:32 -0700 (PDT) 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 References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> In-Reply-To: From: Warner Losh Date: Tue, 2 Sep 2025 16:16:21 -0600 X-Gm-Features: Ac12FXxpQ8NtthJsyVaktBL9UGMJuhDxhq1RId77Q4S0Mx8tiPsx3sPZ3WNSvgQ Message-ID: Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Jordan Gordeev Cc: FreeBSD-CURRENT Content-Type: multipart/alternative; boundary="0000000000002c24c9063dd8d744" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGg7l0XTMz3H6g --0000000000002c24c9063dd8d744 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2025 at 4:03=E2=80=AFPM Jordan Gordeev wrote: > On Tuesday, 2 September 2025 at 22:27, Warner Losh wrote= : > > > > > > > On Tue, Sep 2, 2025 at 12:53=E2=80=AFPM Graham Perrin > wrote: > > > > > On 01/09/2025 02:58, Graham Perrin wrote: > > > > An enhancement to bsdinstall could, before creation of the partitio= n > > > > table, allow the user to specify an amount of space to be left free > at > > > > the end of a device =E2=80=A6 > > > > > > > > > For now, short term, is the (simple) free space idea attractive? > > > > > > Longer term: I'm not averse to more complex enhancements around e.g. > > > /rescue/, however I _do_ like the idea of free space. > > > > > > Freedom for the user to do whatever they want. They might, or might > not, > > > want to use the space for the content of > > > FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Maybe th= is > overlaps > > > with ZFS-specific bsdinstall report > > > . > > > > > > Things are small enough, I'd rather just create it in the ESP directly. > Special reserved space on disks are nothing but a pain. > > > > I think the user should have a choice between a small rescue image > residing as a file in the EFI System Partition and a big rescue image wit= h > more features residing in its own dedicated partition. On some machines t= he > ESP will be too small for the first option so the option for a separate > partition should definitely be supported. > I disagree. Or rather, I'm implementing the first thing only, and somebody else will have to deal with the second. > I want to suggest an enhancement to the default loader.efi (the one with > the Lua interpreter) which will work for all styles of rescue images. Let= 's > add a "rescue" command to the loader which will read and execute the scri= pt > /efi/freebsd/rescue.lua from the ESP. The user can place a small rescue > image in the ESP and write there a suitable rescue.lua script that can > activate it, or they can create a whole rescue partition and write a > different rescue.lua script to the ESP that knows how to activate the > rescue partition. It will be a small change to the loader but at the same > time it will be quite flexible. > By making it its own partition, you have a lot of hair: The loader is stupid. It doesn't have a lot of smarts or protection and gets into trouble often (it's why we're having this discussion at all). Making the partition robust for recovery would be hard, and having it be unreliable isn't something I'll sign up for. And I'm not sure we have everything in Lua to write that script, so there'd likely be some efforts there. I do like the well defined 'rescue' option. > From the user's perspective, if the boot fails and you are left at the > loader's prompt, you just type "rescue". Users will probably pick from > ready-made rescue images, each one coming with the necessary rescue.lua > script, so there will be nothing difficult for the user to do. > Yes. But if they haven't setup the rescue with your plan, they'd be out of luck. That's why I'd like a small, targeted environment that's well defined that we can boot to. It will be without bells and whistles, but will be enough to recover. There will be an editor, commands to interact with the network, the storage stack, etc. But we'll need to be careful what else is in there. And it will be different choices from /rescue (though maybe rescue needs a rethink for several items, like including ipf). So I'd strongly suggest that we walk before we can run. Let's get something with a small, well-defined remit working, and we can iterate from there. Warner --0000000000002c24c9063dd8d744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 2, = 2025 at 4:03=E2=80=AFPM Jordan Gordeev <jgopensource@proton.me> wrote:
On Tuesday, 2 September 2025 at 22:27, War= ner Losh <imp@bsdimp= .com> wrote:

>
>
> On Tue, Sep 2, 2025 at 12:53=E2=80=AFPM Graham Perrin <grahamperrin@gmail.com&= gt; wrote:
>
> > On 01/09/2025 02:58, Graham Perrin wrote:
> > > An enhancement to bsdinstall could, before creation of the p= artition
> > > table, allow the user to specify an amount of space to be le= ft free at
> > > the end of a device =E2=80=A6
> >
> >
> > For now, short term, is the (simple) free space idea attractive?<= br> > >
> > Longer term: I'm not averse to more complex enhancements arou= nd e.g.
> > /rescue/, however I _do_ like the idea of free space.
> >
> > Freedom for the user to do whatever they want. They might, or mig= ht not,
> > want to use the space for the content of
> > FreeBSD-15.0-RELEASE-amd64-memstick.img =E2=80=A6 and so on. Mayb= e this overlaps
> > with ZFS-specific bsdinstall report
> > <https://bugs.freebsd.org/bu= gzilla/show_bug.cgi?id=3D242983>.
>
>
> Things are small enough, I'd rather just create it in the ESP dire= ctly. Special reserved space on disks are nothing but a pain.
>

I think the user should have a choice between a small rescue image residing= as a file in the EFI System Partition and a big rescue image with more fea= tures residing in its own dedicated partition. On some machines the ESP wil= l be too small for the first option so the option for a separate partition = should definitely be supported.

I disag= ree. Or rather, I'm implementing the first thing only, and somebody els= e will have to deal with the second.
=C2=A0
I want to suggest an enhancement to the default loader.efi (the one with th= e Lua interpreter) which will work for all styles of rescue images. Let'= ;s add a "rescue" command to the loader which will read and execu= te the script /efi/freebsd/rescue.lua from the ESP. The user can place a sm= all rescue image in the ESP and write there a suitable rescue.lua script th= at can activate it, or they can create a whole rescue partition and write a= different rescue.lua script to the ESP that knows how to activate the resc= ue partition. It will be a small change to the loader but at the same time = it will be quite flexible.

By making it= its own partition, you have a lot of hair: The loader is stupid. It doesn&= #39;t have a lot of smarts or protection and gets into trouble often (it= 9;s why we're having this discussion at all). Making the partition robu= st for recovery would be hard, and having it be unreliable isn't someth= ing I'll sign up for.

And I'm not sure we = have everything in Lua to write that script, so there'd likely be some = efforts there.

I do like the well defined 'res= cue' option.
=C2=A0
>From the user's perspective, if the boot fails and you are left at the = loader's prompt, you just type "rescue". Users will probably = pick from ready-made rescue images, each one coming with the necessary resc= ue.lua script, so there will be nothing difficult for the user to do.

Yes. But if they haven't setup the rescu= e with your plan, they'd be out of luck. That's why I'd like a = small, targeted environment that's well defined that we can boot to. It= will be without bells and whistles, but will be enough to recover. There w= ill be an editor, commands to interact with the network, the storage stack,= etc. But we'll need to be careful what else is in there. And it will b= e different choices from /rescue (though maybe rescue needs a rethink for s= everal items, like including ipf).

So I'd stro= ngly suggest that we walk before we can run. Let's get something with a= small, well-defined remit working, and we can iterate from there.

Warner
--0000000000002c24c9063dd8d744-- From nobody Tue Sep 2 23:16:53 2025 X-Original-To: freebsd-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 4cGhTW4ypwz65v1L for ; Tue, 02 Sep 2025 23:17:03 +0000 (UTC) (envelope-from SRS0=BOPz=3N=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGhTW2T1Nz3NZC for ; Tue, 02 Sep 2025 23:17:02 +0000 (UTC) (envelope-from SRS0=BOPz=3N=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id ECA9ED7899; Wed, 3 Sep 2025 01:16:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1756855014; bh=vdSh6ooCNtbzU9kbl9yVQqrfJEmhTl1hEVF+p0Xic+g=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=1wFabZ5NOuk//h2ZredvBmok2RbWuuMCnKONAdgBbQd9nBrQCFFfJ8fPFHWQRvWs8 0HtMRdS+UhMYkMXQfNxJU96Y+2pUdOImB6OJ1yDRfs4aI6N2RSrxcjDsKT2FVWYox1 DtYyMjOaHoyv3NyGEvaDstqK0ABd6uccNwfiVloQ= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C9940D7891; Wed, 3 Sep 2025 01:16:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1756855013; bh=vdSh6ooCNtbzU9kbl9yVQqrfJEmhTl1hEVF+p0Xic+g=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=PFLQmhZLOUSab6TRLa0ZZGlAFP9U40E9PA37XeI+OQgmMHNNeIZGOKNGKmnLklf0g 2TqCx0soutFepAfgBJC4gxTshCUIEFcbhX/WO5A8PpxNm0XgSIdwdMVz1+/kRy6ziB fckqIy3p+JZz1LXVFvQqrPovJyKWgIWdVlsGG51U= Message-ID: <114be0ca-dfb0-49bb-8c7d-323622940bea@quip.cz> Date: Wed, 3 Sep 2025 01:16:53 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD To: Warner Losh , Jordan Gordeev Cc: FreeBSD-CURRENT References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGhTW2T1Nz3NZC On 03/09/2025 00:16, Warner Losh wrote: > > > On Tue, Sep 2, 2025 at 4:03 PM Jordan Gordeev > wrote: [..] > Yes. But if they haven't setup the rescue with your plan, they'd be out > of luck. That's why I'd like a small, targeted environment that's well > defined that we can boot to. It will be without bells and whistles, but > will be enough to recover. There will be an editor, commands to interact > with the network, the storage stack, etc. But we'll need to be careful > what else is in there. And it will be different choices from /rescue > (though maybe rescue needs a rethink for several items, like including ipf). > > So I'd strongly suggest that we walk before we can run. Let's get > something with a small, well-defined remit working, and we can iterate > from there. > > Warner I definitely agree with the last paragraph. There have been so many cases where interesting ideas never came to be realized (or took many years to do so) simply because the discussion got out of hand and the original simple idea was killed by heavy arguments of excessive engineering. Start with a simple implementation that requires minimal effort, please. Kind regards Miroslav Lachman From nobody Wed Sep 3 01:20:18 2025 X-Original-To: freebsd-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 4cGlDD0tGKz665dY for ; Wed, 03 Sep 2025 01:20:44 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (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 ECDSA (secp384r1) client-digest SHA384) (Client CN "prime.gushi.org", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGlDB22K0z3Zg3 for ; Wed, 03 Sep 2025 01:20:42 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gushi.org header.s=prime2014 header.b=mTJVRCwU; dmarc=pass (policy=none) header.from=gushi.org; spf=pass (mx1.freebsd.org: domain of freebsd@gushi.org designates 2620:137:6000:10::142 as permitted sender) smtp.mailfrom=freebsd@gushi.org Received: from smtpclient.apple ([IPv6:2001:500:6b:200:8000:0:0:48]) (authenticated bits=0) by prime.gushi.org (8.18.1/8.18.1) with ESMTPSA id 5831KXJo043375 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 3 Sep 2025 01:20:34 GMT (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 5831KXJo043375 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1756862434; bh=xme+iaWOn9w3bQSX+32rCTWoBXuSnlb2D0O8G4sQFjo=; h=From:Subject:Date:To; z=From:=20"Dan=20Mahoney=20(Ports)"=20|Subject:= 20pkg=20broken?|Date:=20Tue,=202=20Sep=202025=2018:20:18=20-0700|T o:=20FreeBSD=20Current=20; b=mTJVRCwU7Ozh/I5YGbWZEC9GUjy9yUL0bwvunHxO8QuJ1RsS43cnDNC9ZHybI4om9 il/mkKzlW5WUXsUcoAIVYXiUAiz1B6TrkqDvrvEHQF6wzeuWeSXKMjDA8iPNGxOrc4 sFqTa0L164YlxDWrCNv0FpDzV+9mfI81i72nhNMkCoRuA24PyDqHWlE6lc741D2Xo6 QLhj8PpA7SRrSIXbPt+29+umW6XiZLcNFG448gW0P2GaHuvnVyUFD0Q2AQUuNm9yfC JFGJu/XpfQxAqA5gMTECunvc5pg5dpEHOqKwL4wRuKU9tiCIKKbdd1xVTcH8IuuGAx n7X9k1XuR8HIw== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2001:500:6b:200:8000:0:0:48] claimed to be smtpclient.apple From: "Dan Mahoney (Ports)" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: pkg broken? Message-Id: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> Date: Tue, 2 Sep 2025 18:20:18 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.49 / 15.00]; DWL_DNSWL_LOW(-1.00)[gushi.org:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[gushi.org,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[2620:137:6000:10::142:from]; R_DKIM_ALLOW(-0.20)[gushi.org:s=prime2014]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gushi.org:+]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:393507, ipnet:2620:137:6000::/44, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4cGlDB22K0z3Zg3 Hey all, After an update today to what looks like snap20250828153719.pkg, it = would seem pkg doesn=E2=80=99t want to play ball. root@poudriere-pkb:/etc/pkg # pkg update Updating FreeBSD-ports repository catalogue... FreeBSD-ports repository is up to date. Updating FreeBSD-ports-kmods repository catalogue... FreeBSD-ports-kmods repository is up to date. Updating FreeBSD-base repository catalogue... FreeBSD-base repository is up to date. Updating FreeBSD repository catalogue... pkg: packagesite URL error for = pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf -- pkg+:// = implies SRV mirror type pkg: packagesite URL error for = pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.txz -- pkg+:// = implies SRV mirror type repository FreeBSD has no meta file, using default settings pkg: packagesite URL error for = pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.pkg -- pkg+:// = implies SRV mirror type pkg: packagesite URL error for = pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.tzst -- pkg+:// = implies SRV mirror type pkg: packagesite URL error for = pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.pkg -- = pkg+:// implies SRV mirror type pkg: packagesite URL error for = pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.tzst -- = pkg+:// implies SRV mirror type Unable to update repository FreeBSD Error updating repositories! root@poudriere-pkb:/etc/pkg # uname -a FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE = main-n280004-00c9ebbbc653 GENERIC amd64 root@poudriere-pkb:/etc/pkg # freebsd-version 15.0-PRERELEASE Running bootstrap doesn=E2=80=99t seem to help: root@poudriere-pkb:/etc/pkg # /usr/sbin/pkg bootstrap -f The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from = pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest, please wait... Verifying signature with trusted certificate = pkg.freebsd.org.2013102301... done Installing pkg-2.2.2... package pkg is already installed, forced install Extracting pkg-2.2.2: 100% My /etc/pkg/FreeBSD.conf was replaced by a repo that changed = FreeBSD-kmods to FreeBSD-ports-kmods but is almost otherwise identical. = My pkgbase repo seems to be behaving, but=E2=80=A6.I think pkg stops on = any failures. Ideas? -Dan= From nobody Wed Sep 3 04:37:14 2025 X-Original-To: freebsd-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 4cGqb20w4tz66NNk for ; Wed, 03 Sep 2025 04:37:18 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGqb05hswz3sqD; Wed, 03 Sep 2025 04:37:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror); spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.33 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id tRMZuWZlf5MqytfFEuwrwA; Wed, 03 Sep 2025 04:37:16 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id tfFCuqgEoWbOatfFDuZ93y; Wed, 03 Sep 2025 04:37:16 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=68b7c5fc a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=zdPUvaFGAAAA:8 a=04oDvr9pAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=yHWkdCLj7hQfc61PRXkA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=fvD0gfNcX4AKPV7IvcuC:22 a=sT4bYkpex2i6d5iwGOJT:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 3D6C21B8; Tue, 02 Sep 2025 21:37:14 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 370F5311; Tue, 02 Sep 2025 21:37:14 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Gleb Smirnoff , Cy Schubert , freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration In-reply-to: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> Comments: In-reply-to Rick Macklem message dated "Mon, 01 Sep 2025 19:00:27 -0700." 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: text/plain; charset=us-ascii Date: Tue, 02 Sep 2025 21:37:14 -0700 Message-Id: <20250903043714.370F5311@slippy.cwsent.com> X-CMAE-Envelope: MS4xfBCmy9a9qtgshI6xBSik+gdg2pLfO5UHss9QTDg23PcU8m96a5fgjFSWwSiUTGEaDiehPvu8sG51lken6WM/9HQE6+c5b8VwFWnGBXPpgtp88KQimgde ac+FPGy4lclGiJs+lXGrCZgEk4WcreLKJRlF+yNWviptaZer+AbbrnrBWXGnZk+jjuRg6rUiA1s2guPboWLQK/FTwaB8b+PEQWXt332JJJxI2EsliHdxptHN ssrb8XIlFEmKcWb/rAzlgPAyLSpRc+ukxbQ9my+h/c4= X-Spamd-Bar: - X-Spamd-Result: default: False [-1.55 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.75)[-0.752]; MV_CASE(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.33:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4cGqb05hswz3sqD In message , Rick Macklem writes: > On Sun, Aug 31, 2025 at 5:58=E2=80=AFPM Rick Macklem m> wrote: > > > > On Sun, Aug 31, 2025 at 5:41=E2=80=AFPM Rick Macklem com> wrote: > > > > > > On Sat, Aug 30, 2025 at 9:47=E2=80=AFPM Rick Macklem l.com> wrote: > > > > > > > > On Sat, Aug 30, 2025 at 4:22=E2=80=AFPM Rick Macklem ail.com> wrote: > > > > > > > > > > On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem gmail.com> wrote: > > > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem m@gmail.com> wrote: > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem lem@gmail.com> wrote: > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem cklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem macklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff ebius@freebsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff= > wrote: > > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Mackl= > em wrote: > > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg ins= > tall heimdal", you get a > > > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > > > T> R> > > > > > > > > > > > T> R> Now, I have another challenge. Fixing the master = > passwords. > > > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > > > T> > > > > > > > > > > > T> I have applied two commits from Heimdal from 2012 th= > at add 'kadmin dump -f MIT' > > > > > > > > > > > T> feature to our base heimdal and polished them to com= > pile. So far it doesn't > > > > > > > > > > > T> work yet, either create an empty dump or create a co= > re dump, instead of > > > > > > > > > > > T> database dump :) I'll see how difficult it is going = > to further resolve that to > > > > > > > > > > > T> a working condition. If I succeed, then having 'dump= > -f MIT' in base without > > > > > > > > > > > T> any ports would be the best solution. Can also be m= > erged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my cha= > nge incorrectly - threw > > > > > > > > > > > the new binary on a system running unpatched libraries.= > When run correctly, > > > > > > > > > > > it successfully produced something that looks like a co= > rrect dump in MIT format. > > > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, though= > . > > > > > Well, would you like the not so bad news or the bad news??;-) > > > > > Your patch works, in that it produces a dump that "kdb5_util load > > > > > -update" can load. > > > > > After loading, if the principal only has keys for the newer encrypt= > ion types of > > > > > aes256-cts-hmac-sha1-96 > > > > > aes128-cts-hmac-sha1-96 > > > > > then you can look at the principal via kadmin.local, but the passwo= > rd must > > > > > be changed before it works. > > > > > --> This is the same behaviour as you get if you use Heimdal-7.8 to= > do the > > > > > dump conversion. > > > > > So far, so good... > > > > > > > > > > Now, the not so good news. Once you update the Heimdal libraries > > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the system > > > > > running the old KDC. "kadmin -l dump" works, but something like: > > > > > # kadmin -l > > > > > kadmin> get rmacklem > > > > > kadmin: get rmacklem: Service key not available > > > > > - I have not yet looked in your patched sources to see where this > > > > > failure comes from? > > > > > > > > > > Now, more not so good news... > > > > > My patch doesn't help. > > > > > It does re-encrypt the key in the master key from the MIT KDC > > > > > system, but that doesn't make the password work. > > > > > When I compared the dump generated via kadmin with both > > > > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > > > > is 34bytes long. > > > > > After doing the change_password so that it works, a dump > > > > > generated by "kdb5_util dump -r13" (the same dump format) > > > > > has a key that is 62bytes long. > > > > > --> So, there is more to converting the key than just re-ecrypting > > > > > it. (I'll try and find where the MIT code encrypts a key in a= > master > > > > > key to see why it ends up at 62bytes and whether that can be = > done > > > > > in the old code.) > > > > > > > > > > So, if we are going to continue with this... > > > > > - We need to figure out why your patch breaks "kadmin" for other > > > > > things and fix that. > > > > > - I/we need to figure out how to convert the 34byte key to the MIT > > > > > 62byte key (and then maybe the password won't need to be changed?= > ). > > > > > > > > > > Or do we just say "When you convert the KDC database, all the passw= > ords > > > > > must be changed to get them to work?". > > > > All I've got sofar is this patch... > > > > https://people.freebsd.org/~rmacklem/print.patch > > > > > > > > It tweaks entry2mit_string_int() so that it skips over the keys for > > > > old encryption types and fills in a fake "modified by" entry if none > > > > exists. > > > > > > > > These changes at least make the MIT dump such that the records > > > > don't end up "incomplete or corrupted" when you try to do something > > > > like "get_principal " in kadmin.local. > > > > > > > > As noted, your patch makes "kadmin -l" break for most things, > > > > reporting "Service key not available". The failures go away if > > > > you revert back to the non-patched libraries. > > > > I have not located the problem yet. > > > > > > > > As for the passwords...no luck yet, rick > > > Finally..it works. (First off, apologies for all the posts, just ignore > > > them.;-) > > > > > > The patch is at: > > > https://people.freebsd.org/~rmacklem/kadmin.patch > I just updated the patch with a fix for the case where the > Heimdal principal does not have any keys for string encryption. > (That is fixed now and I haven't found any other bugs, so I > think I am done playing with it. Yippee!!) > > Please test when you can find the time, rick I think the problem is with OpenSSL 3.5. With the legacy provider loaded in OpenSSL 3.5 I get, test3# openssl list -providers Providers: default name: OpenSSL Default Provider version: 3.5.1 status: active test3# Whereas in 3.0 I get, bob# openssl list -providers Providers: default name: OpenSSL Default Provider version: 3.0.16 status: active legacy name: OpenSSL Legacy Provider version: 3.0.16 status: active bob# Some symbol must be missing. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Wed Sep 3 04:37:09 2025 X-Original-To: freebsd-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 4cGqbD1XYnz66N9G for ; Wed, 03 Sep 2025 04:37:28 +0000 (UTC) (envelope-from bT.410kv90e11a1v16=6yn6vuix0gpb=h772p1xasvg6kg@em598416.pentode.fi) Received: from e2i707.smtp2go.com (e2i707.smtp2go.com [103.2.142.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGqbC5ZZTz3stX for ; Wed, 03 Sep 2025 04:37:27 +0000 (UTC) (envelope-from bT.410kv90e11a1v16=6yn6vuix0gpb=h772p1xasvg6kg@em598416.pentode.fi) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mctqo0.a1-4.dyn; x=1756875147; h=Feedback-ID: X-Smtpcorp-Track:Message-ID:Subject:To:From:Date:Reply-To:Sender: List-Unsubscribe:List-Unsubscribe-Post; bh=2hnREq3vDLXvxuEy4gq6eSydKtCpJCwrGFJ95x+vN3Q=; b=iEYmHR71JhckKHmlMD3h98mjep Nav4bJ425Ty++9eANiLmOVrRD212YUOoJ2eHISJOwJkQ/Fjawbu12HA6J0mCKANYhYvU6R2xVl90F hzWF1Ns1EnqjBytTU4Wnc/+Nzj53KwQa+LQBaor7rxmyhu5/qYWa0Bkt41hUNKVFoFX93s49Ty3Yh aO34zfWOdCaNTgRZdo345mXbWJuZcDirRTHmhaJcSTqUHQ4CyU7/Q4nGAMuvWxkAoe13/PdF5zLfn IdWKyb6o+/qEQzvLXC8Azo5jTVyD5z/5zNPikqpwrAoqFBcNDGsEr+Bi3RmxIroHMghDJDUJMyani x9zq+UMA==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pentode.fi; i=@pentode.fi; q=dns/txt; s=s598416; t=1756874247; h=from : subject : to : message-id : date; bh=2hnREq3vDLXvxuEy4gq6eSydKtCpJCwrGFJ95x+vN3Q=; b=XwQEyBaVKV01GskoA/5Rnoi8HNWgsarpbetCa18bbTdfq1n7meCq3qK/Ey4UGoL3wrDle ur6g+kS9g3zEHZRV5W5uzMrZKIgbl1EBuy/ywWnb3B+FFto5zWSsMqSOv5BSy32ZHNIhxIe Mf51DYq8+oI8okQWY66GlGdGCQ73e6y+mosHX9CQC3wPAS9qc5ZERZ8rNi/UZxEpaEL2jCx Sb3x7jg7mLgfO9VNySvUn9l232SjRFhcHEtbU6Bne91Xhjt50dSxdSSbtbfiMJOw0nG5xRe k0PXHCEXpjyTSqviO9q/NO1tvqE43f6hQW1SNcSk6u+9+l87SWjg6FhvzJPA== Received: from [10.66.228.43] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1utfFA-qt4ES6-7Q; Wed, 03 Sep 2025 04:37:12 +0000 Received: from [10.104.240.112] (helo=eldanna.ocaml.nl) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98.1-S2G) (envelope-from ) id 1utfF9-4o5NDgruvVT-govD; Wed, 03 Sep 2025 04:37:11 +0000 Date: Wed, 3 Sep 2025 07:37:09 +0300 From: Alexey Vyskubov To: "Dan Mahoney (Ports)" Cc: FreeBSD Current Subject: Re: pkg broken? Message-ID: Mail-Followup-To: "Dan Mahoney (Ports)" , FreeBSD Current References: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> X-Smtpcorp-Track: g3o7mhByyrRl.cfbQmxOea-zG.4LoUJwd-r00 Feedback-ID: 598416m:598416aWtJdUF:598416s_653MDEZw X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGqbC5ZZTz3stX On Tue, Sep 02, 2025 at 06:20:18PM -0700, Dan Mahoney (Ports) wrote: > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf -- pkg+:// implies SRV mirror type I do not use pkgbase. I've updated the system from the sources, and I got the same error. I've tried to rebuild pkg from the ports, but it did not help. -- Alexey I cannot receive HTML mail at this account. Hi, I am a signature virus. Add me to your signature to help me spread. From nobody Wed Sep 3 04:45:38 2025 X-Original-To: freebsd-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 4cGqmk0tQnz66P9G for ; Wed, 03 Sep 2025 04:45:42 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGqmj58tBz3wwJ; Wed, 03 Sep 2025 04:45:41 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756874741; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ynU31xIVaZhv8I7jW4rzduxPGASIYeZGMYBftGrf+pU=; b=UfdpTtVfbS0kZUgzMQomwbtTQxW67ThYriAze8COGfGdHpqrp6+4tX9UHvHrdaC//aPP// PhL9rjsGE2MJC8etyLoMf9SQ/GzEscmKoTJ/fFh8pYxHfs+4zsFmLkQX4BHY8HB2Ge61sS 4RutpmNQ698ZdzT2/patPM+9svUhVNwUB85HCF5yWXnaJWboy7nmkS470P0NimfnDTvGVQ ckINQ9n7/dS/rflSlKIfx9qn9gwk3axkQaJSZw3jdcUmVj1VrXIsERYNxMW7bZNM/UXoPX 8/QI+EBFFN5MDMgpyhYVmIIzSJ3W0+BEjLrSQRIzuGO1rFI2b/Jkpn5pefYj+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756874741; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ynU31xIVaZhv8I7jW4rzduxPGASIYeZGMYBftGrf+pU=; b=J7pL+4/RQvxmyqR4FsnRoMCNWOlvpEOR0yROrKEhr08E1kvweZVZ1YKRLdmWi/vDafOiZo IxrWeBpGFOh03I3T2lWa4tZ+jySjpfb0z5mOwhPvgsoGlvcaq6zkTZ6KX/Nw5zYiqTbaUF KqEHol4QqO1a05o5cFaUnVEOI0kZs+IbpxjNoZDuyaGm0rLOnKm2sTu+h72qZAW0zw3bEk 3MZJAs0UMxzeofdXURiY8DoukxV+Gsavydw6N83HfoKOXGo/C7jiSXyilfGE+plKlmVKsh yL02ZjaeMC5RgSamjs36lNv3fPe89m3P3spAeDCskzYIWQqXgGHgiT/rl6231g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756874741; a=rsa-sha256; cv=none; b=YK1XrP/pa/e/RX4nG5VSVw6xJolTAG+hNQYCqCkcTihUvBCFo5GhUmYPnSJFlJu3HsWJOu NmmsPT/Kp96WeYTKV7JWQQaschxpD2k/M8yQqQ8bRFBIxfSzEnLGOzYAMd3hX91lreSQeu wPxzCLK7ND8yaIK+gz65GGoHegHo+Ub335V+SIVnB8KdfIZE/3cdPhfZrIDpIkGhpmLmIG xpieF66SLod36GqHnwMzwJWlJyw+UszGIcpoODOBhpDZcbtXUVJX6nwlF6njUeUkg9+hEq 0XOQGX2ux2NAtQNxEJj3lRpv9nKWlJJKBB6/jA5PTQSF8evKZwVCkIwDQcK0Dw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cGqmj1ZLQzyd6; Wed, 03 Sep 2025 04:45:41 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 2 Sep 2025 21:45:38 -0700 From: Gleb Smirnoff To: Cy Schubert Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration Message-ID: References: <20250903043714.370F5311@slippy.cwsent.com> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250903043714.370F5311@slippy.cwsent.com> On Tue, Sep 02, 2025 at 09:37:14PM -0700, Cy Schubert wrote: C> I think the problem is with OpenSSL 3.5. With the legacy provider loaded in C> OpenSSL 3.5 I get, C> C> test3# openssl list -providers C> Providers: C> default C> name: OpenSSL Default Provider C> version: 3.5.1 C> status: active C> test3# C> C> Whereas in 3.0 I get, C> C> bob# openssl list -providers C> Providers: C> default C> name: OpenSSL Default Provider C> version: 3.0.16 C> status: active C> legacy C> name: OpenSSL Legacy Provider C> version: 3.0.16 C> status: active C> bob# C> C> Some symbol must be missing. The provider is no longer enabled by default in 3.5. You need couple more lines in /etc/ssl/openssl.cnf. This page has some examples: https://www.practicalnetworking.net/practical-tls/openssl-3-and-legacy-providers/ You also need CURRENT after b370fb00c89e9182f650943902a008f0c60883d6. -- Gleb Smirnoff From nobody Wed Sep 3 04:53:47 2025 X-Original-To: freebsd-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 4cGqy61Jmtz66Pb1 for ; Wed, 03 Sep 2025 04:53:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGqy56GDyz40KW; Wed, 03 Sep 2025 04:53:49 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id tRMZuwO1t9JM2tfVFuYwcj; Wed, 03 Sep 2025 04:53:49 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id tfVDuqjeRWbOatfVEuZAFQ; Wed, 03 Sep 2025 04:53:48 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=68b7c9dc a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=MzXxwKnEAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=HSaPlgtFgtBvVZ8QF3UA:9 a=CjuIK1q_8ugA:10 a=AVPT4aCM3DnWkd4gLgzP:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 4EBD61CE; Tue, 02 Sep 2025 21:53:47 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 444CF313; Tue, 02 Sep 2025 21:53:47 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Gleb Smirnoff cc: Cy Schubert , Rick Macklem , freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration In-reply-to: References: <20250903043714.370F5311@slippy.cwsent.com> Comments: In-reply-to Gleb Smirnoff message dated "Tue, 02 Sep 2025 21:45:38 -0700." 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: text/plain; charset=us-ascii Date: Tue, 02 Sep 2025 21:53:47 -0700 Message-Id: <20250903045347.444CF313@slippy.cwsent.com> X-CMAE-Envelope: MS4xfHc1lmSj0Nx0z6IIu5GV3rdgtFxWC/rlX+sLALOCRYzKB52QBXhVHxApLeneHvMhWPqT/G6xRrCpHu8oOri9cMm31/wU1IWRo96aDyRgDFnWDXPGAIoi X7xml/0iQMeYTuDFKUrWFTmDTsPLHflWnrvr7G0Ce36Y+6rvxJwR038NZntm9dDM6eg6zCkTrxmX7tc16R6qxu3F8asyza8kqtsW68cJS/r7RsTRGEc2FVJN vWFbpV52LTBo75/S4qjDWsl0yepNjdhLeqh2Y7GuwQw= X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGqy56GDyz40KW In message , Gleb Smirnoff writes: > On Tue, Sep 02, 2025 at 09:37:14PM -0700, Cy Schubert wrote: > C> I think the problem is with OpenSSL 3.5. With the legacy provider loaded i > n > C> OpenSSL 3.5 I get, > C> > C> test3# openssl list -providers > C> Providers: > C> default > C> name: OpenSSL Default Provider > C> version: 3.5.1 > C> status: active > C> test3# > C> > C> Whereas in 3.0 I get, > C> > C> bob# openssl list -providers > C> Providers: > C> default > C> name: OpenSSL Default Provider > C> version: 3.0.16 > C> status: active > C> legacy > C> name: OpenSSL Legacy Provider > C> version: 3.0.16 > C> status: active > C> bob# > C> > C> Some symbol must be missing. > > The provider is no longer enabled by default in 3.5. You need couple more > lines in /etc/ssl/openssl.cnf. This page has some examples: > > https://www.practicalnetworking.net/practical-tls/openssl-3-and-legacy-provid > ers/ Those lines are already in my openssl.cnf. ... [provider_sect] default = default_sect lagacy = legacy_sect ... [default_sect] # activate = 1 activate = 1 [legacy_sect] activate = 1 > > You also need CURRENT after b370fb00c89e9182f650943902a008f0c60883d6. I'm running CURRENT as of this morning. Works on the machine itself but not in the jail I'm testing in. Ok, there's something amiss with my jail. The server itself produces the correct output. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Wed Sep 3 05:10:06 2025 X-Original-To: freebsd-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 4cGrKG02Ymz66QsB for ; Wed, 03 Sep 2025 05:10:25 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGrKF4nTTz41x5; Wed, 03 Sep 2025 05:10:25 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-61cb9e039d9so12209573a12.1; Tue, 02 Sep 2025 22:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756876218; x=1757481018; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fuiPjpvtL8eUqrWd9CxGmbnBNjtJ3+5l/dbEm1gvEvE=; b=AV+GT5BNxx3aaGzTFqMDP+L+ZxLSVUgibLEHC4eF9xxM/9atEGGkUurYt99sHR0dp6 6n4zNbJCl681XscmsTbPtBxATf4ASUZ4mBzLiHti8+EuoClyM01QBfxXytBFC8x8U72q TjFDLmh8MpVoKznuHFRvSVQ0LKE5ZGlR6LaSmFL+yZT5XXLbL3tJWPSRfqlV6U0pOJaq 34g2De3b2U8VTCoj66L8Cg402ULcYbp0JRmCX2dX3sxKU1D7VPWSFogegngLzgk2A76W ClmWWlxjS8mn6CswJ+XqLIYS114mEdzw9xi+tebdeXc2o9+V4WIj7lGP3L6TjnpnlND+ d+1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756876218; x=1757481018; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fuiPjpvtL8eUqrWd9CxGmbnBNjtJ3+5l/dbEm1gvEvE=; b=De25Ri3yL59R6Y4IFDado/vas93FXk0Jrw4ZaRmmEzM7iolO+vGycTNTP5jY6/SRaO gYx0/C8nwpYce6pY5YUoWJcWpf8EnWK3RsLMJKPD74m7L3J+jpW4HZ6rbK/2Pxp6DS6t vJJG2zxkRB+EzRHgchyqZdmXWIL3XlB+ipCEg/YVFxt7FN0nkAB3LxgT0pYkrsnFGY7/ dZ21TklfUQsgAlnZnZIYU/Cu4jBLA8I/511UrnrQgEaj6nt+dgtaIPHU2U+6ZxDAyBzO B1U8eI2aZugbXSsNAHlDcDcn7fkumpvXzLlhEUaufq7gHn/0cKU6eqLW0bY3sR46ebw4 Twhg== X-Forwarded-Encrypted: i=1; AJvYcCWsFUEk0Ly0xHbRdD8uB0UPeVk2Bjqv7MCGuyJ7QhZm/qDu81xkGHPqAd8OtNrBvFXwt9PjowrKmLq9YXtHPvE=@freebsd.org X-Gm-Message-State: AOJu0YxZ8k37DG7l5hvZnzve71dN503VbfSn/OdE49qYQ6UrlSeHgy0H /GTRQrB2dJ+hLvdwtbNfVi1beFw+QzBbV/U1zFHgy8TUjpVpEX3ZUrpBlCO668wxZXJHV4J8QXR BkNRMu4RPtQNx62BWdZJmKKoVhi5qmA== X-Gm-Gg: ASbGncsc1NfpSpRuKwf0ut9e0Pp8KB2A2hsmomwmRSCNVCvYbK4dhH0cSExxYinm6rj AzM3WXbYGyauKOubkOjVYLHzIXF/9Cl60hOUCt7GGOKbIxppmBp8Y8T5ceud7ZClRkmDy5iPSXK Vqg3IE/FM1e16Ho57hUHnD6yz7s0SMuxDJVC4bqELMbF1ydL+JZDEAqmLTwEdztCMQevwzDDSvk 8bYucqAtng2CsI3rGfGF9hMB17inDqC78EkCtgEFbGEcpeR8A== X-Google-Smtp-Source: AGHT+IHsU+k6/uI3sOeWvQ4dlsnCgExUOQ4V6olpQA7rEcXeaYydpWwBFJyMWpRPesB/P5t/gYoHiyvZ7alXj23PGOk= X-Received: by 2002:a05:6402:5216:b0:61d:2405:b4a9 with SMTP id 4fb4d7f45d1cf-61d26d9143dmr11560724a12.17.1756876218111; Tue, 02 Sep 2025 22:10:18 -0700 (PDT) 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 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> <20250903043714.370F5311@slippy.cwsent.com> In-Reply-To: <20250903043714.370F5311@slippy.cwsent.com> From: Rick Macklem Date: Tue, 2 Sep 2025 22:10:06 -0700 X-Gm-Features: Ac12FXwRwS_a-XnEs0UxOTIMmb_kp7f57H5Szg-Gu6JU7eez6Q6u9RtQL8yGrWs Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Cy Schubert Cc: Gleb Smirnoff , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGrKF4nTTz41x5 On Tue, Sep 2, 2025 at 9:37=E2=80=AFPM Cy Schubert wrote: > > In message om> > , Rick Macklem writes: > > On Sun, Aug 31, 2025 at 5:58=3DE2=3D80=3DAFPM Rick Macklem > m> wrote: > > > > > > On Sun, Aug 31, 2025 at 5:41=3DE2=3D80=3DAFPM Rick Macklem > com> wrote: > > > > > > > > On Sat, Aug 30, 2025 at 9:47=3DE2=3D80=3DAFPM Rick Macklem > l.com> wrote: > > > > > > > > > > On Sat, Aug 30, 2025 at 4:22=3DE2=3D80=3DAFPM Rick Macklem > ail.com> wrote: > > > > > > > > > > > > On Sat, Aug 30, 2025 at 8:56=3DE2=3D80=3DAFAM Rick Macklem > gmail.com> wrote: > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=3DE2=3D80=3DAFPM Rick Macklem > m@gmail.com> wrote: > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=3DE2=3D80=3DAFAM Rick Macklem = > lem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=3DE2=3D80=3DAFPM Rick Mackle= m > cklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=3DE2=3D80=3DAFPM Rick Mack= lem > macklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=3DE2=3D80=3DAFAM Gleb Sm= irnoff > ebius@freebsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smir= noff=3D > > wrote: > > > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick M= ackl=3D > > em wrote: > > > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg= ins=3D > > tall heimdal", you get a > > > > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > > > > T> R> > > > > > > > > > > > > T> R> Now, I have another challenge. Fixing the mas= ter =3D > > passwords. > > > > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > > > > T> > > > > > > > > > > > > T> I have applied two commits from Heimdal from 201= 2 th=3D > > at add 'kadmin dump -f MIT' > > > > > > > > > > > > T> feature to our base heimdal and polished them to= com=3D > > pile. So far it doesn't > > > > > > > > > > > > T> work yet, either create an empty dump or create = a co=3D > > re dump, instead of > > > > > > > > > > > > T> database dump :) I'll see how difficult it is go= ing =3D > > to further resolve that to > > > > > > > > > > > > T> a working condition. If I succeed, then having '= dump=3D > > -f MIT' in base without > > > > > > > > > > > > T> any ports would be the best solution. Can also = be m=3D > > erged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my= cha=3D > > nge incorrectly - threw > > > > > > > > > > > > the new binary on a system running unpatched librar= ies.=3D > > When run correctly, > > > > > > > > > > > > it successfully produced something that looks like = a co=3D > > rrect dump in MIT format. > > > > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, th= ough=3D > > . > > > > > > Well, would you like the not so bad news or the bad news??;-) > > > > > > Your patch works, in that it produces a dump that "kdb5_util lo= ad > > > > > > -update" can load. > > > > > > After loading, if the principal only has keys for the newer enc= rypt=3D > > ion types of > > > > > > aes256-cts-hmac-sha1-96 > > > > > > aes128-cts-hmac-sha1-96 > > > > > > then you can look at the principal via kadmin.local, but the pa= sswo=3D > > rd must > > > > > > be changed before it works. > > > > > > --> This is the same behaviour as you get if you use Heimdal-7.= 8 to=3D > > do the > > > > > > dump conversion. > > > > > > So far, so good... > > > > > > > > > > > > Now, the not so good news. Once you update the Heimdal librarie= s > > > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the sys= tem > > > > > > running the old KDC. "kadmin -l dump" works, but something like= : > > > > > > # kadmin -l > > > > > > kadmin> get rmacklem > > > > > > kadmin: get rmacklem: Service key not available > > > > > > - I have not yet looked in your patched sources to see where th= is > > > > > > failure comes from? > > > > > > > > > > > > Now, more not so good news... > > > > > > My patch doesn't help. > > > > > > It does re-encrypt the key in the master key from the MIT KDC > > > > > > system, but that doesn't make the password work. > > > > > > When I compared the dump generated via kadmin with both > > > > > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > > > > > is 34bytes long. > > > > > > After doing the change_password so that it works, a dump > > > > > > generated by "kdb5_util dump -r13" (the same dump format) > > > > > > has a key that is 62bytes long. > > > > > > --> So, there is more to converting the key than just re-ecrypt= ing > > > > > > it. (I'll try and find where the MIT code encrypts a key = in a=3D > > master > > > > > > key to see why it ends up at 62bytes and whether that can= be =3D > > done > > > > > > in the old code.) > > > > > > > > > > > > So, if we are going to continue with this... > > > > > > - We need to figure out why your patch breaks "kadmin" for othe= r > > > > > > things and fix that. > > > > > > - I/we need to figure out how to convert the 34byte key to the = MIT > > > > > > 62byte key (and then maybe the password won't need to be chan= ged?=3D > > ). > > > > > > > > > > > > Or do we just say "When you convert the KDC database, all the p= assw=3D > > ords > > > > > > must be changed to get them to work?". > > > > > All I've got sofar is this patch... > > > > > https://people.freebsd.org/~rmacklem/print.patch > > > > > > > > > > It tweaks entry2mit_string_int() so that it skips over the keys f= or > > > > > old encryption types and fills in a fake "modified by" entry if n= one > > > > > exists. > > > > > > > > > > These changes at least make the MIT dump such that the records > > > > > don't end up "incomplete or corrupted" when you try to do somethi= ng > > > > > like "get_principal " in kadmin.local. > > > > > > > > > > As noted, your patch makes "kadmin -l" break for most things, > > > > > reporting "Service key not available". The failures go away if > > > > > you revert back to the non-patched libraries. > > > > > I have not located the problem yet. > > > > > > > > > > As for the passwords...no luck yet, rick > > > > Finally..it works. (First off, apologies for all the posts, just ig= nore > > > > them.;-) > > > > > > > > The patch is at: > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > I just updated the patch with a fix for the case where the > > Heimdal principal does not have any keys for string encryption. > > (That is fixed now and I haven't found any other bugs, so I > > think I am done playing with it. Yippee!!) > > > > Please test when you can find the time, rick > > I think the problem is with OpenSSL 3.5. With the legacy provider loaded = in > OpenSSL 3.5 I get, > > test3# openssl list -providers > Providers: > default > name: OpenSSL Default Provider > version: 3.5.1 > status: active > test3# > > Whereas in 3.0 I get, > > bob# openssl list -providers > Providers: > default > name: OpenSSL Default Provider > version: 3.0.16 > status: active > legacy > name: OpenSSL Legacy Provider > version: 3.0.16 > status: active > bob# > > Some symbol must be missing. Ok, I seem to have missed something here? Just in case it wasn't clear, I was referring to testing of the kadmin patches for the old Heimdal, so that the KDC database can be moved to an MIT KDC and still work. rick > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e**(i*pi)+1=3D0 > > From nobody Wed Sep 3 05:19:51 2025 X-Original-To: freebsd-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 4cGrXB0YTMz66RZl for ; Wed, 03 Sep 2025 05:19:54 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cGrX923J6z446x; Wed, 03 Sep 2025 05:19:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror); spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.33 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id tNRBuWRBO5MqytfuSux6wd; Wed, 03 Sep 2025 05:19:52 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id tfuRuqp6UWbOatfuSuZCH5; Wed, 03 Sep 2025 05:19:52 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=68b7cff8 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=zdPUvaFGAAAA:8 a=04oDvr9pAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=5H27IWoi4vgZ8F8KORwA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=fvD0gfNcX4AKPV7IvcuC:22 a=sT4bYkpex2i6d5iwGOJT:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 5C2CC22D; Tue, 02 Sep 2025 22:19:51 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 560A0215; Tue, 02 Sep 2025 22:19:51 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Cy Schubert , Gleb Smirnoff , freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration In-reply-to: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> <20250903043714.370F5311@slippy.cwsent.com> Comments: In-reply-to Rick Macklem message dated "Tue, 02 Sep 2025 22:10:06 -0700." 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: text/plain; charset=us-ascii Date: Tue, 02 Sep 2025 22:19:51 -0700 Message-Id: <20250903051951.560A0215@slippy.cwsent.com> X-CMAE-Envelope: MS4xfA4Oexq41eU9GfKTraSRVNbfbRn5YZ9EkEgrX0uVSRWle1u1aPxDu9hNqJmrB0EfbJ0ocq8NEUwd1MpEiIJixhYqNQtzKmmxquVlFnnZVd50Tc/kyId0 aWE3PAdMrlBLX8081UJJOpUbYOcgh5WTUV+TozMcCtHBrBFqbvzqEMA7rx7gtmhT/4eEWoOIP/jkEAGCDkAFNOw9+PHrHOHYXOCoY4/JOn50+Z8XBYi8yqfu W7BNi2B35vE58hOoxev7yl0tEZchyjzRCnPsIIaHJS4= X-Spamd-Bar: - X-Spamd-Result: default: False [-1.76 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.957]; MV_CASE(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.33:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31:c]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4cGrX923J6z446x In message , Rick Macklem writes: > On Tue, Sep 2, 2025 at 9:37=E2=80=AFPM Cy Schubert om> wrote: > > > > In message l.c > > om> > > , Rick Macklem writes: > > > On Sun, Aug 31, 2025 at 5:58=3DE2=3D80=3DAFPM Rick Macklem m@gmail.co=3D > > > m> wrote: > > > > > > > > On Sun, Aug 31, 2025 at 5:41=3DE2=3D80=3DAFPM Rick Macklem lem@gmail.=3D > > > com> wrote: > > > > > > > > > > On Sat, Aug 30, 2025 at 9:47=3DE2=3D80=3DAFPM Rick Macklem cklem@gmai=3D > > > l.com> wrote: > > > > > > > > > > > > On Sat, Aug 30, 2025 at 4:22=3DE2=3D80=3DAFPM Rick Macklem macklem@gm=3D > > > ail.com> wrote: > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 8:56=3DE2=3D80=3DAFAM Rick Macklem k.macklem@=3D > > > gmail.com> wrote: > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=3DE2=3D80=3DAFPM Rick Macklem ick.mackle=3D > > > m@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=3DE2=3D80=3DAFAM Rick Macklem = > > > lem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=3DE2=3D80=3DAFPM Rick Mackle= > m > > cklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=3DE2=3D80=3DAFPM Rick Mack= > lem > > macklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=3DE2=3D80=3DAFAM Gleb Sm= > irnoff > > ebius@freebsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smir= > noff=3D > > > wrote: > > > > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick M= > ackl=3D > > > em wrote: > > > > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg= > ins=3D > > > tall heimdal", you get a > > > > > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > > > > > T> R> > > > > > > > > > > > > > T> R> Now, I have another challenge. Fixing the mas= > ter =3D > > > passwords. > > > > > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > > > > > T> > > > > > > > > > > > > > T> I have applied two commits from Heimdal from 201= > 2 th=3D > > > at add 'kadmin dump -f MIT' > > > > > > > > > > > > > T> feature to our base heimdal and polished them to= > com=3D > > > pile. So far it doesn't > > > > > > > > > > > > > T> work yet, either create an empty dump or create = > a co=3D > > > re dump, instead of > > > > > > > > > > > > > T> database dump :) I'll see how difficult it is go= > ing =3D > > > to further resolve that to > > > > > > > > > > > > > T> a working condition. If I succeed, then having '= > dump=3D > > > -f MIT' in base without > > > > > > > > > > > > > T> any ports would be the best solution. Can also = > be m=3D > > > erged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my= > cha=3D > > > nge incorrectly - threw > > > > > > > > > > > > > the new binary on a system running unpatched librar= > ies.=3D > > > When run correctly, > > > > > > > > > > > > > it successfully produced something that looks like = > a co=3D > > > rrect dump in MIT format. > > > > > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, th= > ough=3D > > > . > > > > > > > Well, would you like the not so bad news or the bad news??;-) > > > > > > > Your patch works, in that it produces a dump that "kdb5_util lo= > ad > > > > > > > -update" can load. > > > > > > > After loading, if the principal only has keys for the newer enc= > rypt=3D > > > ion types of > > > > > > > aes256-cts-hmac-sha1-96 > > > > > > > aes128-cts-hmac-sha1-96 > > > > > > > then you can look at the principal via kadmin.local, but the pa= > sswo=3D > > > rd must > > > > > > > be changed before it works. > > > > > > > --> This is the same behaviour as you get if you use Heimdal-7.= > 8 to=3D > > > do the > > > > > > > dump conversion. > > > > > > > So far, so good... > > > > > > > > > > > > > > Now, the not so good news. Once you update the Heimdal librarie= > s > > > > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the sys= > tem > > > > > > > running the old KDC. "kadmin -l dump" works, but something like= > : > > > > > > > # kadmin -l > > > > > > > kadmin> get rmacklem > > > > > > > kadmin: get rmacklem: Service key not available > > > > > > > - I have not yet looked in your patched sources to see where th= > is > > > > > > > failure comes from? > > > > > > > > > > > > > > Now, more not so good news... > > > > > > > My patch doesn't help. > > > > > > > It does re-encrypt the key in the master key from the MIT KDC > > > > > > > system, but that doesn't make the password work. > > > > > > > When I compared the dump generated via kadmin with both > > > > > > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > > > > > > is 34bytes long. > > > > > > > After doing the change_password so that it works, a dump > > > > > > > generated by "kdb5_util dump -r13" (the same dump format) > > > > > > > has a key that is 62bytes long. > > > > > > > --> So, there is more to converting the key than just re-ecrypt= > ing > > > > > > > it. (I'll try and find where the MIT code encrypts a key = > in a=3D > > > master > > > > > > > key to see why it ends up at 62bytes and whether that can= > be =3D > > > done > > > > > > > in the old code.) > > > > > > > > > > > > > > So, if we are going to continue with this... > > > > > > > - We need to figure out why your patch breaks "kadmin" for othe= > r > > > > > > > things and fix that. > > > > > > > - I/we need to figure out how to convert the 34byte key to the = > MIT > > > > > > > 62byte key (and then maybe the password won't need to be chan= > ged?=3D > > > ). > > > > > > > > > > > > > > Or do we just say "When you convert the KDC database, all the p= > assw=3D > > > ords > > > > > > > must be changed to get them to work?". > > > > > > All I've got sofar is this patch... > > > > > > https://people.freebsd.org/~rmacklem/print.patch > > > > > > > > > > > > It tweaks entry2mit_string_int() so that it skips over the keys f= > or > > > > > > old encryption types and fills in a fake "modified by" entry if n= > one > > > > > > exists. > > > > > > > > > > > > These changes at least make the MIT dump such that the records > > > > > > don't end up "incomplete or corrupted" when you try to do somethi= > ng > > > > > > like "get_principal " in kadmin.local. > > > > > > > > > > > > As noted, your patch makes "kadmin -l" break for most things, > > > > > > reporting "Service key not available". The failures go away if > > > > > > you revert back to the non-patched libraries. > > > > > > I have not located the problem yet. > > > > > > > > > > > > As for the passwords...no luck yet, rick > > > > > Finally..it works. (First off, apologies for all the posts, just ig= > nore > > > > > them.;-) > > > > > > > > > > The patch is at: > > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > I just updated the patch with a fix for the case where the > > > Heimdal principal does not have any keys for string encryption. > > > (That is fixed now and I haven't found any other bugs, so I > > > think I am done playing with it. Yippee!!) > > > > > > Please test when you can find the time, rick > > > > I think the problem is with OpenSSL 3.5. With the legacy provider loaded = > in > > OpenSSL 3.5 I get, > > > > test3# openssl list -providers > > Providers: > > default > > name: OpenSSL Default Provider > > version: 3.5.1 > > status: active > > test3# > > > > Whereas in 3.0 I get, > > > > bob# openssl list -providers > > Providers: > > default > > name: OpenSSL Default Provider > > version: 3.0.16 > > status: active > > legacy > > name: OpenSSL Legacy Provider > > version: 3.0.16 > > status: active > > bob# > > > > Some symbol must be missing. > Ok, I seem to have missed something here? > Just in case it wasn't clear, I was referring to testing of the > kadmin patches for the old Heimdal, so that the KDC database > can be moved to an MIT KDC and still work. I'm back at the keyboard and catching up. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Wed Sep 3 05:43:56 2025 X-Original-To: freebsd-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 4cGs4015cwz66TXT for ; Wed, 03 Sep 2025 05:44:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4cGs3z64hNz46bM for ; Wed, 03 Sep 2025 05:43:59 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview4.colo2.realworks.nl [10.2.52.34]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4cGs3x3mGdzDC; Wed, 3 Sep 2025 07:43:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1756878237; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=/kZYxTM1xrl+LUCVeM9FEZBYW8+AFTQm9z8EXej/vqc=; b=KoiB86YzbQlIGTzfzm18aEl2zhzur7DQMeqt96ol4CoulRAKlsHCElkFRus7e7JXWCQo+O xsD1vUjdhnZ8fEbCE20D7IZXBPk4zEfbjv7Y8TK6o0Q0tIBHyTutFgO4ruCooa7j6MmjEw 1IrMwGTs6MnTjNEY00TxeIo2HAnzR2gBfh1jyTUooauYjnNAxZ0GCE7oV/rePzadrt6zTR wqf7WxVmLP3HhHxTz1urm9VJBVmKsdw1OFUOIrv6Fyar+BM3wZul5VKtc9YWklFD3Bblrh hDtuJ6rrGx/yDyIt23hxLNUJKPYKfQUAW7lb6Oc4tkTw3NluTYnn5RBoDtaQCg== Received: from crmpreview4.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview4.colo2.realworks.nl (Postfix) with ESMTP id 283FD1C032C; Wed, 3 Sep 2025 07:43:56 +0200 (CEST) Date: Wed, 3 Sep 2025 07:43:56 +0200 (CEST) From: Ronald Klop To: "Dan Mahoney (Ports)" Cc: FreeBSD Current Message-ID: <1236876296.673.1756878236940@localhost> In-Reply-To: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> Subject: Re: pkg broken? 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/alternative; boundary="----=_Part_672_343193303.1756878236937" X-Mailer: Realworks (763.79) X-Originating-Host: from (localhost [127.0.0.1]) by crmpreview4.colo2.realworks.nl [10.2.52.34] with HTTP; Wed, 03 Sep 2025 07:43:56 +0200 Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGs3z64hNz46bM ------=_Part_672_343193303.1756878236937 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Do you have a config in /usr/local/etc/pkg/repos/ ? If yes, did that follow the changes for freeebsd-ports and -ports-kmod? Regards, Ronald.=20 Van: "Dan Mahoney (Ports)" Datum: 3 september 2025 03:21 Aan: FreeBSD Current Onderwerp: pkg broken? >=20 >=20 > Hey all, >=20 > After an update today to what looks like snap20250828153719.pkg, it would= seem pkg doesn=E2=80=99t want to play ball. >=20 > root@poudriere-pkb:/etc/pkg # pkg update > Updating FreeBSD-ports repository catalogue... > FreeBSD-ports repository is up to date. > Updating FreeBSD-ports-kmods repository catalogue... > FreeBSD-ports-kmods repository is up to date. > Updating FreeBSD-base repository catalogue... > FreeBSD-base repository is up to date. > Updating FreeBSD repository catalogue... > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd6= 4/latest/meta.conf -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd6= 4/latest/meta.txz -- pkg+:// implies SRV mirror type > repository FreeBSD has no meta file, using default settings > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd6= 4/latest/data.pkg -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd6= 4/latest/data.tzst -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd6= 4/latest/packagesite.pkg -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd6= 4/latest/packagesite.tzst -- pkg+:// implies SRV mirror type > Unable to update repository FreeBSD > Error updating repositories! > root@poudriere-pkb:/etc/pkg # uname -a > FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE mai= n-n280004-00c9ebbbc653 GENERIC amd64 > root@poudriere-pkb:/etc/pkg # freebsd-version > 15.0-PRERELEASE >=20 > Running bootstrap doesn=E2=80=99t seem to help: >=20 > root@poudriere-pkb:/etc/pkg # /usr/sbin/pkg bootstrap -f > The package management tool is not yet installed on your system. > Do you want to fetch and install it now? [y/N]: y > Bootstrapping pkg from pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/lates= t, please wait... > Verifying signature with trusted certificate pkg.freebsd.org.2013102301..= . done > Installing pkg-2.2.2... > package pkg is already installed, forced install > Extracting pkg-2.2.2: 100% >=20 > My /etc/pkg/FreeBSD.conf was replaced by a repo that changed FreeBSD-kmod= s to FreeBSD-ports-kmods but is almost otherwise identical. My pkgbase rep= o seems to be behaving, but=E2=80=A6.I think pkg stops on any failures. >=20 > Ideas? >=20 > -Dan >=20 >=20 >=20 >=20 ------=_Part_672_343193303.1756878236937 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Do you have a config in /usr/local/etc/pkg/repos/ = ?
If yes, did that follow the changes for freeebsd-ports and -ports-kmo= d?

Regards,
Ronald. 

Van: "Dan Mahoney (Ports)" <freebsd@= gushi.org>
Datum: 3 september 2025 03:21
= Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: pkg broken?

Hey all,

After an update today to what looks like snap20250828153719.pkg, it would s= eem pkg doesn=E2=80=99t want to play ball.

root@poudriere-pkb:/etc/pkg # pkg update
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
Updating FreeBSD repository catalogue...
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest= /meta.conf -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/= meta.txz -- pkg+:// implies SRV mirror type
repository FreeBSD has no meta file, using default settings
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/= data.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest= /data.tzst -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/= latest/packagesite.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64= /latest/packagesite.tzst -- pkg+:// implies SRV mirror type
Unable to update repository FreeBSD
Error updating repositories!
root@poudriere-pkb:/etc/pkg # uname -a
FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE main-= n280004-00c9ebbbc653 GENERIC amd64
root@poudriere-pkb:/etc/pkg # freebsd-version
15.0-PRERELEASE

Running bootstrap doesn=E2=80=99t seem to help:

root@poudriere-pkb:/etc/pkg # /usr/sbin/pkg bootstrap -f
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest, please wai= t...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... = done
Installing pkg-2.2.2...
package pkg is already installed, forced install
Extracting pkg-2.2.2: 100%

My /etc/pkg/FreeBSD.conf was replaced by a repo that changed FreeBSD-kmods = to FreeBSD-ports-kmods but is almost otherwise identical.  My pkgbase = repo seems to be behaving, but=E2=80=A6.I think pkg stops on any failures.<= br>
Ideas?

-Dan



------=_Part_672_343193303.1756878236937-- From nobody Wed Sep 3 09:28:34 2025 X-Original-To: freebsd-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 4cGy3L0zwzz65njJ for ; Wed, 03 Sep 2025 09:28:46 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4cGy3K38Sjz3FP3 for ; Wed, 03 Sep 2025 09:28:45 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5839SZIZ059331; Wed, 3 Sep 2025 18:28:37 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756891719; bh=2TFVV5HlxRsQ6c2yrUMbg1kguLKlrrj33ayWQaPIAFk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=SbYQF/Zhy5KCPoGFkxp0SWi0+dI4kHvK5r2vuPM+azTMrHq8BRO4uoP+snOL6E81c IUsv4nvKx66vW9W5NDEc/pFU1Ffdd5V750FXlmeR9UA6TsviOHyqNeRDeUT8N29NIm IkGbha/gLTno8flRGH2fYO4JBp2qiL/v4Z3lV3vQ= Date: Wed, 3 Sep 2025 18:28:34 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Poul-Henning Kamp , Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250903182834.a3c266576fd844dfadcda9a7@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> <202509010904.58194iP2007318@critter.freebsd.dk> <20250901204243.6548150b14d79d2eab04ad3d@dec.sakura.ne.jp> <20250902225500.70577e08c0584754e743bac9@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGy3K38Sjz3FP3 On Tue, 2 Sep 2025 13:25:59 -0600 Warner Losh wrote: > On Tue, Sep 2, 2025 at 7:55 AM Tomoaki AOKI > wrote: > > > On Mon, 1 Sep 2025 21:02:45 -0600 > > Warner Losh wrote: > > > > > On Mon, Sep 1, 2025 at 5:42 AM Tomoaki AOKI > > > wrote: > > > > > > > On Mon, 1 Sep 2025 03:15:50 -0600 > > > > Warner Losh wrote: > > > > > > > > > On Mon, Sep 1, 2025, 3:05 AM Poul-Henning Kamp > > > > wrote: > > > > > > > > > > > -------- > > > > > > Tomoaki AOKI writes: > > > > > > > > > > > > > > > > > > > > > … it would be nice to have something like 'recovery > > partition', > > > > as > > > > > > > > some OSes have. or at least some tiny fail-safe feature. having > > > > remote > > > > > > > > machine in some distant datacenter, booting from a flashstick > > is > > > > > > always > > > > > > > > a problem. > > > > > > > > > > > > I thought that is what /rescue is for ? > > > > > > > > > > > > > > > > That only works if your boot loader can read it... I've thought for a > > > > > while now that maybe we should move that into a ram disk image that > > we > > > > fall > > > > > back to if the boot loader can't read anything else... > > > > > > > > > > Warner > > > > > > > > Exactly. If the loader (or bootcode to kick the loader in the > > > > partition/pool) can sanely read the partition/pool to boot from, > > > > I think /rescue is enough and no need for rescue "partition / pool". > > > > > > > > But once the partition / pool to boot is broken (including lost > > > > decryption key for encrypted partitions/drives from regular place), > > > > something others are needed. > > > > > > > > And what can be chosen to boot from BIOS/UEFI firmware depends on > > > > the implementation (some could restrict per-drive only, instead of > > > > every entry in EFI boot manager table). > > > > > > > > If BIOS/firmware allow to choose "drive" to boot, rescue "drive" > > > > is useful, if multiple physical drives are available. > > > > > > > > Yes, rescue mfsroot embedded into loader.efi would be a candidate, too, > > > > if the size of ESP allows. > > > > > > > > > Rescue is quite small. On the order of 8MB compressed. The trouble is > > that > > > the kernel is like 12MB compressed, plus we'd need a few more modules. > > > Still, we could likely get something under 25MB that's an MD image that > > we > > > could boot into, but it would have to be single user. And It's been a > > while > > > since I did that... Typically I just run /rescue/init or /rescue/sh, > > which > > > isn't a full system and still uses the system's /etc. If we customized it > > > per system, we could do better, since the kernel can be a bit smaller > > > (compressed our kernels at work are 6MB), so under 20MB could be > > possible. > > > We'd not need /boot/loader.efi in there. > > > > Oh, much smaller than I've expected! > > > > Actually, using boot1.efi (either stock or patched), users of Root on > > ZFS can have rescue UFS partition on the same drive. > > This is because it looks for /boot/loader.efi to kick from ZFS pool > > first, then, UFS. This is per-drive priority and if both are NOT found, > > boot1.efi looks for another drive with the order that UEFI firmware > > recognized. (The first to try is the drive boot1.efi itself was kicked.) > > > > This is how smh@ implemented when I requested to fix boot issue > > on UEFI boot (at the moment, loader.efi cannot be kicked directly > > by UEFI firmware and needed boot1.efi). > > > > This isn't true, at least not generally. We load loader.efi in all new > installations by default. I've fixed a number of issues around this from > the past... We're not able to use it at netflix to boot off of ZFS, for > example... This is why I believe you're the best person to ask about loader. ;-) > > Maybe Warner would remember, before the fix, boot1.efi always looked for > > /boot/loader.efi with the order UEFI firmware recognized drives, > > thus, even if started from USB memstick for rescue, boot1.efi > > "always" kicked the first "internal" drive and cannot rescue. > > Yes, fresh installations was OK with it, as there's no /boot/loader.efi > > in any of internal drives. > > > > Yea, I'm not remembering it... It was late Jan., 2016. https://lists.freebsd.org/pipermail/freebsd-current/2016-January/059387.html > > > If we could hook into the arch specific traps that cause segv, etc, we > > > could do a setjmp early and set 'safe mode' and restart. Though that may > > > be trickier than I initially am thinking... maybe the best bet is to let > > > uefi catch that failure and have the next bootable BootXXXX environment > > on > > > the list specify a safe mode. More investigation might be needed. > > > > > > Warner > > > > Yeah, and it could be (and would actually be) implementation-specific. > > Maybe chaotic in real world and lots of quirks would be required. > > > > I don't understand that part... It would be architecture specific, but why > would it be implementation specific? > > Warner Even for mandatory features, some implementations that mis-understanding the spec can be implementation-specific, especially in early phase of the standard, unfortunately. Do you remember early PCI (not PCIe!) incompatibility issues? And early USB, too, IIRC. -- Tomoaki AOKI From nobody Wed Sep 3 09:30:16 2025 X-Original-To: freebsd-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 4cGy594n1qz65pBF for ; Wed, 03 Sep 2025 09:30:21 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4cGy591wSRz3GTV for ; Wed, 03 Sep 2025 09:30:21 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5839UGeB059675; Wed, 3 Sep 2025 18:30:17 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756891817; bh=nGoZMXHK2u23vARqKuATXjlsPcT5rpWC5qQ9hVzd16c=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ofm2jZAoyovteZmRwijsk8DVwIpeZjFnQ0ShDbya0aSFOV3IQjlXd3IDLmNmosMxq Tm8i2OfeyI6lXImGDfCRE06U77tfXTzF1/BVo4bMG/1R2B2NGkWHhzNLmRrKxelENN 5SwdM7akenKcoaE0Mz2AjM4yjNJPEStwQty9T/mY= Date: Wed, 3 Sep 2025 18:30:16 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250903183016.a608f97e10208e904a11a4ba@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <98890564-ad8f-411a-9c00-45326a9d6ff5@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cGy591wSRz3GTV On Tue, 2 Sep 2025 13:26:53 -0600 Warner Losh wrote: > On Tue, Sep 2, 2025 at 12:53 PM Graham Perrin > wrote: > > > On 01/09/2025 02:58, Graham Perrin wrote: > > > An enhancement to bsdinstall could, before creation of the partition > > > table, allow the user to specify an amount of space to be left free at > > > the end of a device … > > > > > > For now, short term, is the (simple) free space idea attractive? > > > > Longer term: I'm not averse to more complex enhancements around e.g. > > /rescue/, however I _do_ like the idea of free space. > > > > Freedom for the user to do whatever they want. They might, or might not, > > want to use the space for the content of > > FreeBSD-15.0-RELEASE-amd64-memstick.img … and so on. Maybe this overlaps > > with ZFS-specific bsdinstall report > > . > > > > Things are small enough, I'd rather just create it in the ESP directly. > Special reserved space on disks are nothing but a pain. > > Warner What I imagine with this specific use-case (example): 1. Create 250MB ESP as, i.e., nda0p1 2. Create freebsd-zfs for all remained amount after 3., as nda0p2 3. Create 64GB freebsd-swap as nda0-3 at the end of the drive In this case, I need to calculate the (aligned) size of 2. manually, which is a bit pain. Something like gpart add -a 1M -t freebsd-zfs -l zfsNVMe001 -i 2 -s fill nda0 then create -i 3 and later, and finally gpart commit actually create second and later partitions would be helpful. -- Tomoaki AOKI From nobody Wed Sep 3 15:28:20 2025 X-Original-To: freebsd-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 4cH62c5Yrrz66c0G for ; Wed, 03 Sep 2025 15:28:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cH62c07BDz3vXX; Wed, 03 Sep 2025 15:28:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=D2D2wAtA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61edf1686ffso991960a12.0; Wed, 03 Sep 2025 08:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756913313; x=1757518113; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uketxR9MtJnTCDPW+UNcXi6AE3WSIwPZTW/h7nPPl80=; b=D2D2wAtAdID5EFIZEnVLsrnL0lL1rP1hGaUiuOXHEO9m+TdnSqh+1Kw6wL6nhLFoK8 HxRluXXNXiFhQRjB4xt8nSYcMBKJkjV4iyOvhiUurwnU5UMUbcQO4GuRqWZOG3Zr5xRa j8gR5Bg5/d5X5njx6NzIVT2FaiOKg8/LQzSgnPw52Qu68jzh01L2km+6F0T9ujAw9Q63 tUw6n5ZkycWfK7pxl7X18BJH8nqfvFszWfSL8av2Yu9Dh4SVm3fi7MkluShbtfrvMCma Stk7H4xhCt2E0kKeXQExIV2a0RPk066c8LLsq7NmTnOLsWOeyIaEKUjfXCqgPlrddkgD IsXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756913313; x=1757518113; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uketxR9MtJnTCDPW+UNcXi6AE3WSIwPZTW/h7nPPl80=; b=f2uLSMD0eEalU21nWnMULY7v2aAX+LyHkV4ou87oAlc4dblYqfIO0azDQwB5vZi9ex 92h15daXoZ/tpaMI5v3dZbi7RZsjRON4FCncQpiK+2AiZ4eIWvhqeNwAYdB7vqjiLHaV 2Ns9MyKZFEtTJnOpUEQ/2J3s4hPgTycsc86X8DoYiY4Mf/vYksdmPqfMhsw+XBCZOCsi dVhQffP1Vo/vMfVeZGR8ZifJNWqcnLxfKP59+6jKYv/t3Be1+0vCnUPauHqCBVZWIH2b RHmw34Fd/FxVBNMmp3GYbDCrWVoC0wp5j2YlYt9B+mwzwAVOhQtWHmgYB52FxUnJgQ0f cKng== X-Forwarded-Encrypted: i=1; AJvYcCXeQJlC4srrxXHiu8EO4ROwhMOgFhGzyLV48IZbOzZxBndOllLQYdp9Dy8K/1ru8AMs83vin2xf1Vps0rYf2k4=@freebsd.org X-Gm-Message-State: AOJu0YxrTjikR0AO4VOUcjc1AmxcEUVEsUOU7Bowq8eeNzDUejgqOSLo ntu/RBUXII2yu5s8F+gPTHLSiNrTuG1P9k/P0d5r/mPoIXSP2eVgUs6btwVC0pA/R0IjnNWboUu MD7weJqDazrMVEdqpAiMbzfMCd9nQmj0SElg= X-Gm-Gg: ASbGncuTpxg3d+KKQ7F58AsKpMZntbb7+JEXtCg7b+x2Bz639LUkRE7/6WbW6VDe0hV TwpGRY5UE3OBJ2aTZrUegPLwArJayay3bQl3sRj6ERJdwkBn21I3UdJdctUSnzwxGCzll+KUsOM w/TdUTddOq2u/gJzmchXz6tqX5RuQe1vpeOtwdgxjh6MQGJV/Pi/74g150CYFutgd6BuMYGGol4 4DfjD7Y+p03dcD6d1LTdt1eBsjVHrjX2T7e9kQ= X-Google-Smtp-Source: AGHT+IGdWZqtZH/p8pwWhmiTmHM5K1TJW4a46YbOaVuwJAjzKrhXJ/l0MOy1eKy9HCJIc+96dcjdpzw/YT24zT+G8jw= X-Received: by 2002:a05:6402:50c7:b0:61e:acff:8e20 with SMTP id 4fb4d7f45d1cf-61eacff9df1mr8993670a12.6.1756913312568; Wed, 03 Sep 2025 08:28:32 -0700 (PDT) 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 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> <20250903043714.370F5311@slippy.cwsent.com> In-Reply-To: From: Rick Macklem Date: Wed, 3 Sep 2025 08:28:20 -0700 X-Gm-Features: Ac12FXyavvwhK_vJxW84ugnkeJsEK4zQrz9W1AxFYu2kT-18eIw7lf-jR4Fh0y4 Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Cy Schubert Cc: Gleb Smirnoff , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.07 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.07)[-0.071]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4cH62c07BDz3vXX On Tue, Sep 2, 2025 at 10:10=E2=80=AFPM Rick Macklem wrote: > > On Tue, Sep 2, 2025 at 9:37=E2=80=AFPM Cy Schubert wrote: > > > > In message > om> > > , Rick Macklem writes: > > > On Sun, Aug 31, 2025 at 5:58=3DE2=3D80=3DAFPM Rick Macklem > > m> wrote: > > > > > > > > On Sun, Aug 31, 2025 at 5:41=3DE2=3D80=3DAFPM Rick Macklem > > com> wrote: > > > > > > > > > > On Sat, Aug 30, 2025 at 9:47=3DE2=3D80=3DAFPM Rick Macklem > > l.com> wrote: > > > > > > > > > > > > On Sat, Aug 30, 2025 at 4:22=3DE2=3D80=3DAFPM Rick Macklem > > ail.com> wrote: > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 8:56=3DE2=3D80=3DAFAM Rick Macklem > > gmail.com> wrote: > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=3DE2=3D80=3DAFPM Rick Macklem = > > m@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=3DE2=3D80=3DAFAM Rick Mackle= m > > lem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=3DE2=3D80=3DAFPM Rick Mack= lem > > cklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=3DE2=3D80=3DAFPM Rick Ma= cklem > > macklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=3DE2=3D80=3DAFAM Gleb = Smirnoff > > ebius@freebsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Sm= irnoff=3D > > > wrote: > > > > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick= Mackl=3D > > > em wrote: > > > > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "p= kg ins=3D > > > tall heimdal", you get a > > > > > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > > > > > T> R> > > > > > > > > > > > > > T> R> Now, I have another challenge. Fixing the m= aster =3D > > > passwords. > > > > > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > > > > > T> > > > > > > > > > > > > > T> I have applied two commits from Heimdal from 2= 012 th=3D > > > at add 'kadmin dump -f MIT' > > > > > > > > > > > > > T> feature to our base heimdal and polished them = to com=3D > > > pile. So far it doesn't > > > > > > > > > > > > > T> work yet, either create an empty dump or creat= e a co=3D > > > re dump, instead of > > > > > > > > > > > > > T> database dump :) I'll see how difficult it is = going =3D > > > to further resolve that to > > > > > > > > > > > > > T> a working condition. If I succeed, then having= 'dump=3D > > > -f MIT' in base without > > > > > > > > > > > > > T> any ports would be the best solution. Can als= o be m=3D > > > erged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing = my cha=3D > > > nge incorrectly - threw > > > > > > > > > > > > > the new binary on a system running unpatched libr= aries.=3D > > > When run correctly, > > > > > > > > > > > > > it successfully produced something that looks lik= e a co=3D > > > rrect dump in MIT format. > > > > > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, = though=3D > > > . > > > > > > > Well, would you like the not so bad news or the bad news??;-) > > > > > > > Your patch works, in that it produces a dump that "kdb5_util = load > > > > > > > -update" can load. > > > > > > > After loading, if the principal only has keys for the newer e= ncrypt=3D > > > ion types of > > > > > > > aes256-cts-hmac-sha1-96 > > > > > > > aes128-cts-hmac-sha1-96 > > > > > > > then you can look at the principal via kadmin.local, but the = passwo=3D > > > rd must > > > > > > > be changed before it works. > > > > > > > --> This is the same behaviour as you get if you use Heimdal-= 7.8 to=3D > > > do the > > > > > > > dump conversion. > > > > > > > So far, so good... > > > > > > > > > > > > > > Now, the not so good news. Once you update the Heimdal librar= ies > > > > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the s= ystem > > > > > > > running the old KDC. "kadmin -l dump" works, but something li= ke: > > > > > > > # kadmin -l > > > > > > > kadmin> get rmacklem > > > > > > > kadmin: get rmacklem: Service key not available > > > > > > > - I have not yet looked in your patched sources to see where = this > > > > > > > failure comes from? > > > > > > > > > > > > > > Now, more not so good news... > > > > > > > My patch doesn't help. > > > > > > > It does re-encrypt the key in the master key from the MIT KDC > > > > > > > system, but that doesn't make the password work. > > > > > > > When I compared the dump generated via kadmin with both > > > > > > > your patch and mine, the key for aes256-cts-hmac-sha1-96 > > > > > > > is 34bytes long. > > > > > > > After doing the change_password so that it works, a dump > > > > > > > generated by "kdb5_util dump -r13" (the same dump format) > > > > > > > has a key that is 62bytes long. > > > > > > > --> So, there is more to converting the key than just re-ecry= pting > > > > > > > it. (I'll try and find where the MIT code encrypts a ke= y in a=3D > > > master > > > > > > > key to see why it ends up at 62bytes and whether that c= an be =3D > > > done > > > > > > > in the old code.) > > > > > > > > > > > > > > So, if we are going to continue with this... > > > > > > > - We need to figure out why your patch breaks "kadmin" for ot= her > > > > > > > things and fix that. > > > > > > > - I/we need to figure out how to convert the 34byte key to th= e MIT > > > > > > > 62byte key (and then maybe the password won't need to be ch= anged?=3D > > > ). > > > > > > > > > > > > > > Or do we just say "When you convert the KDC database, all the= passw=3D > > > ords > > > > > > > must be changed to get them to work?". > > > > > > All I've got sofar is this patch... > > > > > > https://people.freebsd.org/~rmacklem/print.patch > > > > > > > > > > > > It tweaks entry2mit_string_int() so that it skips over the keys= for > > > > > > old encryption types and fills in a fake "modified by" entry if= none > > > > > > exists. > > > > > > > > > > > > These changes at least make the MIT dump such that the records > > > > > > don't end up "incomplete or corrupted" when you try to do somet= hing > > > > > > like "get_principal " in kadmin.local. > > > > > > > > > > > > As noted, your patch makes "kadmin -l" break for most things, > > > > > > reporting "Service key not available". The failures go away if > > > > > > you revert back to the non-patched libraries. > > > > > > I have not located the problem yet. > > > > > > > > > > > > As for the passwords...no luck yet, rick > > > > > Finally..it works. (First off, apologies for all the posts, just = ignore > > > > > them.;-) > > > > > > > > > > The patch is at: > > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > I just updated the patch with a fix for the case where the > > > Heimdal principal does not have any keys for string encryption. > > > (That is fixed now and I haven't found any other bugs, so I > > > think I am done playing with it. Yippee!!) > > > > > > Please test when you can find the time, rick Outstanding issue/question w.r.t. converting the KDC database from Heimdal 1.5.2->MIT. Right now, the patch I have drops the weak encryption type keys (des3.. and arcfour..). If the principal in the Heimdal KDC does not have keys for either of: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 the patch generates a "fake" one. As a result, a change_password for the principal is needed for this case. The alternative to doing this would be an option that converts the weak keys, but... - The MIT KDC will find the principal "incomplete or corrupted" for at least the "out-of-the-box" configuration. - It might accept them if "accept_weak_ecntypes" is set in the kdc.conf. This leads to a couple of questions: - Does anyone know if MIT 1.22 still allows "accept_weak_enctypes? If it does not allow them, I don't think there is much use for this option? Given the release schedule, it would be nice to get this resolved soon. Also, someone needs to document this. The Handbook section does a nice job of explaining the setup of a Heimdal KDC, but has nothing w.r.t. setting up an MIT KDC nor converting the KDC database over to it. rick > > > > I think the problem is with OpenSSL 3.5. With the legacy provider loade= d in > > OpenSSL 3.5 I get, > > > > test3# openssl list -providers > > Providers: > > default > > name: OpenSSL Default Provider > > version: 3.5.1 > > status: active > > test3# > > > > Whereas in 3.0 I get, > > > > bob# openssl list -providers > > Providers: > > default > > name: OpenSSL Default Provider > > version: 3.0.16 > > status: active > > legacy > > name: OpenSSL Legacy Provider > > version: 3.0.16 > > status: active > > bob# > > > > Some symbol must be missing. > Ok, I seem to have missed something here? > Just in case it wasn't clear, I was referring to testing of the > kadmin patches for the old Heimdal, so that the KDC database > can be moved to an MIT KDC and still work. > > rick > > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e**(i*pi)+1=3D0 > > > > From nobody Wed Sep 3 18:03:53 2025 X-Original-To: freebsd-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 4cH9V337c3z66pcN for ; Wed, 03 Sep 2025 18:04:11 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cH9V26Lnnz3JFm for ; Wed, 03 Sep 2025 18:04:10 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=ultimatedns.net header.s=mx99 header.b="s+Q9Wm/m"; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 583I3r1M028888; Wed, 3 Sep 2025 11:03:59 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1756922640; x=1756923240; r=y; bh=t3lMpyqoP2E8qECw2A9SSjxfgiXJsYICVJWASeeQ9to=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=s+Q9Wm/m71SrJU8IBnse06E/znQrKA9JRKFwu9aTuVTB4rjEyAJvNc9hY4kSXqayx civfb6syQCXm0DIqH1b06ze/g51kiarPa+DKrUL3XmpnMPCzNFyTsgU/8ocLDarKqB 5o0wkt4v7fxePxLtzu1kDpy4YtO1Eu+qqxOyu0+u2VLBXCRMPogj4252cw6YqSWRVI 9UxZF7LI0JwJn75B8G0C2Xjw5fTf7UgI9gqFqmmnNdhyuLh86DHB6GnxrJ2CnpCt5J 1cyXezBILSGsO342EqwKZ8lovOayes6Iir3QU6w7qltr6JRAWL150CpYR5B5us0bLr T/BJZVgqCfsXw== 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 Date: Wed, 03 Sep 2025 11:03:53 -0700 From: Chris To: Tomoaki AOKI Cc: Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD In-Reply-To: <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_d26fa793762c87f411a9a66144812766" X-Spamd-Bar: + X-Spamd-Result: default: False [1.00 / 15.00]; R_DKIM_REJECT(1.00)[ultimatedns.net:s=mx99]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.20)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[ultimatedns.net:-]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Rspamd-Queue-Id: 4cH9V26Lnnz3JFm --=_d26fa793762c87f411a9a66144812766 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-09-01 01:58, Tomoaki AOKI wrote: > On Mon, 1 Sep 2025 02:58:58 +0100 > Graham Perrin wrote: > >> On 17/08/2025 01:55, Graham Perrin wrote to freebsd-pkgbase: >> >> > Subject: Using pkgbasify to repair a broken installation of FreeBSD >> > 14.3-RELEASE >> >> > >> >> >> The routine is effective, to the best of my knowledge, however it's not >> particularly attractive. At least: >> >> - the condensed steps will be too long for some users >> >> - the first step assumes that the operator will have local access >>   and a USB memory stick. >> >> I love this response to the Foundation's recent Community Check-In: >> >> > … it would be nice to have something like 'recovery partition', as >> some OSes have. or at least some tiny fail-safe feature. having remote >> machine in some distant datacenter, booting from a flashstick is always >> a problem. >> >> >> >> An enhancement to bsdinstall could, before creation of the partition >> table, allow the user to specify an amount of space to be left free at >> the end of a device … > > On legacy BIOS boots, using MBR (boot0) of FreeBSD allows selecting > which base 4 partition "in the drive" to boot. > So keeping this limitation in mind, rescue partition is possible > and if there's KVM switch accessible via netowork, selections > can be done on boot (not sure about IPMI: no experience). > > Currently, both UEFI boot1.efi and loader.efi don't have something > alike "on stock". Ability to choose BE from loader is available, > but IIUC, it can do nothing when the pool itself is causing problem. > > > On the other hand, boot1.efi has patch to choose partition / pool > to boot at Bug 207940, which is not landed but I'm always using. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 > > But unfortunately, boot1.efi is deprecated (no expiration target > defined, though) and no merge would be expected. > > > So it would be nice if loader.efi has this kind of feature. > > Implementing with lua and/or forth shouldn't be an option, > as it wouldn't work once the pool / partition loader.efi > looks into is somehow broken. > > So should be implemented as the functionality of loader.efi itself and > show its selection menu BEFORE usual boot menu by lua/forth is shown. I was thinking of bolting something onto loader when I first read this too. But to my mind, wouldn't being able to load an image file be a more versatile choice? The ability to load and boot into a minimal FreeBSD environment from say an mfs image would be fantastic. You could place it on your FreeBSD root slice or on the ESP. If on the ESP, it's as if you're already using a special "boot" partition. Apologies if I'm dragging this too far off topic. --Chris -- The internet is not a place. --=_d26fa793762c87f411a9a66144812766 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_d26fa793762c87f411a9a66144812766-- From nobody Wed Sep 3 23:15:44 2025 X-Original-To: freebsd-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 4cHJQ34ygDz66LWt for ; Wed, 03 Sep 2025 23:16:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4cHJQ30gJfz3vGk for ; Wed, 03 Sep 2025 23:16:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 583NFiwR080961; Thu, 4 Sep 2025 08:15:45 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1756941346; bh=AicSDQ4qrEzvAX29Yskmy+ru8daGobKl3VHB2lMjncY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=E5Em5IQxV0dn2Kub6V8Cqfi9JRV4OOTGfyx0DfqB3kJmD+KaQhqSQRskx3pL2GXdA eGhFxZnXKzCbEYAVN5oUhjL9uhja+Ty6bEamKswwIOvqIWSl4Ng3E9UO3UdxiPSmg1 9F5mpXwlYhk02JzK9bDXW59eFPyurwMS4iPcp37o= Date: Thu, 4 Sep 2025 08:15:44 +0900 From: Tomoaki AOKI To: Chris Cc: Graham Perrin , FreeBSD-CURRENT Subject: Re: Using a recovery partition to repair a broken installation of FreeBSD Message-Id: <20250904081544.4e1ac6d13377dac565aa434d@dec.sakura.ne.jp> In-Reply-To: References: <7b384ac0-9b24-43a4-bf63-012d745155a7@gmail.com> <18e1a7e9-07d8-43a2-96af-0acdab6c2920@gmail.com> <20250901175827.73ba0ea24812cebe2263811f@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.3) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cHJQ30gJfz3vGk On Wed, 03 Sep 2025 11:03:53 -0700 Chris wrote: > On 2025-09-01 01:58, Tomoaki AOKI wrote: > > On Mon, 1 Sep 2025 02:58:58 +0100 > > Graham Perrin wrote: > > > >> On 17/08/2025 01:55, Graham Perrin wrote to freebsd-pkgbase: > >> > >> > Subject: Using pkgbasify to repair a broken installation of FreeBSD > >> > 14.3-RELEASE > >> > >> > > >> > >> > >> The routine is effective, to the best of my knowledge, however it's not > >> particularly attractive. At least: > >> > >> - the condensed steps will be too long for some users > >> > >> - the first step assumes that the operator will have local access > >>   and a USB memory stick. > >> > >> I love this response to the Foundation's recent Community Check-In: > >> > >> > … it would be nice to have something like 'recovery partition', as > >> some OSes have. or at least some tiny fail-safe feature. having remote > >> machine in some distant datacenter, booting from a flashstick is always > >> a problem. > >> > >> > >> > >> An enhancement to bsdinstall could, before creation of the partition > >> table, allow the user to specify an amount of space to be left free at > >> the end of a device … > > > > On legacy BIOS boots, using MBR (boot0) of FreeBSD allows selecting > > which base 4 partition "in the drive" to boot. > > So keeping this limitation in mind, rescue partition is possible > > and if there's KVM switch accessible via netowork, selections > > can be done on boot (not sure about IPMI: no experience). > > > > Currently, both UEFI boot1.efi and loader.efi don't have something > > alike "on stock". Ability to choose BE from loader is available, > > but IIUC, it can do nothing when the pool itself is causing problem. > > > > > > On the other hand, boot1.efi has patch to choose partition / pool > > to boot at Bug 207940, which is not landed but I'm always using. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 > > > > But unfortunately, boot1.efi is deprecated (no expiration target > > defined, though) and no merge would be expected. > > > > > > So it would be nice if loader.efi has this kind of feature. > > > > Implementing with lua and/or forth shouldn't be an option, > > as it wouldn't work once the pool / partition loader.efi > > looks into is somehow broken. > > > > So should be implemented as the functionality of loader.efi itself and > > show its selection menu BEFORE usual boot menu by lua/forth is shown. > > I was thinking of bolting something onto loader when I first read this too. > But to my mind, > wouldn't being able to load an image file be a more versatile choice? The > ability to load > and boot into a minimal FreeBSD environment from say an mfs image would be > fantastic. You > could place it on your FreeBSD root slice or on the ESP. If on the ESP, it's > as if you're > already using a special "boot" partition. Apologies if I'm dragging this too > far off topic. > > --Chris > > -- > The internet is not a place. It should be what's discussed starting from here. https://lists.freebsd.org/archives/freebsd-current/2025-September/008675.html -- Tomoaki AOKI From nobody Wed Sep 3 23:19:48 2025 X-Original-To: freebsd-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 4cHJVQ4M76z66M2N for ; Wed, 03 Sep 2025 23:19:58 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHJVP5ymhz3wNZ for ; Wed, 03 Sep 2025 23:19:57 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="Bjv7gj/S"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-45b7d485173so3221795e9.0 for ; Wed, 03 Sep 2025 16:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756941590; x=1757546390; darn=freebsd.org; h=in-reply-to:autocrypt:content-language:from:references:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=rqXaPuPOZt9+9mDCxiLTq0PoWzL9MZzlZzm1WXkEgFA=; b=Bjv7gj/SLwBg77ze0BTN0/oS4Q7fCqhiSC020AUCNP2hNMFpqGRM2BLVMYgkrptZ6e rmC4Bn+vl1op5ckpf1zKAMSC8Q84yfJPvr/cM1iihf/Gr9/NqKy0PmcrLo0ctpy/WpDk Dyo/oagzFSAsk6uTUq7/Q1cBL4dUiEtbSTkUdiRK/uvPkxnAkxC01hfiKYbhWQ8gweN4 yXC4mC1x2X5kM4t0maiU0oqNg1fHdiSxdwI0Bk7iNo+10C460y6W2/T4riT7Nr7HiVDS p14GKwKM9otBFkNL+EXYbo1Fh+42AaFyWJvlSQadlQ8mqlHD/NxwnDG/ZETzQfyJ1Gju AjeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756941590; x=1757546390; h=in-reply-to:autocrypt:content-language:from:references:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=rqXaPuPOZt9+9mDCxiLTq0PoWzL9MZzlZzm1WXkEgFA=; b=a6AhitBdmE8EyMAnbX+9df5INE42myj4Iq7TWQ8ZUbOr8qPUVAJUxFd2M53dgITI17 P5sSnUtzlMaSaVETOq4NS6m1FPmxcC/rCzp7kvZ04RSWfSBJdk2PGqmprHKBLFUWlARo QQX1B/UOgjoaj1nBkuk1Yo4tMu3O94yYxG3vZrM/dAcBAm/fncL0J5Z2jdt8VN17R9Kr vVxjO8ghwuTQbe/Kp16AzKaSMDhRUGfBZAhKEd6VFA37ejAffPGyBlDxwvzzH0Vf2PGQ gxaOtSxkqrCIfySb088RxD+5kiRuRlXlNnEEgd4v37ZZXt8EYQBRVo35/EBEPg2AM4C9 J1Eg== X-Gm-Message-State: AOJu0YywoLJqIjQXCIIFhEj893RhLfY9p0/957gjdATSz+FD9jaW+AO0 3TffjDb31h330OxpQNGuq6W+d/6DyDPaRB0ZzeBfmuUZHiHOhP08su0GZAciGw== X-Gm-Gg: ASbGncvms2GHsVATDDRXnjEwAuJqDD+sX7THxOc5aPpJixte4preVT2mkuZIn7CsYGP z7d6GqingKuyFTYZXR/tT6yyLxvb95kQABQ0kAxg8/oeZpA8kHI2fpiiQbOU6MzIpwhKJkiNhhl O3F2h0s4LtNkqjd/YxteutXExwz47WPOc/15wDvNlkfHkNDiJPrVJSo+WG5piHtM69GhW8+D0yT UUsePlYXXh4FYJ5jTUmh8PiOADsw6r4aGutd5+YjzNaHtbYJHJL4g9Kozykf6VYZXQuw7ftQIaJ v49aGPueS/U7fUORtpP2HTeW9mX0vt58LyiAQ1FqNYqjavnsYCvwNt2+fghUK2ZvxU2wcSw1iEy +i1mfHA2Se9AqLvNsectUK2COj51J309c87MSnxIDfVSAP6dIDs36d6SOLSw= X-Google-Smtp-Source: AGHT+IES2zD0TLWzkINav+ggNMd3RbMkAX8qVlNQ0ECGqbAEpG+Reute2bjJoOm3yfFMXaeYOTzkIQ== X-Received: by 2002:a05:600c:1f94:b0:45b:772b:12b9 with SMTP id 5b1f17b1804b1-45b855336dcmr144065975e9.15.1756941589695; Wed, 03 Sep 2025 16:19:49 -0700 (PDT) Received: from [192.168.1.4] (host-89-241-205-78.as13285.net. [89.241.205.78]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e8ab14esm282851475e9.21.2025.09.03.16.19.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Sep 2025 16:19:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------0AfP0dj04J0JbhUCc0v4r8cx" Message-ID: <2f4bacf4-379c-4ed0-8315-384417283e7d@gmail.com> Date: Thu, 4 Sep 2025 00:19:48 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: pkg broken? To: FreeBSD-CURRENT References: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> From: Graham Perrin Content-Language: en-GB Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJoRALAAhsDBQkPEg5ABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQL8YkP/2V1z6XQDyG1QlKAu8TuE8zDWy9QQKjC/G44hlu5zk+2kWSNk4zeExs9ZXOBmVhF EW1d+1J8wDiYIeKYj/rqMoP+gb8o0Au0lSRitvTdLxkZBFGMn0CEzlDOzv+wmiy0ggAV/s+Y EbiHk12fI0LoTy5/ywdmG/uGS7M6p3XOrM0YO1qmLXy1cUyYDsYIpq5/rT0QzpGowsJLoEA3 zz1vfKVY+RTorsL4W8ljXLmcs4c3b3HZG9Xmgtt+Ni/eb9CjzM7kCXOcSMnVzvfscCowPAwB 0ZHlNxNV0MTa61xgvOCk4Zf278ArRgbTm4oOz9Z4ciPMnVue+9P/VdxIxgUuYkAryM0+agGz L9bd8ljn+efNtgZ5dlDLrNnTE+vWnMVlMXgl7BNnhwHg7UYFLrC2xklsICub0qpnNheTGeqo 0N4UongJTQJ6H6LEpgd+KMkCncAHghED/G0/BUdO90VEOoqnIKwKa+F9NqVMvHWc8D58mwCP FghsmxK9FM9pnsjLmG7u+s51Y7++GSRnU4NkI4tHiVk7hcAcvZuc0QbUDwVMTurDUgIqRo6W 80j1tFjEspkrwtMoeVFEkDHktjoc3AoEymXIncZfqIqi3nVseyDVyNByvkV0mutX9hXqac0/ RXMuyK9KniAUZ9+gsWs4rPs/DOdsw4K8/RnjduBrfCYQzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmhEAsACGwwFCQ8SDkAACgkQt2dIb0oY1AvQxw//REWYFK2m4yS/QP5kzfhkWcNqDI/akGT5 /LXmdmbc1s78+mOMXnA4vBY/+X1QatgxWUECkPDOiIwXJMxoBuyY8e7spLRXeyhtfh5aYaJc MO5bARX0c49v+KfZ80u9tG2rkKQvAt/ySo7OXsbDADFFRhlc8RLbb8e7bSctGbYZk9CYa0ya dW5+n3znDNJ6yW1skx9wTH+Y8VlSazRLk3XgXscNqBA2h56v3WS/R5dI++7AQxZxSQacQvfj 9eahq7ATdB4zMQ9MBHEwOvGD3DLlc55FYSDZvNX+mhnK7S0t1Nt2EtGUOmXb5ysMFGnbsce0 woKQ0sLPF1HWDAAf7tBCF8mpPIzU/ViAkupsJ6NYCD0tLFD8pvl0NYU2TjvyWh6ie3e5B/b3 8Daiyme+M92ivfoRQOFKmkPfeT14AI6OW1k7qFbmoIwMWWQdFWAl1CP9hNdF9gRN4rFB0Jy1 90BajZW2zOdVfqdurJZegCzAowZalLm4JEK2MklpPzipibnJqhLOmvJy587pF52KDdM/4rLy BBREIm7uRivnO5k/BY5qS+H/aqv97LC0PVaTsLXbDmTxTnJplUpdlYT9NGidM+x/ioS0iztO Cht7cT8V8jvvKZYvNpst8iqxuIaoV9V7aZ0wAQpkgDGXHmSzwtz6U8xNf/4e4sLn9KPlldSd kvo= In-Reply-To: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4cHJVP5ymhz3wNZ This is a multi-part message in MIME format. --------------0AfP0dj04J0JbhUCc0v4r8cx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/09/2025 02:20, Dan Mahoney (Ports) wrote: > Hey all, > > After an update today to what looks like snap20250828153719.pkg, it would seem pkg doesn’t want to play ball. > > root@poudriere-pkb:/etc/pkg # pkg update > Updating FreeBSD-ports repository catalogue... > FreeBSD-ports repository is up to date. > Updating FreeBSD-ports-kmods repository catalogue... > FreeBSD-ports-kmods repository is up to date. > Updating FreeBSD-base repository catalogue... > FreeBSD-base repository is up to date. > Updating FreeBSD repository catalogue... > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.txz -- pkg+:// implies SRV mirror type > repository FreeBSD has no meta file, using default settings > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.pkg -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.tzst -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.pkg -- pkg+:// implies SRV mirror type > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.tzst -- pkg+:// implies SRV mirror type > Unable to update repository FreeBSD > Error updating repositories! > root@poudriere-pkb:/etc/pkg # uname -a > FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE main-n280004-00c9ebbbc653 GENERIC amd64 > root@poudriere-pkb:/etc/pkg # freebsd-version > 15.0-PRERELEASE > > > … Which mirror? One comparable report, from a user of RELEASE with the Chicago mirror: --------------0AfP0dj04J0JbhUCc0v4r8cx Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 03/09/2025 02:20, Dan Mahoney (Ports) wrote:
Hey all,

After an update today to what looks like snap20250828153719.pkg, it would seem pkg doesn’t want to play ball.

root@poudriere-pkb:/etc/pkg # pkg update
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
Updating FreeBSD repository catalogue...
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.txz -- pkg+:// implies SRV mirror type
repository FreeBSD has no meta file, using default settings
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.tzst -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.tzst -- pkg+:// implies SRV mirror type
Unable to update repository FreeBSD
Error updating repositories!
root@poudriere-pkb:/etc/pkg # uname -a
FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE main-n280004-00c9ebbbc653 GENERIC amd64
root@poudriere-pkb:/etc/pkg # freebsd-version
15.0-PRERELEASE


…


Which mirror? 

One comparable report, from a user of RELEASE with the Chicago mirror: 

<https://www.reddit.com/r/freebsd/comments/1mzvgxm/comment/nbjxyvt/>

--------------0AfP0dj04J0JbhUCc0v4r8cx-- From nobody Thu Sep 4 12:20:09 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 4cHdpq61dJz65v0S for ; Thu, 04 Sep 2025 12:20:19 +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 4cHdpn5QXxz4PP8 for ; Thu, 04 Sep 2025 12:20:17 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 584CK9GJ074890 for ; Thu, 4 Sep 2025 12:20:09 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 584CK97k074889 for current@freebsd.org; Thu, 4 Sep 2025 05:20:09 -0700 (PDT) (envelope-from david) Date: Thu, 4 Sep 2025 05:20:09 -0700 From: David Wolfskill To: current@freebsd.org Subject: Panic after kldload i915kms at main-n280058-e7a04a110724 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="DQXit6Si6vsDQLZb" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.29 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.89)[-0.890]; 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: 4cHdpn5QXxz4PP8 --DQXit6Si6vsDQLZb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yesterday's (source-based) update was to main-n280031-11f1dd193af5, and I saw no issues. Today's was to main-n280058-e7a04a110724. My (headless) build machine (which does not attempt to either build or load the module), and uses the GENERIC kernel, had no issues. I note that the machines that load the modules also build them whenever the kernel is built. All machines mentioned here are amd64. The ports tree is at main-n717402-cd0318d52939. (Yesterday, it was at main-n717309-326381de144d.) Installed ports are updated daily. On one of the affected laptops, following the panic, I booted to single-user mode & ran: swapon -a && fsck -p && mount -a That done, I (manually) issued kldload i915kms and (hand-transcribed -- phone is updating): root@:/ # kldload i915kms Fatal tyrap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault bvirtual address =3D 0x68 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80a92491 stack pointer =3D 0x28:0xfffffe108ecea5e0 frame pointer =3D 0x28:0xfffffe108ecea630 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 37 (kldload) =2E..[sorry; I'm getting a bit impatient....] KDB: stack backtrace: db_trace_self_wrapper() at ... vanic() at ... panic() at ... trap_pfault() at ... calltrap() at ... --- trap 0xc, rip =3D 0xffffffff80a92491, rsp =3D 0xfffffe108ecea5e0, rpb = =3D 0xfffffe108ecea630 --- pfs_create_dir() at ... debugfs_create_dir() at ... drm_core_init() at ... linker_load_module() at ... linker_load_dependencies() at ... link_elf_laod_file() at ... linker_load_module() at ... kern_kldload() at ... sys_kldload() at ... fast_syscall_common() at ... --- syscall (304, FreeBSD ELF64, kldload), rip =3D 0x1fbdd4a14e2a, rsp =3D = 0x1fbdd22cde08, rpb =3D 0x1fbdd22ce380 --- KDB: enter: panic [ thread pid 37 tid 100152 ] Stopped at 0xffffffff80bce523 =3D kdb_enter+0x33: movq $0,0x1230ee2(%rip) db>=20 I will get a photo up on my Web server once the phone update is done. 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. --DQXit6Si6vsDQLZb Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaLmD+V8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5YeWAQCcD0Ob8NTRe7PgV7jfwmauF4NLxn0rd/4y+5uNu21BPQEAjNB9A+EPUuN8 u/OQp02evZAAThpBqn9R4DjS3a51sg0= =lZfO -----END PGP SIGNATURE----- --DQXit6Si6vsDQLZb-- From nobody Thu Sep 4 12:33:03 2025 X-Original-To: freebsd-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 4cHf5Y33Jkz65vyP for ; Thu, 04 Sep 2025 12:33:05 +0000 (UTC) (envelope-from benoit@neviani.fr) Received: from taslin.fdn.fr (taslin.fdn.fr [80.67.169.77]) (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 4cHf5X6CVvz3FSk for ; Thu, 04 Sep 2025 12:33:04 +0000 (UTC) (envelope-from benoit@neviani.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=neviani.fr header.s=fdn header.b=pD91+SEN; dmarc=pass (policy=none) header.from=neviani.fr; spf=pass (mx1.freebsd.org: domain of benoit@neviani.fr designates 80.67.169.77 as permitted sender) smtp.mailfrom=benoit@neviani.fr Received: from [IPV6:2a02:8440:b508:3559:a8e:90ff:fe1f:3e25] (2a02-8440-b508-3559-0a8e-90ff-fe1f-3e25.rev.sfr.net [IPv6:2a02:8440:b508:3559:a8e:90ff:fe1f:3e25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by taslin.fdn.fr (Postfix) with ESMTPSA id F15866067F for ; Thu, 4 Sep 2025 14:33:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neviani.fr; s=fdn; t=1756989184; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Cm215Hgu9O35hzH0wQSzQOAEOM2mNzMB0m1jrk9sUqI=; b=pD91+SENv12lIQd+4KgzhQx3wkjBYG6NnXYstdye/fPyduYSW49HsWn0D6xrqiqYKYRfgx 9wvfAjt4y+uT6+cQLay0Lp3PCAL4JC4sjAV6y16f7tWoGA8wUV5tkXZqLDPfC9ozb6OBSu 2DNbf4iNciUqKXhaQ0n0cXi5qWPByF9gaeeQcaz9rlzTIVm5rEIhkPX2JPZKq5Nz/QxWR7 WNwMt/ap8Nh1rqes6DemHGYFupNf9MgepHsmx3bbNp/WOUzlt3jv/K49kSQVFRob4JqW+Z nlBRxwp7gyUpVBmILJEcEJCsYmaFjP3N/kspok+hNraGSlPy+z4mz4cmcE789A== Content-Type: multipart/alternative; boundary="------------P8BNsEmq8ERbWjxfLRYxOLsW" Message-ID: Date: Thu, 4 Sep 2025 14:33:03 +0200 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 User-Agent: Mozilla Thunderbird Content-Language: en-US, fr, es-ES To: freebsd-current@freebsd.org From: =?UTF-8?Q?Beno=C3=AEt?= Subject: Intel Xeon 6 with high number of threads APIC IDs > 255 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[neviani.fr,none]; R_SPF_ALLOW(-0.20)[+ip4:80.67.169.77:c]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[neviani.fr:s=fdn]; RCVD_IN_DNSWL_LOW(-0.10)[80.67.169.77:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:20766, ipnet:80.67.160.0/19, country:FR]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[neviani.fr:+] X-Rspamd-Queue-Id: 4cHf5X6CVvz3FSk This is a multi-part message in MIME format. --------------P8BNsEmq8ERbWjxfLRYxOLsW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, As suggested on FreeBSD forum, here is the bug I opened : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289297 As described, this seems to be a known issue with large number of threads and APIC IDs > 255 Hopefully we are still on time for a fix for 15.0 Many thanks --------------P8BNsEmq8ERbWjxfLRYxOLsW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi,

As suggested on FreeBSD forum, here is the bug I opened : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289297

As described, this seems to be a known issue with large number of threads and APIC IDs > 255

Hopefully we are still on time for a fix for 15.0

Many thanks


--------------P8BNsEmq8ERbWjxfLRYxOLsW-- From nobody Thu Sep 4 12:39:45 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 4cHfFW6Ymhz65wdD for ; Thu, 04 Sep 2025 12:39:59 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHfFW66Z3z3HLW; Thu, 04 Sep 2025 12:39:59 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756989599; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ptkXcc17La4jL57v2iPlbamdAoYDQSBdN/ft8c43nTg=; b=RiUuLG38rqK7xwbwssitrFq+OzZznelzZ+CG6JZQG03zWcfinfX4/jzFMNm1OzB8bvxuf8 lExjBCAPSQfZi96osJwXA7MzgylZ+mqyBPw6dSS6fkvgnBo3nnJyk0Wcn2UPm+YyuoMOa5 ectrPILzhkXeFezVxj3n1fRW0RRLaE7QsyCl9nhLFUUqydrThWO9m+x0s8iejyg2xCwtVB QnySsrlcaZgpedhAUOKonlZO1Y2b8QnexHt10HiD6jWz3ziQJdmYurE+xYHyKh56awwSA2 GohNgqN8dROIBzB69gepM4Gp4WIMUtPYSZcFoLUr5RSob16AERjxQVgsfDjaFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756989599; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ptkXcc17La4jL57v2iPlbamdAoYDQSBdN/ft8c43nTg=; b=TLi667ZN7efs5Hx/IqWfTwV59aXmWSt0z/uYnvSPkDq1f/abAHZMN4c9H5nPe7xK5Fke3D aa7u21OdnQIJ2UtRUFoJtPZfG0T+NLC6SefiYw6BUsn+VC19W5gKHJSCWVpDowrqIobkOs TXGAxIACzIfEb20FCHWk0ZiVxT6PDoBTfTSfU7pbyF2Wn3c7otoxk1B+qgzq7elDvvYs3z bK1SeQRzRf/HMhZg/jmIVtAKH8Z8HMdz5eD17yikqWWSpuQ45kQQ5C4bRg2HMIyRwogY+G 6XbsNC5sDDCUeg+0SlMjnfb+lbspbOGlLYT9c5oEdcEgjsjTtroG8dF7MnNhAA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756989599; a=rsa-sha256; cv=none; b=Ss7j+8X09X2gklRiV9ovTSVFSufpoLOl3ONxApRUNEWRf64DVl6lqMei5J0K5AL/XKWEuZ ewB8Lf3FOCpLVdnpJTfl3JQXaEZmPdMvFkx8lM3t6VuuLHfzTz49h9UoVDaLLTL+mX0nL8 fPTsz2J3QOc5/FnnsMRLbXKyNczsI7WD6pRtK5ANHYGYOIIMdDuWlJ4i5nc7xvFVCBo240 2t6w2MTM6DY72//loecw95BeeA2oKPgxlMo56T2RjNS4Q8IBTZzPxXEaPiSslfmQhaJrUu P6Cs9H8mWl8+IjmiQwhUM9NB88UxQAcsGdxJWjs2Iz7fQ4bELI2E2s2vHDitxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from wsk-files-n1.wilbury.net (wsk-files-n1.wilbury.net [IPv6:2a01:4f9:2a:2851:95:216:42:37]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "E6" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cHfFW4jFkz99V; Thu, 04 Sep 2025 12:39:59 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (unknown [217.73.28.193]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 64E5F27E2E; Thu, 04 Sep 2025 14:39:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Panic after kldload i915kms at main-n280058-e7a04a110724 From: Juraj Lutter In-Reply-To: Date: Thu, 4 Sep 2025 14:39:45 +0200 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D97C74E-EDBF-47A9-B519-0D1A945BBA52@FreeBSD.org> References: To: David Wolfskill X-Mailer: Apple Mail (2.3826.700.81) > On 4 Sep 2025, at 14:20, David Wolfskill wrote: >=20 > Yesterday's (source-based) update was to main-n280031-11f1dd193af5, > and I saw no issues. Today's was to main-n280058-e7a04a110724. >=20 > My (headless) build machine (which does not attempt to either build > or load the module), and uses the GENERIC kernel, had no issues. >=20 > I note that the machines that load the modules also build them > whenever the kernel is built. All machines mentioned here are > amd64. >=20 > The ports tree is at main-n717402-cd0318d52939. (Yesterday, it was at > main-n717309-326381de144d.) Installed ports are updated daily. Out of curiosity, does the problem go away when you revert commit = a2f08d0ddc29e4da15f614bdb6a5072b3fd6332c ? It is the most recent one that touched pseudofs subsystem. =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Thu Sep 4 12:52:20 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 4cHfWn5355z65xXs for ; Thu, 04 Sep 2025 12:52:21 +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 4cHfWn3LGMz3Kp4; Thu, 04 Sep 2025 12:52:21 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 584CqKCu075253; Thu, 4 Sep 2025 12:52:20 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 584CqKuM075252; Thu, 4 Sep 2025 05:52:20 -0700 (PDT) (envelope-from david) Date: Thu, 4 Sep 2025 05:52:20 -0700 From: David Wolfskill To: Juraj Lutter Cc: current@freebsd.org Subject: Re: Panic after kldload i915kms at main-n280058-e7a04a110724 Message-ID: Mail-Followup-To: David Wolfskill , Juraj Lutter , current@freebsd.org References: <6D97C74E-EDBF-47A9-B519-0D1A945BBA52@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="Zz8yAYozG7l9MIN5" Content-Disposition: inline In-Reply-To: <6D97C74E-EDBF-47A9-B519-0D1A945BBA52@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cHfWn3LGMz3Kp4 --Zz8yAYozG7l9MIN5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 04, 2025 at 02:39:45PM +0200, Juraj Lutter wrote: > ...=20 > Out of curiosity, does the problem go away when you revert commit a2f08d0= ddc29e4da15f614bdb6a5072b3fd6332c ? >=20 > It is the most recent one that touched pseudofs subsystem. > .... Thanks; I will try it & report. In the mean time, I have screenshots for the panic up at https://www.catwhisker.org/~david/FreeBSD/head/n280058/ 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. --Zz8yAYozG7l9MIN5 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaLmLg18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5X/4AQDkG9Jm3ihgH7sq+ZfB7F8jgUoI70UHukI8XRYvmVangwEAsjMEtNir5ZuR rb2RewuVVGHjIlRdp+YrjJAUpdlUtAo= =dBsV -----END PGP SIGNATURE----- --Zz8yAYozG7l9MIN5-- From nobody Thu Sep 4 13:29:34 2025 X-Original-To: freebsd-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 4cHgLm4RY1z6622q for ; Thu, 04 Sep 2025 13:29:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHgLm3Qtyz3Rp1; Thu, 04 Sep 2025 13:29:36 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756992576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OJoqMtePqv5nje05FGBhyOtPbeDswcZ52hVfmzZUXYI=; b=Xf+3ceA3dxex9MpOpG/NIg1G2i7jJ8KyaA6ZD+PpW3TolCBlx+fuXGX1PA1Wys+SMN0v79 jXpmgIxnUDE0GfMRAo8k7L2gu3HL3UydpNzjQS/IKk5nzq5TmM1wD2XNMcFfLqaox2JM27 nWYJ7kxXiNZ7YQv2vhZi1JzWumMiSnOWltp8jxY2DOzOfy24VCH3MLRU3Qtc0Tb0gln7Gt anwF4gZbZmF0LfI/st3V9PwxixcJN86Mqf6PwVXVlak4Qc1/OM6U2fPg/TMB1JDAAn3+jG /GnIyi5/BY9nbDzb7DqAkiBjaPTshEdu1aU9mDoSfD+CDT6wzPo2F/2Cwtw/IA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756992576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OJoqMtePqv5nje05FGBhyOtPbeDswcZ52hVfmzZUXYI=; b=pXNlf+Yu0Kme825fLtiEL0hfzf2TDQgSecpd99C55PQ1UsfAXeZHVX9r7qgbjIxZDMbhGJ YKWd7Kp+2iOznMWeHHLoG1fUFMv8bIMixuIhGfSc49KXs5MPX/Kwfw38pHdw/DT9rDRdhp ae8wamn38Jk3mMKuzWP35dyv5yW0z/C2Pok5ZQr0NoqjHVbJ8n3yg+g9t9rOR9XhLq2lKu GvEVNkwrTzdHVS3ZkSeqzJaUuc8f3m5JQ34hlQkSydBf/48e8IL6/haOkT32qFly9vLgIK 0JP9/mvcmj4AfirCVQGBSyUMwb8DFO5u8GGOHcTqs9pNVGa2VNPd+mumQFAF6Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756992576; a=rsa-sha256; cv=none; b=MRT8jcGrOfmsKZKlnz2Fw4/qQim9N0z82QG3Oxiv0qPP6kdBfmLjD1SEh7sIAW3IbZnvDz 3llvcMBl3DhvfC+OzTWP0cqBtWQS6N1k+nfrzznEZr5NlzscDlV9v32eduS4aSmQZVMDfd O3oQjb0W1xpbYM/1QZpHyt7gq0+3eKYFRQvXEZaMwl/FRs4+gFLW3vBqRi+7wQ2H8+52vg CFKYeVTTbqVMGnceWf/ghUgdl8qEoZCQX7PAmjGNakDHQBxSoS1CBJbUGiSf6kfwuD/bSj G3fidABkX3a7wwQNZWcQQf05Kx3UjyiXGj1YjcMIeGLqRnN72FNSFeedvz9Z2Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cHgLm1MKNzCdp; Thu, 04 Sep 2025 13:29:35 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <64c7bb13-ce6a-49a5-a7a1-952ce2f35a9e@FreeBSD.org> Date: Thu, 4 Sep 2025 08:29:34 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: Panic after kldload i915kms at main-n280058-e7a04a110724 To: freebsd-current@freebsd.org References: <6D97C74E-EDBF-47A9-B519-0D1A945BBA52@FreeBSD.org> Content-Language: en-US Cc: Cy Schubert From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/4/25 07:52, David Wolfskill wrote: > On Thu, Sep 04, 2025 at 02:39:45PM +0200, Juraj Lutter wrote: >> ... >> Out of curiosity, does the problem go away when you revert commit a2f08d0ddc29e4da15f614bdb6a5072b3fd6332c ? >> >> It is the most recent one that touched pseudofs subsystem. >> .... > > Thanks; I will try it & report. > > In the mean time, I have screenshots for the panic up at > https://www.catwhisker.org/~david/FreeBSD/head/n280058/ > > Peace, > david Hi, Sorry for the hassle, this is reverted in d3462294c1f02ca20cc1869d618bde57559f5914. I had smoke-tested all in-tree pseudofs, but missed that lindebugfs is mostly initialized in drivers that populated it rather than in lindebugfs itself. I'll add it to my list to circle back to later. Thanks, Kyle Evans From nobody Thu Sep 4 13:39:19 2025 X-Original-To: freebsd-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 4cHgZ15Wwxz662ts for ; Thu, 04 Sep 2025 13:39:21 +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 4cHgZ11RKnz3Trn; Thu, 04 Sep 2025 13:39:21 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 584DdJUe075874; Thu, 4 Sep 2025 13:39:19 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 584DdJx5075873; Thu, 4 Sep 2025 06:39:19 -0700 (PDT) (envelope-from david) Date: Thu, 4 Sep 2025 06:39:19 -0700 From: David Wolfskill To: Kyle Evans Cc: freebsd-current@freebsd.org, Cy Schubert Subject: Re: Panic after kldload i915kms at main-n280058-e7a04a110724 Message-ID: Mail-Followup-To: David Wolfskill , Kyle Evans , freebsd-current@freebsd.org, Cy Schubert References: <6D97C74E-EDBF-47A9-B519-0D1A945BBA52@FreeBSD.org> <64c7bb13-ce6a-49a5-a7a1-952ce2f35a9e@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="yWBDMIm5pBGrPIeq" Content-Disposition: inline In-Reply-To: <64c7bb13-ce6a-49a5-a7a1-952ce2f35a9e@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cHgZ11RKnz3Trn --yWBDMIm5pBGrPIeq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 04, 2025 at 08:29:34AM -0500, Kyle Evans wrote: > On 9/4/25 07:52, David Wolfskill wrote: > > On Thu, Sep 04, 2025 at 02:39:45PM +0200, Juraj Lutter wrote: > > > ... > > > Out of curiosity, does the problem go away when you revert commit a2f= 08d0ddc29e4da15f614bdb6a5072b3fd6332c ? > > >=20 > > > It is the most recent one that touched pseudofs subsystem. > > > .... > >=20 > > Thanks; I will try it & report. Just finished rebuild after local reversion of a2f08d0ddc29e4da15f614bdb6a5072b3fd6332c (main-n280055-a2f08d0ddc29); panic looks unchanged. > > In the mean time, I have screenshots for the panic up at > > https://www.catwhisker.org/~david/FreeBSD/head/n280058/ > ... > Hi, >=20 > Sorry for the hassle, this is reverted in d3462294c1f02ca20cc1869d618bde5= 7559f5914. I had smoke-tested > all in-tree pseudofs, but missed that lindebugfs is mostly initialized in= drivers that populated it > rather than in lindebugfs itself. I'll add it to my list to circle back = to later. >=20 > Thanks, >=20 > Kyle Evans Ah -- that's reverting 65059dd2b6f94e570acc645be82b8ea056316459 (main-n280054-65059dd2b6f9). OK. Thanks for the fix! 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. --yWBDMIm5pBGrPIeq Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaLmWh18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5cCYAP9/yvM6W4Nps7vmrRyIJMAFBXoVwenqc9E2x3gzNurEcAEA+MzyAd53nI14 S3XEj5HmHdCE/TqBgAUEDAYQHM32+gA= =9TLJ -----END PGP SIGNATURE----- --yWBDMIm5pBGrPIeq-- From nobody Thu Sep 4 14:13:11 2025 X-Original-To: freebsd-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 4cHhKK4jdMz665vY for ; Thu, 04 Sep 2025 14:13:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (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 "smarthost1.sentex.ca", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHhKH5jmyz3ZkV for ; Thu, 04 Sep 2025 14:13:23 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 584EDD3P094951 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Thu, 4 Sep 2025 10:13:13 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:40a5:51be:79a7:f121] ([IPv6:2607:f3e0:0:4:40a5:51be:79a7:f121]) by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 584EDAML014060 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 4 Sep 2025 10:13:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: Date: Thu, 4 Sep 2025 10:13:11 -0400 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 User-Agent: Mozilla Thunderbird Content-Language: en-US To: freebsd-current From: mike tancsa Subject: testing HEAD and packages Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.53 / 15.00]; NEURAL_HAM_LONG(-0.96)[-0.962]; NEURAL_HAM_MEDIUM(-0.95)[-0.951]; RCVD_IN_DNSWL_LOW(-0.20)[2607:f3e0:0:1::12:from,199.212.134.19:received]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; NEURAL_HAM_SHORT(-0.12)[-0.117]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; FREEFALL_USER(0.00)[mike]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sentex.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cHhKH5jmyz3ZkV Was going to give the pre-release a spin, but it looks like many of the packages are not available? root@freebsd:~ # pkg update Updating FreeBSD-ports repository catalogue... FreeBSD-ports repository is up to date. Updating FreeBSD-ports-kmods repository catalogue... FreeBSD-ports-kmods repository is up to date. All repositories are up to date. root@freebsd:~ # pkg search git libgit2-1.9.1                  Portable, pure C implementation of the Git core py311-PyGithub-2.7.0           Python library implementing the full GitHub API v3 root@freebsd:~ # root@freebsd:~ # pkg search pou root@freebsd:~ # Whats the best way to bootstrap things for git etc ?     ---Mike From nobody Thu Sep 4 14:18:06 2025 X-Original-To: freebsd-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 4cHhQq0slcz666GD for ; Thu, 04 Sep 2025 14:18:11 +0000 (UTC) (envelope-from ivy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHhQp6yprz3cCf; Thu, 04 Sep 2025 14:18:10 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756995491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qHUk+rXHVxiqPrJvi/Q9U6LBHOGRXV2UqihcTmeBE4U=; b=iVkByONxbvKNWqKzSbQcqVq781+NSfQCCz3RcO2B/0EW4TccREOCjDFhLwyMJKjMtOJygT EEbbit9V166+XpjD8AN+YMHKnzJXF7EOVVgzUfFbP13Rp3XYRHD4FZA1oPGt7P76EkHI9e XsAaq6Ea/IejNVOSvMq4/JXzhOW6paUhLBqUGKaJQCLbjQG7DSpxPCy0vhlEiWukeuhXZ/ TNoFqIdGl7ZrF7J6SubIsb3r8TXqRbyBAUGJDnKLb9XFiULCFEPH2xXRnnGS5luJD0ppmI uwqzs+U3E27DPGaZ3tBLIn+BPDDt+7uKgExtBkfKTy2Y3iL3YDi17AYuIJBi8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1756995491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qHUk+rXHVxiqPrJvi/Q9U6LBHOGRXV2UqihcTmeBE4U=; b=dGMH3kqsAIx3JNjL47ZNFD0ggIguyX0aID7mf+OLRUflC6vbnyb9MwpiZP1jTKosEJpqQO j1mJh7jwO5f5IOn9KXoMHcsKvrH7rbPB3Kj0BXni+4rVqU6xfhbIg2nNY7wEfBsk2VyUda NmZJuU4OcXpkgzj7SFR1EdLZ583G135mKyZSMe2Wq9s8D7AOH/o8tLaHxwt4jn0mtnp9De KOYnK7HbVnAOoY5R3KhCTA4tSNr5PMPrwGmqFZ1N+fROZ0hLQs1f5rwLBfGTq+/5AtZqIb V56c0BNrtw083XJ6H6zijvi5yt0gPfe2bJWAify88erjmsQeW0Ns7S4bRK7zZA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1756995491; a=rsa-sha256; cv=none; b=UKGDb8IWJw+OCSZrMDAQa7j7rVgOr8Z3giPINa0IK/WKtJXqMe0phl9yZd0n5iEhdR7/LV IXSlkoAlT1/SjTlE5/5Xzm+9O+Yu8sH2JDmffEMNX/JVbe1GYmpVVioJU4A5qPvGJKi5Os Zy9b15X7wesNsyG2tqU8/GcVVhS+9Blw33OzRMlhz2K6gbs59RT9I242WndfL9KzH+Picf 0GvDcJ+RimkrPz50pGY7hE30IegpTTmTYoEdAI6BT9tyySRrfs61i5z1bGXMSHGb+ZWzcV 8s0oIlaCc+gUqWcyY+OdbjvRdKVJgV9dEqmVdKZ1a5/TcldkjoaQtEUPDQpISQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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) (Authenticated sender: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cHhQp4BFfzD3j; Thu, 04 Sep 2025 14:18:10 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Thu, 4 Sep 2025 15:18:06 +0100 From: Lexi Winter To: mike tancsa Cc: freebsd-current Subject: Re: testing HEAD and packages Message-ID: Mail-Followup-To: mike tancsa , freebsd-current References: 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="Qy5lFj+oCibCcEme" Content-Disposition: inline In-Reply-To: --Qy5lFj+oCibCcEme Content-Type: text/plain; charset=us-ascii Content-Disposition: inline mike tancsa: > Was going to give the pre-release a spin, but it looks like many of the > packages are not available? this is because the builders did a special build for re@ to fix the snapshot builds which only includes the ~500 packages needed for that. the next "proper" build is currently in progress and should be finished in the next day or two. i believe 15.0-ALPHA1 was delayed because of this. > Whats the best way to bootstrap things for git etc ? as long as you can get a ports tree onto the host, building ports locally should work fine. e.g., do a git clone elsewhere and copy it over. or just wait until the next build finishes. --Qy5lFj+oCibCcEme Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaLmfmwAKCRD1nT63mIK/ YGKFAQCgndU0ldC2oTXZRVZlep7BEIrBmfNABiWjLzctJY5CGAEA3FDIzjTFDnVq 5gDNzVqPe8kLC1hWVk4KVgCVR28QAQA= =Qmf9 -----END PGP SIGNATURE----- --Qy5lFj+oCibCcEme-- From nobody Thu Sep 4 16:05:35 2025 X-Original-To: freebsd-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 4cHkpw4xhpz66GGH for ; Thu, 04 Sep 2025 16:05:44 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHkpv6cmXz3s7t for ; Thu, 04 Sep 2025 16:05:43 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=dBgJN+qh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-45b7da4101fso4572565e9.3 for ; Thu, 04 Sep 2025 09:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757001937; x=1757606737; darn=freebsd.org; h=in-reply-to:autocrypt:content-language:from:references:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=5lPM+aFFBn5XIs2XcUZ8/HojHDsKRnRmqVDORxa44PU=; b=dBgJN+qhQoLn4joLvrXctqslZ/QqsKEP/C9E7vX5vAk73BZ8EuZErkNIxjlqiMSXb/ vbJpHzbR5Nq8/zPm1iP/siikBlXuQPlx8l579lUVAdWDooOsk3sCefyyN1X1kPXUJ/4n aohD+IUzc2N4SCF79298mV3popqsQl1N7eRo1TCW7n6y9RIoA/9z7n9HIVfWO4lSkpEf H2+fgTVbJUo+SJptXSpJ011lzXkdemjCKXDARLwtcXuY6KpDwiqfUVjsr4Rgci9yfkAK vjXGey0JukVH5RuxLH4VSd2sjSA761377jaR9e5pkMdKhxarRI/Efjjw2V/cXkwPDzT2 MNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757001937; x=1757606737; h=in-reply-to:autocrypt:content-language:from:references:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=5lPM+aFFBn5XIs2XcUZ8/HojHDsKRnRmqVDORxa44PU=; b=dDZXh/2OyvJmr/OBWOu6DbmQy1eMe0Nw3u5RPV6EJdauBO35kgsdF31JdpL8/AZUZC XcyCVRfUCaA0KtN8c32HjEwQddoPX/t09WR7YsTxUr7EREF2BnmI4xjqT8gcRg6Nuf7O jGMFmZYIfHUPejHMcsm7YYL3ILnhu0F/UWS96VBG7LlfDMIqJoi3Y/ectfqbzeb8yP16 1+iPaFuDjvKW8VrfI5WhrOZTSPZBz2ho5NV21UzOJrGETqOses6L9d+obmhiP/c6k4Du mtH8LiTn9bb0+sgYTH3O8wQjPgU+sbTGCMnWNPil+OnKaMJI/fd7kYWTUpZjTJGc0dez tfEg== X-Gm-Message-State: AOJu0YxLLppYbDVyXnElISKJVN1bq/3Q2OtFJG5Gu4NSZMpWLd1QqeCO DuqWHrlXvE5RhSeCzww4j7A/o7JroGew9yixyXrwLIT8y1kKdvYDvotBApMMPQ== X-Gm-Gg: ASbGncuzymFj6M8KwqdBfl8IeQsZfCT19wtOZbJdYNtNjStqps/0J6tjkKtgE/nt8ia e2lZB6QCxs59tGi//dtEoR4vHwUGplcrmnIDw7s+S1AhsB47CZJPCBaulSqC/4Na33QXPy2cL9f q7aN4Ud0Cg2lGzk20wCwlS9/DnTS49BdqXvDEtjdmSlY8+nqcmKcvwL6wnd4rt/p1F4Eqn0hpDh vL0aL04XmjbSMb0SL5fHYhGH4L2cuM3SpxCHR2mX8fSnTAjlEzaZm7l062UeGJsX9PmRucn/X8w kqqw17Oa+YTs/v7WwRid4Rpl1wSToOYYrB0K6pLyeuoi25Beugh7/COgw1y2DsNwxcLy1n0cpoO 3H9Zu5Rq7OHG4pR5V0O4a2okinaaK3asn34by8KSWHoDCo8ESZdDINVRpSFY= X-Google-Smtp-Source: AGHT+IF5c7qSaCIF6yMz4b2tEVL5T5JrqKPHWSsmpB310R3ZDeADVoCG2wBUPE0gOXFS0o0TyNe2VA== X-Received: by 2002:a05:600c:c4ab:b0:45b:47e1:ef6d with SMTP id 5b1f17b1804b1-45b855b3032mr150147635e9.36.1757001937017; Thu, 04 Sep 2025 09:05:37 -0700 (PDT) Received: from [192.168.1.4] (host-89-241-205-78.as13285.net. [89.241.205.78]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45dcfa3ec60sm43499575e9.15.2025.09.04.09.05.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Sep 2025 09:05:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------3RmUcHoX5zRnne9FfT0PTr1P" Message-ID: <6242c75a-7514-4e38-b13e-67c82dc745c6@gmail.com> Date: Thu, 4 Sep 2025 17:05:35 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: testing HEAD and packages To: freebsd-current References: From: Graham Perrin Content-Language: en-GB Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJoRALAAhsDBQkPEg5ABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQL8YkP/2V1z6XQDyG1QlKAu8TuE8zDWy9QQKjC/G44hlu5zk+2kWSNk4zeExs9ZXOBmVhF EW1d+1J8wDiYIeKYj/rqMoP+gb8o0Au0lSRitvTdLxkZBFGMn0CEzlDOzv+wmiy0ggAV/s+Y EbiHk12fI0LoTy5/ywdmG/uGS7M6p3XOrM0YO1qmLXy1cUyYDsYIpq5/rT0QzpGowsJLoEA3 zz1vfKVY+RTorsL4W8ljXLmcs4c3b3HZG9Xmgtt+Ni/eb9CjzM7kCXOcSMnVzvfscCowPAwB 0ZHlNxNV0MTa61xgvOCk4Zf278ArRgbTm4oOz9Z4ciPMnVue+9P/VdxIxgUuYkAryM0+agGz L9bd8ljn+efNtgZ5dlDLrNnTE+vWnMVlMXgl7BNnhwHg7UYFLrC2xklsICub0qpnNheTGeqo 0N4UongJTQJ6H6LEpgd+KMkCncAHghED/G0/BUdO90VEOoqnIKwKa+F9NqVMvHWc8D58mwCP FghsmxK9FM9pnsjLmG7u+s51Y7++GSRnU4NkI4tHiVk7hcAcvZuc0QbUDwVMTurDUgIqRo6W 80j1tFjEspkrwtMoeVFEkDHktjoc3AoEymXIncZfqIqi3nVseyDVyNByvkV0mutX9hXqac0/ RXMuyK9KniAUZ9+gsWs4rPs/DOdsw4K8/RnjduBrfCYQzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmhEAsACGwwFCQ8SDkAACgkQt2dIb0oY1AvQxw//REWYFK2m4yS/QP5kzfhkWcNqDI/akGT5 /LXmdmbc1s78+mOMXnA4vBY/+X1QatgxWUECkPDOiIwXJMxoBuyY8e7spLRXeyhtfh5aYaJc MO5bARX0c49v+KfZ80u9tG2rkKQvAt/ySo7OXsbDADFFRhlc8RLbb8e7bSctGbYZk9CYa0ya dW5+n3znDNJ6yW1skx9wTH+Y8VlSazRLk3XgXscNqBA2h56v3WS/R5dI++7AQxZxSQacQvfj 9eahq7ATdB4zMQ9MBHEwOvGD3DLlc55FYSDZvNX+mhnK7S0t1Nt2EtGUOmXb5ysMFGnbsce0 woKQ0sLPF1HWDAAf7tBCF8mpPIzU/ViAkupsJ6NYCD0tLFD8pvl0NYU2TjvyWh6ie3e5B/b3 8Daiyme+M92ivfoRQOFKmkPfeT14AI6OW1k7qFbmoIwMWWQdFWAl1CP9hNdF9gRN4rFB0Jy1 90BajZW2zOdVfqdurJZegCzAowZalLm4JEK2MklpPzipibnJqhLOmvJy587pF52KDdM/4rLy BBREIm7uRivnO5k/BY5qS+H/aqv97LC0PVaTsLXbDmTxTnJplUpdlYT9NGidM+x/ioS0iztO Cht7cT8V8jvvKZYvNpst8iqxuIaoV9V7aZ0wAQpkgDGXHmSzwtz6U8xNf/4e4sLn9KPlldSd kvo= In-Reply-To: X-Spamd-Bar: - X-Spamd-Result: default: False [-1.53 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; URI_COUNT_ODD(1.00)[13]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_SHORT(0.47)[0.468]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEFALL_USER(0.00)[grahamperrin]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from] X-Rspamd-Queue-Id: 4cHkpv6cmXz3s7t This is a multi-part message in MIME format. --------------3RmUcHoX5zRnne9FfT0PTr1P Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/09/2025 15:18, Lexi Winter wrote: > … the next "proper" build is currently in progress and should be > finished in the next day or two. I made a similar estimate "less than two days from now" more than two days ago :-| > i believe 15.0-ALPHA1 was delayed because of this. At the schedule does still show the /originally/ expected date (builds to begin tomorrow, Friday 5th September), however I'm fairly certain that the schedule will change. Colin wrote: "…  I'm not planning on creating stable/15 and starting 15.0-ALPHA1 builds until there's a full pkg repository for amd64 at least.". As things were seven hours ago: > A quick review of > >: > > *     95% complete after seventeen days > *     1725 packages remain > *     90 packages per hour, however the impulse (over the last ten > minutes) is *much lower, whenever I look* > *     x11/kde succeeded on Monday. > > 0.95 ÷ 17 ≈ 0.06, so, again, hopefully less than two days from now. > At the current impulse rate – high, relative to the lows that I have seen: 24 hours until completion (1350÷56). So I don't expect completion on the 5th. --------------3RmUcHoX5zRnne9FfT0PTr1P Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 04/09/2025 15:18, Lexi Winter wrote:

… the next "proper" build is currently in progress and should be finished in the next day or two.

I made a similar estimate "less than two days from now" more than two days ago :-|

i believe 15.0-ALPHA1 was delayed because of this.

At <https://www.freebsd.org/releases/15.0R/> the schedule does still show the originally expected date (builds to begin tomorrow, Friday 5th September), however I'm fairly certain that the schedule will change. Colin wrote: "…  I'm not planning on creating stable/15 and starting 15.0-ALPHA1 builds until there's a full pkg repository for amd64 at least.".

As things were seven hours ago: 

A quick review of <https://pkg-status.freebsd.org/beefy18/build.html?mastername=main-amd64-default&build=p9652f95ce8e4_sb45a181a74c>:

  •     95% complete after seventeen days
  •     1725 packages remain
  •     90 packages per hour, however the impulse (over the last ten minutes) is much lower, whenever I look
  •     x11/kde succeeded on Monday.

0.95 ÷ 17 ≈ 0.06, so, again, hopefully less than two days from now. 


<https://www.freshports.org/x11/kde/#packages>

At the current impulse rate – high, relative to the lows that I have seen: 24 hours until completion (1350÷56). So I don't expect completion on the 5th. 



--------------3RmUcHoX5zRnne9FfT0PTr1P-- From nobody Thu Sep 4 23:36:39 2025 X-Original-To: freebsd-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 4cHwqT6RKLz66jVp; Thu, 04 Sep 2025 23:36:53 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cHwqS3w8Cz42jQ; Thu, 04 Sep 2025 23:36:52 +0000 (UTC) (envelope-from obiwac@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=obiwac@gmail.com Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-6188b7550c0so2333613a12.2; Thu, 04 Sep 2025 16:36:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757029011; x=1757633811; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DkVGFSz986dkXCqhcQjg4EIHiVLfmX8o9u5PHTncILA=; b=EfhdC6Er8RqmVeRuJ3h9TzZfO1AFh+VhBagsGoVDBtkSPk7offvxsuk4TiOzBjJb29 iiFXSZkf2Mfusy+YJ5gzEQo20rq0MUlWNkGn+TDjctn/mVEtfZykXCjqsyVpAllLMFQU 8vN/QF7tzAa9wI4TApA1/1fTBYTMF2IGDp3t98uy9ikzstzME1OljMZiAwNvr2ld9+cs M8RmF0hZKVOtpHOR7uWU6QDgoUac+sL6QdXi1BX0VEKv5xm9eWE85dLrT3l7RjFa/UoU +UClyb+ajCkvEvrzfVSbt7dAlesPlCKFOsoY2TmAmPW9/ajtfoa3BJX2NfeZ/EogOlaK MfQQ== X-Forwarded-Encrypted: i=1; AJvYcCUtbHX6pzkXJHKgYnKa+XRMm61Xfx10dlZDaNcxs13ijcUxEdTa+9WzTn3yU2j0AbF280lTEkOzF/lB@freebsd.org X-Gm-Message-State: AOJu0YzZS1CUM2wm0ft9dBjvRt2xLanxM9ufhRDhGyXX2t3Q2QkCDWRq yFBwYwBzp0wuyUsAi0ab1g4t60+r1N/d5e7ad82M6SdcApn0/TEoB08Mxeufv949 X-Gm-Gg: ASbGncvl5cCXcifLF87kDoKfHn+ICdE4OYbJwv1T+UtptDpu74m7ikgNwregZDMxdKe q2ojxSURtnFS6C7dJIPXJQBHiBAFgV6KdsfPdQBSer8d3MpN+WKG3Xz5dZorInYohydMjvXg7DJ 9xbuI9AyV6XckHIeqiAO1Wx3OYDLO2/9xUS/273fGqESU1dN4SgHOQiThL0V25V/dDUsOPey5N7 KzPDENBEKjz6t7v7f7DfLUAyPDFbn9IFzi2GNojfqFZP87c5PLNtka66Am1AEZxLKfm/1E1WEHB zYaf6sQIOtM+D6IAaFidDhno3y1kA4FCUntg2KUJ+xNGfxAxX1/ak1j/v0PzfyCCXHgQBjVEJqd sPKG7GmAeH41S/nBk1OuM/RwOCvFHlp+CLIVLO3qRwM75tuWRaiQtPxufiK2205/aG0fL X-Google-Smtp-Source: AGHT+IGAAG5vjf+rJLi4hrV4RF0MhSIp3/VgrS2ny4fxrjng/QonMx8RkVAtRzTnqhtZ+OdooBoSPw== X-Received: by 2002:a05:6402:42c2:b0:61e:d636:5815 with SMTP id 4fb4d7f45d1cf-61ed6365ademr8268045a12.24.1757029010777; Thu, 04 Sep 2025 16:36:50 -0700 (PDT) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com. [209.85.218.53]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-61cfc22dfa1sm15020091a12.22.2025.09.04.16.36.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Sep 2025 16:36:50 -0700 (PDT) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-afcb7ace3baso294355966b.3; Thu, 04 Sep 2025 16:36:50 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXYFf/JVwPiD1tOlsB1gVvBBtUUf0cpH9wRyB4qnqmwAc5wH63PBM+PZV01F3rco5OD/P2HNh8m4wQ1@freebsd.org X-Received: by 2002:a17:907:7293:b0:b04:568b:8a42 with SMTP id a640c23a62f3a-b04568b947dmr1017296966b.29.1757029010247; Thu, 04 Sep 2025 16:36:50 -0700 (PDT) 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 From: obiwac Date: Fri, 5 Sep 2025 01:36:39 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXxCyWO_wjSOYygKYXCh1eDf1FlsBD4fDegjIQlqM5-gyRXTz3ZaOkUg2tI Message-ID: Subject: Fuse issue with attr caching expecting write lock To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Cc: alan.somers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.965]; NEURAL_HAM_MEDIUM(-0.86)[-0.862]; FORGED_SENDER(0.30)[obiwac@freebsd.org,obiwac@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[obiwac@freebsd.org,obiwac@gmail.com]; FREEFALL_USER(0.00)[obiwac]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-fs@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.45:from]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.45:from,209.85.218.53:received] X-Rspamd-Queue-Id: 4cHwqS3w8Cz42jQ Hi! When trying to access a large file with sshfs (on fuse), I get a kernel panic because fuse_internal_cache_attrs is asserting a write lock when it is sometimes being called from fuse_internal_do_getattr, which only asserts a read lock. To me (i.e. someone who has never touched VFS or fuse code) this code looks wrong, and fuse_internal_do_getattr should be acquiring a write lock around its call to fuse_internal_cache_attrs, but clearly it has been working just fine for a while now as this code hasn't changed super recently so I could be missing something. Thanks, Aymeric From nobody Fri Sep 5 00:14:43 2025 X-Original-To: freebsd-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 4cHxgN04yQz66lc0; Fri, 05 Sep 2025 00:14:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4cHxgM5SScz47gG; Fri, 05 Sep 2025 00:14:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5850Ehs9068289; Fri, 5 Sep 2025 03:14:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5850Ehs9068289 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5850EhhN068288; Fri, 5 Sep 2025 03:14:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Sep 2025 03:14:43 +0300 From: Konstantin Belousov To: obiwac Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, alan.somers@freebsd.org Subject: Re: Fuse issue with attr caching expecting write lock Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cHxgM5SScz47gG On Fri, Sep 05, 2025 at 01:36:39AM +0200, obiwac wrote: > Hi! > > When trying to access a large file with sshfs (on fuse), I get a > kernel panic because fuse_internal_cache_attrs is asserting a write > lock when it is sometimes being called from fuse_internal_do_getattr, > which only asserts a read lock. > > To me (i.e. someone who has never touched VFS or fuse code) this code > looks wrong, and fuse_internal_do_getattr should be acquiring a write > lock around its call to fuse_internal_cache_attrs, but clearly it has > been working just fine for a while now as this code hasn't changed > super recently so I could be missing something. It is only the assertions that were enabled recently. Mark merged DEBUG_VFS_LOCKS option into INVARIANTS. From nobody Fri Sep 5 03:58:17 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 4cJ2dF4BfSz671HM for ; Fri, 05 Sep 2025 03:58:25 +0000 (UTC) (envelope-from brian@sonicboom.org) Received: from sheehan.sonicboom.org (sheehan.sonicboom.org [50.190.118.82]) (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 4cJ2dD5qyMz3Vd8 for ; Fri, 05 Sep 2025 03:58:24 +0000 (UTC) (envelope-from brian@sonicboom.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brian@sonicboom.org designates 50.190.118.82 as permitted sender) smtp.mailfrom=brian@sonicboom.org Received: from [192.168.4.22] (unknown [50.190.118.81]) by sheehan.sonicboom.org (Postfix) with ESMTPSA id 4E2C73A0007F for ; Thu, 4 Sep 2025 21:58:16 -0600 (MDT) Message-ID: <45d0b773-6126-49fc-abe7-8421c4374358@sonicboom.org> Date: Thu, 4 Sep 2025 21:58:17 -0600 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 User-Agent: Mozilla Thunderbird Content-Language: en-US To: current@freebsd.org From: Brian Subject: buildworld problem Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.83 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.999]; NEURAL_SPAM_SHORT(0.97)[0.970]; NEURAL_SPAM_MEDIUM(0.96)[0.962]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip4:50.190.118.82]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[brian]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:50.128.0.0/9, country:US]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sonicboom.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cJ2dD5qyMz3Vd8 I am running current in a vm in proxmox and started seeing this today. ===> usr.bin/mail/tests (includes) --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/moused --- --- includes_subdir_usr.sbin/moused/moused --- ===> usr.sbin/moused/moused (includes) [Creating objdir /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused...] mkdir: /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: File exists make[5]: /usr/src/share/mk/auto.obj.mk:74: could not use /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: .OBJDIR=/usr/src/usr.sbin/moused/moused         in /usr/src/share/mk/sys.mk:105         in make[5] in directory "/usr/src/usr.sbin/moused/moused" make[5]: stopped making "includes" in /usr/src/usr.sbin/moused/moused make[4]: stopped making "includes" in /usr/src/usr.sbin/moused make[3]: stopped making "includes" in /usr/src/usr.sbin --- includes_subdir_usr.bin --- --- includes_subdir_usr.bin/locate --- --- includes_subdir_usr.bin/locate/locate --- ===> usr.bin/locate/locate (includes) --- includes_subdir_usr.bin/ldd32 --- make[3]: stopped making "includes" in /usr/src/usr.bin --- includes_subdir_usr.bin/mail --- make[4]: stopped making "includes" in /usr/src/usr.bin/mail make[3]: stopped making "includes" in /usr/src/usr.bin --- includes_subdir_usr.bin/locate --- make[4]: stopped making "includes" in /usr/src/usr.bin/locate make[3]: stopped making "includes" in /usr/src/usr.bin make[2]: stopped making "includes" in /usr/src --- includes_subdir_usr.sbin --- --- includes_subdir_usr.sbin/vidcontrol --- make[3]: stopped making "includes" in /usr/src/usr.sbin --- includes_subdir_usr.sbin/bsdinstall --- make[3]: stopped making "includes" in /usr/src/usr.sbin make[2]: stopped making "includes" in /usr/src        20.98 real        78.69 user        14.56 sys make[1]: stopped making "buildworld" in /usr/src make: stopped making "buildworld" in /usr/src From nobody Fri Sep 5 04:03:16 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 4cJ2kz6324z671fn for ; Fri, 05 Sep 2025 04:03:23 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJ2kz40fjz3WXB for ; Fri, 05 Sep 2025 04:03:23 +0000 (UTC) (envelope-from ianfreislich@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e96ff16fea1so2006751276.0 for ; Thu, 04 Sep 2025 21:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757044997; x=1757649797; darn=freebsd.org; h=mime-version:subject:user-agent:references:in-reply-to:message-id :date:to:from:from:to:cc:subject:date:message-id:reply-to; bh=luP4Ue7KC/MQ5UYCiRlJ4ZKDXZ1D/QAPmDHohiulrU8=; b=k04K0gwvumaVyX3jZhjpmF8vG8ONg14HOYsaSJpc2JnmGwFlpHDsXBbnhVRkRVfeOW GYu5FB+j18VXlVwL8VKcPfEZNiT8lD6tUwgBi/D7A+Gpi5SymTv+ojs73sCbAzCJLs5R 94fAFr+8IuhjM97YpPoL6NgaWMgkjJtcpYFj86wAD/fzJoS/yZcYm+2kKy/Bmy8/HkUw QT6IW3DBsBpWAY7AWg01iDXtz+b+BYxyayyQQ9Xf3z5DDlWmFTDdsvmlT26kRqXYohDO IGiL/aGIl+RUtt7HstM8EjCgl7ERwQpwgeNyHnQZCufoz7CAyZ4ES6RoKhaBgWSseF25 jfLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757044997; x=1757649797; h=mime-version:subject:user-agent:references:in-reply-to:message-id :date:to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=luP4Ue7KC/MQ5UYCiRlJ4ZKDXZ1D/QAPmDHohiulrU8=; b=QQYfeII8M6MEho08/Wbj93TizxTrzUozrNWTlABv1YBuiW9Lyas4sQfPQDX+IExB6n 9oD9RdlRCYtEmM/p9v4OqaGRXrakAI2PDvtL6+N2tDVNEesXDgVJU9s3feMu3BGSvZaG YTFu/hzFsvxjSUTojQZq/njeDWIEuIMCE2zm20fNnev7VRULwgDdsSMxD1+45yVdbRBu wU0jUfWO0gabWH1Vek4lDlKvLZfr+5iN30zPcetaYA8s/PFQA070roiKIDaNckDWDHkH TPPlACX/cL+ZyGtie8pFbonyBqBPGHvltW2Nlixz09NhaBBbBX766m7n5UAmh9kyvBxM FfjQ== X-Forwarded-Encrypted: i=1; AJvYcCUCmvc4MthF+QVvZzXSPp77tW0c14Yh7C5UV2GpPqmqZK5xzBcaNQH5wrkjHEG0WiIXlqnFsJqZ@freebsd.org X-Gm-Message-State: AOJu0YyC2ejlSMzcLE3JNpLShPn0d25NGPSdlwztgvlzMHOX8UZ5tMb7 xwiCMvUIVPyv3G0gJege43uYRUMKp+yF0hWgaWHxLQxKBgoFWaHAiYAb X-Gm-Gg: ASbGncuBv/gHRpVdGBbVGMeC9Y0CBpFuuzuDwEHN+VN0grQLdXNEBiB+o5a/Lj21UrM plRgo2hCr5IHzSgMogpxgMIDuTzZbJNo3rwrS6j+eVqJOYJckvhsCO2rIMkZ1vqoaba2CbYj+Ey eGL9sq/jz4K5eigl3d4dzPTZhZNOWOJ1NZf22Tkv3pwyiPEXDW9L9cNRg6VH1RNO65NcwdPWpa8 A4wZ/gur8BO2cNypoVIwrBhOb2yx8CDf7sC9UexOa7ce8OtYzPx1jZjaUsneWimYj4vxwjN3H9J VGW94tv6tT+UczA4zcfQs5Kue3ZH2yQWlxYenC12Gfky9db4ZCfgzdQqixwCg2RYWSYutDV3dOj q2ZT8JOiRm1ei84majSRqWtWtehoF6Pk9zP6XgilvO3DxIz8u6BxOjzdeybtOaSPzUEkqNhnSRw lYuP0= X-Google-Smtp-Source: AGHT+IF+53cWc2kSzcMrJ7AxtGv20Js2kH4wSISEgLwDd4L48cmsbHfUomMv+1pAY2lssqCjJU1d0w== X-Received: by 2002:a53:cb01:0:b0:608:9a13:8e4c with SMTP id 956f58d0204a3-6089a139432mr3460873d50.29.1757044997306; Thu, 04 Sep 2025 21:03:17 -0700 (PDT) Received: from [10.0.0.109] (107-128-20-168.lightspeed.tukrga.sbcglobal.net. [107.128.20.168]) by smtp.gmail.com with ESMTPSA id 00721157ae682-723a837a8f9sm26365327b3.33.2025.09.04.21.03.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Sep 2025 21:03:16 -0700 (PDT) From: Ian Freislich To: Brian , Date: Fri, 05 Sep 2025 00:03:16 -0400 Message-ID: <199180af7a0.28c3.64e08aff09ba5a21b2fc9010d26a90e5@gmail.com> In-Reply-To: <45d0b773-6126-49fc-abe7-8421c4374358@sonicboom.org> References: <45d0b773-6126-49fc-abe7-8421c4374358@sonicboom.org> User-Agent: AquaMail/1.55.2 (build: 105502562) Subject: Re: buildworld problem 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/alternative; boundary="199180afb5416f828c334eaf8c" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cJ2kz40fjz3WXB This is a multi-part message in MIME format. --199180afb5416f828c334eaf8c Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit On September 4, 2025 23:58:39 Brian wrote: > I am running current in a vm in proxmox and started seeing this today. > > ===> usr.bin/mail/tests (includes) > --- includes_subdir_usr.sbin --- > --- includes_subdir_usr.sbin/moused --- > --- includes_subdir_usr.sbin/moused/moused --- > ===> usr.sbin/moused/moused (includes) > [Creating objdir /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused...] > mkdir: /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: File exists > make[5]: /usr/src/share/mk/auto.obj.mk:74: could not use > /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: > .OBJDIR=/usr/src/usr.sbin/moused/moused > in /usr/src/share/mk/sys.mk:105 > in make[5] in directory "/usr/src/usr.sbin/moused/moused" > > make[5]: stopped making "includes" in /usr/src/usr.sbin/moused/moused > > make[4]: stopped making "includes" in /usr/src/usr.sbin/moused > > make[3]: stopped making "includes" in /usr/src/usr.sbin > --- includes_subdir_usr.bin --- > --- includes_subdir_usr.bin/locate --- > --- includes_subdir_usr.bin/locate/locate --- > ===> usr.bin/locate/locate (includes) > --- includes_subdir_usr.bin/ldd32 --- > > make[3]: stopped making "includes" in /usr/src/usr.bin > --- includes_subdir_usr.bin/mail --- > > make[4]: stopped making "includes" in /usr/src/usr.bin/mail > > make[3]: stopped making "includes" in /usr/src/usr.bin > --- includes_subdir_usr.bin/locate --- > > make[4]: stopped making "includes" in /usr/src/usr.bin/locate > > make[3]: stopped making "includes" in /usr/src/usr.bin > > make[2]: stopped making "includes" in /usr/src > --- includes_subdir_usr.sbin --- > --- includes_subdir_usr.sbin/vidcontrol --- > > make[3]: stopped making "includes" in /usr/src/usr.sbin > --- includes_subdir_usr.sbin/bsdinstall --- > > make[3]: stopped making "includes" in /usr/src/usr.sbin > > make[2]: stopped making "includes" in /usr/src > 20.98 real 78.69 user 14.56 sys > > make[1]: stopped making "buildworld" in /usr/src > > make: stopped making "buildworld" in /usr/src This bit me too. It's trying to make a directory but a file of that name already exists. Just rm /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused Ian --199180afb5416f828c334eaf8c Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On September 4, 2025 23:= 58:39 Brian <brian@sonicboom.org> wrote:

I am running current in a vm in proxmox and started seein= g this today.

=3D=3D=3D> usr.bin/mail/tests (includes)
--- includes_subdir_usr.sbin ---
--- includes_subdir_usr.sbin/moused ---
--- includes_subdir_usr.sbin/moused/moused ---
=3D=3D=3D> usr.sbin/moused/moused (includes)
[Creating objdir /usr/obj/usr/src/amd64.amd64/usr.sbin/mo= used/moused...]
mkdir: /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/mouse= d: File exists
make[5]: /usr/src/share/mk/auto.obj.mk:74: could not use&= nbsp;
/usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: = ;
.OBJDIR=3D/usr/src/usr.sbin/moused/moused
         in /usr/src/share/mk/sy= s.mk:105
         in make[5] in directory= "/usr/src/usr.sbin/moused/moused"

make[5]: stopped making "includes" in /usr/src/usr.sbin/m= oused/moused

make[4]: stopped making "includes" in /usr/src/usr.sbin/m= oused

make[3]: stopped making "includes" in /usr/src/usr.sbin
--- includes_subdir_usr.bin ---
--- includes_subdir_usr.bin/locate ---
--- includes_subdir_usr.bin/locate/locate ---
=3D=3D=3D> usr.bin/locate/locate (includes)
--- includes_subdir_usr.bin/ldd32 ---

make[3]: stopped making "includes" in /usr/src/usr.bin
--- includes_subdir_usr.bin/mail ---

make[4]: stopped making "includes" in /usr/src/usr.bin/ma= il

make[3]: stopped making "includes" in /usr/src/usr.bin
--- includes_subdir_usr.bin/locate ---

make[4]: stopped making "includes" in /usr/src/usr.bin/lo= cate

make[3]: stopped making "includes" in /usr/src/usr.bin

make[2]: stopped making "includes" in /usr/src
--- includes_subdir_usr.sbin ---
--- includes_subdir_usr.sbin/vidcontrol ---

make[3]: stopped making "includes" in /usr/src/usr.sbin
--- includes_subdir_usr.sbin/bsdinstall ---

make[3]: stopped making "includes" in /usr/src/usr.sbin

make[2]: stopped making "includes" in /usr/src
        20.98 real    =     78.69 user        14.56 sys

make[1]: stopped making "buildworld" in /usr/src

make: stopped making "buildworld" in /usr/src

This bit me too. It's t= rying to make a directory but a file of that name already exists. Just rm /= usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused
<= br>Ian
--199180afb5416f828c334eaf8c-- From nobody Fri Sep 5 13:30:49 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 4cJHLD4LKnz67Zcq for ; Fri, 05 Sep 2025 13:31:16 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (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 4cJHLC4ZSCz3d1h for ; Fri, 05 Sep 2025 13:31:15 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=VN+DeSbR; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at Date: Fri, 05 Sep 2025 15:30:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1757079067; bh=1BtKAmXMIguGhD6HzZr8LjV64ikaZczWRp+9MxJlN94=; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; b=VN+DeSbRGGFBQdrNWJq9zMW8HSaIIn8wQuCDzety3xm7bUpg93TwxD1hso8++0ZNM I9JigMXzRuDp2JaHiuIiGVOIjCU8KgHGLS+6T7JOsXVuFLvke965duaUuQKqkWme6L 1So4T5zxEkAXsdo9+kXour1M6dGgyj3oM6X1D4nbSF/f76r4pyCp0hT5JmPBl0gkxc XojDzu5hEjtvAFATfOTIQP+HggllXMYPVW+pV6ZlcdtFzCwU4Jov4QFIab+B/X/tuA NSbRX9UDM7kKO/4SCkypbQ5m0w3vMhJyDYensXoP3WjdUd3BQ1MK0wjKzN3J7MzfDF Yqgxc7giTVYJQ== Message-ID: <877byd81rq.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: current@freebsd.org Subject: Re: pkg broken? In-Reply-To: <2f4bacf4-379c-4ed0-8315-384417283e7d@gmail.com> References: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> <2f4bacf4-379c-4ed0-8315-384417283e7d@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/31.0 Mule/6.0 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 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: - X-Spamd-Result: default: False [-1.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; DMARC_NA(0.00)[gojira.at]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gojira.at:+] X-Rspamd-Queue-Id: 4cJHLC4ZSCz3d1h On Thu, 04 Sep 2025 01:19:48 +0200, Graham Perrin wrote: >=20 > On 03/09/2025 02:20, Dan Mahoney (Ports) wrote: > > Hey all, > >=20 > > After an update today to what looks like snap20250828153719.pkg, it wou= ld seem pkg doesn=E2=80=99t want to play ball. > >=20 > > root@poudriere-pkb:/etc/pkg # pkg update > > Updating FreeBSD-ports repository catalogue... > > FreeBSD-ports repository is up to date. > > Updating FreeBSD-ports-kmods repository catalogue... > > FreeBSD-ports-kmods repository is up to date. > > Updating FreeBSD-base repository catalogue... > > FreeBSD-base repository is up to date. > > Updating FreeBSD repository catalogue... > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:am= d64/latest/meta.conf -- pkg+:// implies SRV mirror type > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:am= d64/latest/meta.txz -- pkg+:// implies SRV mirror type > > repository FreeBSD has no meta file, using default settings > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:am= d64/latest/data.pkg -- pkg+:// implies SRV mirror type > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:am= d64/latest/data.tzst -- pkg+:// implies SRV mirror type > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:am= d64/latest/packagesite.pkg -- pkg+:// implies SRV mirror type > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:am= d64/latest/packagesite.tzst -- pkg+:// implies SRV mirror type > > Unable to update repository FreeBSD > > Error updating repositories! > > root@poudriere-pkb:/etc/pkg # uname -a > > FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE m= ain-n280004-00c9ebbbc653 GENERIC amd64 > > root@poudriere-pkb:/etc/pkg # freebsd-version > > 15.0-PRERELEASE > >=20 > >=20 > > =E2=80=A6 >=20 >=20 > Which mirror? >=20 > One comparable report, from a user of=C2=A0RELEASE with=C2=A0the Chicago = mirror: >=20 > Same issue after updating stable/14 to stable/15. I don't use pkgbase. pkg is using the mirror in Sj=C3=B6bo, Sverige (pkg0.sjb.freebsd.org). From nobody Fri Sep 5 13:40:45 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 4cJHYC6Slwz67bgY for ; Fri, 05 Sep 2025 13:40:47 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (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 4cJHYC2t2hz3fbJ for ; Fri, 05 Sep 2025 13:40:47 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=M3bqoUYE; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at Date: Fri, 5 Sep 2025 15:40:45 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1757079645; bh=UDG54Aa7F/nMtJupLO2yPN/rEFJH49dmbweag7xxq0I=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=M3bqoUYEwVsyA9XN/Rf2bWYvny/dSl55k94ZvEK2aSpqrTtFWNmaMRnwZ5hihvCnL xlRHc3cQBVYNFysNbCrkZIQQ61YRQvOryuzDzn2ITmMfshNQ98v0QTmPdiwF1r8LJe kqRtE2nwvygHfWiGDWIzanuboyE5JimpLtwtW7eDazgSc0MYzWY0hwhTYJETSgWXoZ QT7Cr6TejFpns42T9mgTD1dwnXiMYF3oKKqdszCW7GrEJPjr7a+9jSA8xle+ppliao uIGCID4y/vgoY5cP0mCxLkFfg+YBy8lmEzmAPMXB5SwOdJahePYRUULXhPk1bL1tUE B9yJnjUJA/Cvg== From: "Herbert J. Skuhra" To: current@freebsd.org Subject: Re: pkg broken? Message-ID: References: <8E1757D0-28DD-4E0D-B156-04F97ED1172B@gushi.org> <2f4bacf4-379c-4ed0-8315-384417283e7d@gmail.com> <877byd81rq.wl-herbert@gojira.at> 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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877byd81rq.wl-herbert@gojira.at> X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[gojira.at]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gojira.at:+] X-Rspamd-Queue-Id: 4cJHYC2t2hz3fbJ On Fri, Sep 05, 2025 at 03:30:49PM +0200, Herbert J. Skuhra wrote: > On Thu, 04 Sep 2025 01:19:48 +0200, Graham Perrin wrote: > > > > On 03/09/2025 02:20, Dan Mahoney (Ports) wrote: > > > Hey all, > > > > > > After an update today to what looks like snap20250828153719.pkg, it would seem pkg doesn’t want to play ball. > > > > > > root@poudriere-pkb:/etc/pkg # pkg update > > > Updating FreeBSD-ports repository catalogue... > > > FreeBSD-ports repository is up to date. > > > Updating FreeBSD-ports-kmods repository catalogue... > > > FreeBSD-ports-kmods repository is up to date. > > > Updating FreeBSD-base repository catalogue... > > > FreeBSD-base repository is up to date. > > > Updating FreeBSD repository catalogue... > > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf -- pkg+:// implies SRV mirror type > > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.txz -- pkg+:// implies SRV mirror type > > > repository FreeBSD has no meta file, using default settings > > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.pkg -- pkg+:// implies SRV mirror type > > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/data.tzst -- pkg+:// implies SRV mirror type > > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.pkg -- pkg+:// implies SRV mirror type > > > pkg: packagesite URL error for pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/packagesite.tzst -- pkg+:// implies SRV mirror type > > > Unable to update repository FreeBSD > > > Error updating repositories! > > > root@poudriere-pkb:/etc/pkg # uname -a > > > FreeBSD poudriere-pkb.isc.org 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE main-n280004-00c9ebbbc653 GENERIC amd64 > > > root@poudriere-pkb:/etc/pkg # freebsd-version > > > 15.0-PRERELEASE > > > > > > > > > … > > > > > > Which mirror? > > > > One comparable report, from a user of RELEASE with the Chicago mirror: > > > > > > Same issue after updating stable/14 to stable/15. I don't use pkgbase. > pkg is using the mirror in Sjöbo, Sverige (pkg0.sjb.freebsd.org). Sorry, please ignore. Removing the file /usr/local/etc/pkg/repos/FreeBSD.conf resolved the issue. Running 'pkg epositories' helped. :-) From nobody Fri Sep 5 14:26:25 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 4cJJZC3c1mz67dZ0 for ; Fri, 05 Sep 2025 14:26:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJJZC1QtBz3lfm for ; Fri, 05 Sep 2025 14:26:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-32326793a85so1605555a91.1 for ; Fri, 05 Sep 2025 07:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1757082397; x=1757687197; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MN8JSZDmzyZY8lGBn+MMIwaoxjefAVHNAOz+wznNYNo=; b=BR80J25Qv8KEygmrLz7uelQ97g3HaYsWIJkkpnNMV79SC2Qk0EQGxVA4rY3uIapigy Alk+PR9aguvjMhdUiXadJ9/5uMH4goFh8Gyf+27C9QgWpeKosgFL43juCQEbZ+6PF+VV aPJ6SN48Y/TYuPxtehDYe8ueaBIxgWN9izCKb6OQE7CUB0pVR4bCF+BttzvXXXzNFcPe c95zs6s4LVdOiJp8XZXJkbBWr7TbCDckHde8MEHXT+jGos6bfpyglRx0e+z8X8DvL5Nh vNCbmckHkkQ7eiX1S50FU9ove5beQ79+y2plGRMDxUHZnArNJvCHgEcd1c7ibY7UyfX7 OgJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757082397; x=1757687197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MN8JSZDmzyZY8lGBn+MMIwaoxjefAVHNAOz+wznNYNo=; b=PNJu35WnvPNFm/IaVQPIIAhY6/qjEfUWyDZJDR7bER2m+YvcYwc8Lk0xWHU+6ajTGh 5OaFSHlxEfH++11zth3eiTvqPPgiftAaAACRo1oDz/ybgGF71i00lQoKd8DQI7XfXBI4 ynsXojDjPBbb2GBG3L/N9Q3n4mSWBJthIhcQIZpVe9Y6r08AXc+uo7hW9bUZKnD8uBrC 01sVQmO3fyjOk/IYc1y3JXWTBCto0JcdAkjXOv2DiMgpgPqa6p5gBiUp4aNIqfa77mYZ Pl/4csXYoSbdYxf38MZEqSSnBpmCtmSvjiwpABllxfcv+ES0mtTKD5CFOr0yIhnPzLnA A3jw== X-Forwarded-Encrypted: i=1; AJvYcCVTWNzaAa3HC87cEOeJx67dflianLP36YO88Qk5n96b56y6SzC089pWRfVmxchhcoFyfcuFM5q4@freebsd.org X-Gm-Message-State: AOJu0YwK8GO4W4SEiEIJplZ8WL8lQd7svDn2ATTPlGLm3PZ9bUBDdKSX giU6UdgjrV8u4+nrd+TVaio0iLUmgJasPj6cmTwaw97q/yHHm1fuoMxA1QK0zoEL/VChx2buYbU thq/48qPgkewdnkgrBVspmYUM7ye+DiW7wR9tssk0CIvfpHOEOhIuAMM= X-Gm-Gg: ASbGncuycXBlmeuCF8wjQtn5mFpQFoedfn2twzHCvKGKaWpritADbXupYClxdoSa56e OmI6g6ubC/31j2JqBUxRVjHbLPu/EiFkkGu47ys3AdoN2wtgHzYDKc7uuSpe867yR4W9aCjpsrK FJXzSkxPLiYQfXQvtkkofbkiOitZXleC8Kc+NgComBC2fs8sKUoQjhvpko2U6IqWIxS4fto1GKW yBnEqwSNog41NI2RsE/JY1t57VY5vyYMJpwNsU= X-Google-Smtp-Source: AGHT+IFXXGYRb5T/82dZp+AB4cE9v3N5MYl9zRK2nlG7OF31QBBVBw2GCNmyXGN6bvppPsYs4sQG3zGtMVLfczmjyvM= X-Received: by 2002:a17:90b:5185:b0:32b:be68:bb30 with SMTP id 98e67ed59e1d1-32bbe68bc57mr4436032a91.37.1757082396709; Fri, 05 Sep 2025 07:26:36 -0700 (PDT) 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 References: <45d0b773-6126-49fc-abe7-8421c4374358@sonicboom.org> <199180af7a0.28c3.64e08aff09ba5a21b2fc9010d26a90e5@gmail.com> In-Reply-To: <199180af7a0.28c3.64e08aff09ba5a21b2fc9010d26a90e5@gmail.com> From: Warner Losh Date: Fri, 5 Sep 2025 08:26:25 -0600 X-Gm-Features: Ac12FXzxpK7SPfTlJ8VYaqqcT6n4vRChvCuRar13rkml6t4faqOeBmkO7zIeFrM Message-ID: Subject: Re: buildworld problem To: Ian Freislich Cc: Brian , current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000018e640063e0ea0bd" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cJJZC1QtBz3lfm --00000000000018e640063e0ea0bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I fixed this last night on main and stable/15. You are correct: make won't mkdir on stop of a regular file. Removing that file will allow the build to succeed. You can do that manually w/o updating, or you can update where I've hung the rm off the usual depend cleanup we do. Warner Warner On Thu, Sep 4, 2025 at 10:03=E2=80=AFPM Ian Freislich wrote: > On September 4, 2025 23:58:39 Brian wrote: > > I am running current in a vm in proxmox and started seeing this today. >> >> =3D=3D=3D> usr.bin/mail/tests (includes) >> --- includes_subdir_usr.sbin --- >> --- includes_subdir_usr.sbin/moused --- >> --- includes_subdir_usr.sbin/moused/moused --- >> =3D=3D=3D> usr.sbin/moused/moused (includes) >> [Creating objdir /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused...] >> mkdir: /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: File exists >> make[5]: /usr/src/share/mk/auto.obj.mk:74: could not use >> /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused: >> .OBJDIR=3D/usr/src/usr.sbin/moused/moused >> in /usr/src/share/mk/sys.mk:105 >> in make[5] in directory "/usr/src/usr.sbin/moused/moused" >> >> make[5]: stopped making "includes" in /usr/src/usr.sbin/moused/moused >> >> make[4]: stopped making "includes" in /usr/src/usr.sbin/moused >> >> make[3]: stopped making "includes" in /usr/src/usr.sbin >> --- includes_subdir_usr.bin --- >> --- includes_subdir_usr.bin/locate --- >> --- includes_subdir_usr.bin/locate/locate --- >> =3D=3D=3D> usr.bin/locate/locate (includes) >> --- includes_subdir_usr.bin/ldd32 --- >> >> make[3]: stopped making "includes" in /usr/src/usr.bin >> --- includes_subdir_usr.bin/mail --- >> >> make[4]: stopped making "includes" in /usr/src/usr.bin/mail >> >> make[3]: stopped making "includes" in /usr/src/usr.bin >> --- includes_subdir_usr.bin/locate --- >> >> make[4]: stopped making "includes" in /usr/src/usr.bin/locate >> >> make[3]: stopped making "includes" in /usr/src/usr.bin >> >> make[2]: stopped making "includes" in /usr/src >> --- includes_subdir_usr.sbin --- >> --- includes_subdir_usr.sbin/vidcontrol --- >> >> make[3]: stopped making "includes" in /usr/src/usr.sbin >> --- includes_subdir_usr.sbin/bsdinstall --- >> >> make[3]: stopped making "includes" in /usr/src/usr.sbin >> >> make[2]: stopped making "includes" in /usr/src >> 20.98 real 78.69 user 14.56 sys >> >> make[1]: stopped making "buildworld" in /usr/src >> >> make: stopped making "buildworld" in /usr/src >> > > This bit me too. It's trying to make a directory but a file of that name > already exists. Just rm /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/mous= ed > > Ian > --00000000000018e640063e0ea0bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I fixed this last night on main and stable/15. You are cor= rect: make won't mkdir on stop of a regular file. Removing that file wi= ll allow the build to succeed. You can do that manually w/o updating, or yo= u=C2=A0can update where I've hung the rm off the usual depend cleanup w= e do.

Warner

Warner

On Thu, Sep 4, 2025 at 10:03=E2=80=AFPM Ian Freislich &= lt;ianfreislich@gmail.com>= wrote:
On September 4, 2025 23:58= :39 Brian <bria= n@sonicboom.org> wrote:

I am running current in a vm in proxmox and started seein= g this today.

=3D=3D=3D> usr.bin/mail/tests (includes)
--- includes_subdir_usr.sbin ---
--- includes_subdir_usr.sbin/moused ---
--- includes_subdir_usr.sbin/moused/moused ---
=3D=3D=3D> usr.sbin/moused/moused (includes)
[Creating objdir /usr/obj/usr/src/amd64.amd64/usr.sbin/mo= used/moused...]
mkdir: /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/mouse= d: File exists
make[5]: /usr/src/share/mk/auto.obj.mk:74: could not use=C2=A0
/usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused:=C2= =A0
.OBJDIR=3D/usr/src/usr.sbin/moused/moused
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 in /usr/src/share/mk/sys.mk:105
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 in make[5] in directory= "/usr/src/usr.sbin/moused/moused"

make[5]: stopped making "includes" in /usr/src/= usr.sbin/moused/moused

make[4]: stopped making "includes" in /usr/src/= usr.sbin/moused

make[3]: stopped making "includes" in /usr/src/= usr.sbin
--- includes_subdir_usr.bin ---
--- includes_subdir_usr.bin/locate ---
--- includes_subdir_usr.bin/locate/locate ---
=3D=3D=3D> usr.bin/locate/locate (includes)
--- includes_subdir_usr.bin/ldd32 ---

make[3]: stopped making "includes" in /usr/src/= usr.bin
--- includes_subdir_usr.bin/mail ---

make[4]: stopped making "includes" in /usr/src/= usr.bin/mail

make[3]: stopped making "includes" in /usr/src/= usr.bin
--- includes_subdir_usr.bin/locate ---

make[4]: stopped making "includes" in /usr/src/= usr.bin/locate

make[3]: stopped making "includes" in /usr/src/= usr.bin

make[2]: stopped making "includes" in /usr/src<= /div>
--- includes_subdir_usr.sbin ---
--- includes_subdir_usr.sbin/vidcontrol ---

make[3]: stopped making "includes" in /usr/src/= usr.sbin
--- includes_subdir_usr.sbin/bsdinstall ---

make[3]: stopped making "includes" in /usr/src/= usr.sbin

make[2]: stopped making "includes" in /usr/src<= /div>
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A020.98 real=C2=A0 =C2=A0 = =C2=A0 =C2=A0 78.69 user=C2=A0 =C2=A0 =C2=A0 =C2=A0 14.56 sys

make[1]: stopped making "buildworld" in /usr/sr= c

make: stopped making "buildworld" in /usr/src

This bit me too. It'= ;s trying to make a directory but a file of that name already exists. Just = rm /usr/obj/usr/src/amd64.amd64/usr.sbin/moused/moused

Ian
--00000000000018e640063e0ea0bd-- From nobody Fri Sep 5 17:17:34 2025 X-Original-To: freebsd-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 4cJPZX1TPbz65wbF for ; Fri, 05 Sep 2025 18:12:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJPZW35cHz4KWh for ; Fri, 05 Sep 2025 18:12:19 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror); spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.32 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id uUPDuzNnd9JM2uav4ufMTu; Fri, 05 Sep 2025 18:12:18 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id uav3u3kgNWbOauav4ufbr6; Fri, 05 Sep 2025 18:12:18 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=68bb2802 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=IkcTkHD0fZMA:10 a=yJojWOMRYYMA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=JAf30KXuAAAA:8 a=YxBL1-UpAAAA:8 a=ekjOxkQkDP927x0WAJsA:9 a=QEXdDO2ut3YA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=GEL62FyrTCmHtEug2d3R:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from ehlo.thunderbird.net (unknown [209.52.88.4]) by spqr.komquats.com (Postfix) with ESMTPSA id CC6FB1BA; Fri, 05 Sep 2025 11:12:16 -0700 (PDT) Date: Fri, 05 Sep 2025 10:17:34 -0700 From: Cy Schubert To: freebsd-current@freebsd.org Subject: Re: Panic after kldload i915kms at main-n280058-e7a04a110724 In-Reply-To: References: <6D97C74E-EDBF-47A9-B519-0D1A945BBA52@FreeBSD.org> <64c7bb13-ce6a-49a5-a7a1-952ce2f35a9e@FreeBSD.org> Message-ID: 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfNs2OWTvSo/VVTFxN9Jys6rVl2fl/D5c1Gl/yRwp8EhvbxMlJcoszmPPhhVdtGt0wgw0Zl5oHERkTiwCWBkUcuXHj/hyTxRSD7G5LvcXWCfWQTZXXSGH Gkc7hdyx8w8oke//yUWcJbt3CYHU8ArqnnL+8Ln3Uuzo2CmjyoCviG+YvxLBLK9hPp3HOdUb7DMGx+hi9tMEkZ8hAMCtnUmQWlo= X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.76 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.96)[-0.956]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.32:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cJPZW35cHz4KWh The i915kms and iwlwifi panics on my HP 840 are resolved but the amdgpu pan= ic on the Framework 13 is still occurring=2E I'll try looking into this som= etime this weekend=2E=20 --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Tiny keyboard in use=2E On September 4, 2025 6:39:19=E2=80=AFa=2Em=2E PDT, David Wolfskill wrote: >On Thu, Sep 04, 2025 at 08:29:34AM -0500, Kyle Evans wrote: >> On 9/4/25 07:52, David Wolfskill wrote: >> > On Thu, Sep 04, 2025 at 02:39:45PM +0200, Juraj Lutter wrote: >> > > =2E=2E=2E >> > > Out of curiosity, does the problem go away when you revert commit a= 2f08d0ddc29e4da15f614bdb6a5072b3fd6332c ? >> > >=20 >> > > It is the most recent one that touched pseudofs subsystem=2E >> > > =2E=2E=2E=2E >> >=20 >> > Thanks; I will try it & report=2E > >Just finished rebuild after local reversion of >a2f08d0ddc29e4da15f614bdb6a5072b3fd6332c (main-n280055-a2f08d0ddc29); >panic looks unchanged=2E > >> > In the mean time, I have screenshots for the panic up at >> > https://www=2Ecatwhisker=2Eorg/~david/FreeBSD/head/n280058/ >> =2E=2E=2E >> Hi, >>=20 >> Sorry for the hassle, this is reverted in d3462294c1f02ca20cc1869d618bd= e57559f5914=2E I had smoke-tested >> all in-tree pseudofs, but missed that lindebugfs is mostly initialized = in drivers that populated it >> rather than in lindebugfs itself=2E I'll add it to my list to circle b= ack to later=2E >>=20 >> Thanks, >>=20 >> Kyle Evans > >Ah -- that's reverting 65059dd2b6f94e570acc645be82b8ea056316459 >(main-n280054-65059dd2b6f9)=2E OK=2E > > >Thanks for the fix! > >Peace, >david From nobody Fri Sep 5 21:11:46 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 4cJTYf0X36z66Ppc for ; Fri, 05 Sep 2025 21:11:50 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJTYd2p1mz3f2v for ; Fri, 05 Sep 2025 21:11:49 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b=ltAe2YEH; dmarc=pass (policy=none) header.from=zabbadoz.net; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id D65D0A64806 for ; Fri, 05 Sep 2025 21:11:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1757106699; bh=dW0aMGBHgec2OFJRG9fF2Ilw+m8ZYfWS9XmnMgAAtgI=; h=Date:From:To:Subject; b=ltAe2YEHjRKWzxDNiVEqXDYepV3qy2t/3L141QXg5FJvKR1ng4DTu3+2vtQ5H8dl7 Rf+X+VTnVstFCU7UKsfdX6tTIil0epRSCXvqAssef4d+9/BvMRPFe2H0uC1UpGJPGC leutt5Lr9fFs7PQUypJ7BlL2RYkFhrvWTCYCi8L5uppfZhCsmti1ppVpRoNvHROd2Y hjUTsi6J7jKS7+cs2RSwkfhXRdTsB97mXyMGC3akzYGJx2XLdBNuToMMtFniabtSmt /FyBjLMTUy60ZQaI7rhz1NFgTdALZqzul9RhhjCU6fPsfUrzPor07znFa8++OvEcC8 /dTNeRUGwr75OkO0p26jAS3+I7sWVpzR29NEx17hShiIe0GtG/lWGe2qEpdNkPUbiM q3Ex+qWsrLC/akuOIFiOlRv73a+Ux7DrevoWwxy+xQKpOO2TMe2axhXnhXLqFiQnDN 0CEvxo/ak8MFjANTCHGlYyU2e9jXJ9gxEcby3z1AGCP1vOr+eUxGDPuX1jYamvAWr7 Gjb2WJSrCS/rZMBLhjH10FPjCImR6bD1fMQtn9nHqGpFQBXZgE1mGovPwTWnM8s5Gg 7fCkK7enJ2MoLN43FUWgFKv/ynjh+QFpepKQ9X6RyKoVKrAVFdWiizG/lqvMo3y6jn 1UbBJopW+DhevQ0ripcJ+8sM= 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 9887F2D029E4 for ; Fri, 5 Sep 2025 21:11:47 +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 kRf1G1cfNJuN for ; Fri, 5 Sep 2025 21:11:46 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (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 A1C512D029D8 for ; Fri, 5 Sep 2025 21:11:46 +0000 (UTC) Date: Fri, 5 Sep 2025 21:11:46 +0000 (UTC) From: "Bjoern A. Zeeb" To: current@freebsd.org Subject: -Wunused-function rising on main again Message-ID: <8328954n-nq87-23p2-3no1-24394nn1n395@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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: text/plain; format=flowed; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.910]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19:c]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] X-Rspamd-Queue-Id: 4cJTYd2p1mz3f2v Hi, for a long time we were down to 1 zfs warning, now we accumulate a lot more. Can people please pay attention. make -s is your friend: 2 -------------------------------------------------------------- 3 >>> Kernel build for LINT started on Fri Sep 5 20:14:36 UTC 2025 4 -------------------------------------------------------------- 5 ===> LINT 6 0.12 real 0.04 user 0.09 sys 7 8 -------------------------------------------------------------- 9 >>> stage 2.3: build tools 10 -------------------------------------------------------------- 11 0.33 real 0.23 user 0.10 sys 12 13 -------------------------------------------------------------- 14 >>> stage 3.1: building everything 15 -------------------------------------------------------------- 16 /tank/users/bz/git/FreeBSD/freebsd-src/sys/dev/ichwd/i6300esbwd.c:49:1: warning: unused function 'i6300esbwd_cfg_read' [-Wunused-function] 17 49 | i6300esbwd_cfg_read(struct i6300esbwd_softc *sc) 18 | ^~~~~~~~~~~~~~~~~~~ 19 1 warning generated. 20 /tank/users/bz/git/FreeBSD/freebsd-src/sys/net/iflib.c:7124:1: warning: unused function 'iflib_simple_transmit' [-Wunused-function] 21 7124 | iflib_simple_transmit(if_t ifp, struct mbuf *m) 22 | ^~~~~~~~~~~~~~~~~~~~~ 23 1 warning generated. 24 /tank/users/bz/git/FreeBSD/freebsd-src/sys/dev/ixgbe/ixgbe_e610.c:1411:13: warning: unused function 'ixgbe_is_media_cage_present' [-Wunused-function] 25 1411 | static bool ixgbe_is_media_cage_present(struct ixgbe_hw *hw) 26 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 27 1 warning generated. 28 /tank/users/bz/git/FreeBSD/freebsd-src/sys/dev/ixgbe/ixgbe_e610.c:1411:13: warning: unused function 'ixgbe_is_media_cage_present' [-Wunused-function] 29 1411 | static bool ixgbe_is_media_cage_present(struct ixgbe_hw *hw) 30 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 31 1 warning generated. 32 /tank/users/bz/git/FreeBSD/freebsd-src/sys/contrib/openzfs/module/zstd/zfs_zstd.c:445:1: warning: unused function 'zfs_zstd_compress_wrap' [-Wunused-function] 33 445 | zfs_zstd_compress_wrap(void *s_start, void *d_start, size_t s_len, size_t d_len, 34 | ^~~~~~~~~~~~~~~~~~~~~~ 35 1 warning generated. 36 /tank/users/bz/git/FreeBSD/freebsd-src/sys/dev/ixgbe/ixgbe_e610.c:1411:13: warning: unused function 'ixgbe_is_media_cage_present' [-Wunused-function] 37 1411 | static bool ixgbe_is_media_cage_present(struct ixgbe_hw *hw) 38 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 39 1 warning generated. 40 /tank/users/bz/git/FreeBSD/freebsd-src/sys/net/iflib.c:7124:1: warning: unused function 'iflib_simple_transmit' [-Wunused-function] 41 7124 | iflib_simple_transmit(if_t ifp, struct mbuf *m) 42 | ^~~~~~~~~~~~~~~~~~~~~ 43 1 warning generated. 44 /tank/users/bz/git/FreeBSD/freebsd-src/sys/dev/ichwd/i6300esbwd.c:49:1: warning: unused function 'i6300esbwd_cfg_read' [-Wunused-function] 45 49 | i6300esbwd_cfg_read(struct i6300esbwd_softc *sc) 46 | ^~~~~~~~~~~~~~~~~~~ 47 1 warning generated. 48 linking kernel -- Bjoern A. Zeeb r15:7 From nobody Fri Sep 5 21:27:04 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 4cJTvX1P8mz66Qnn for ; Fri, 05 Sep 2025 21:27:20 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT TLS ECC 1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJTvW55qXz3hMX for ; Fri, 05 Sep 2025 21:27:19 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 585LR5PJ003841 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 5 Sep 2025 23:27:05 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1757107625; bh=Fkf3uWDnj1R5h4eVXSFc+C4yUJgpzr1KEIxiqziZ4JY=; h=Date:Subject:To:References:From:In-Reply-To; b=HU5aMwexzxBbqQC9j0U3oP8YVbtLtEYTaemPC+uhvnYK0W/e5VmObXD5QyAWuA7+G s7KSNv1wPXuYjQLmEEfO6vJt7WIC4ESXwEhWs4uTaJSry7Hf0rcZ2FIB1Njf0XQwMl b5WrxX84tGlXeAOFyxi1bkzZZ7eIy/HaIyJ3B6Hbm0hwozlLVSkpZBXukzMc8WrYNw K9/RtC0dptuepM7O5AkqoJ1CFBDaPRmb1FvoolGyyIUxqvdnhmXp4+5szLl+muWQRW 99ycWAt2b4Ss5oeEfozhhtx0n81vOGvn9+Pm13p/T0q7JGr2iJa91PsXFoaFiNxGkj I8R67B8DRhkcQ== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <9f52f76c-6f97-4ffb-b12a-153fed766a6e@plan-b.pwste.edu.pl> Date: Fri, 5 Sep 2025 23:27:04 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: -Wunused-function rising on main again To: "Bjoern A. Zeeb" , current@freebsd.org References: <8328954n-nq87-23p2-3no1-24394nn1n395@yvfgf.mnoonqbm.arg> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <8328954n-nq87-23p2-3no1-24394nn1n395@yvfgf.mnoonqbm.arg> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cJTvW55qXz3hMX W dniu 5.09.2025 o 23:11, Bjoern A. Zeeb pisze: > long time we were down to 1 zfs warning, now we accumulate a lot > more.  Can people please pay attention.  make -s is your friend: If there is another round of efforts to remove unused functions, please keep in mind that there is a lot of such code under #ifdef RSS, which as far as I kn ow has never been cleaned up. To test this, try building a kernel with "options RSS". Cheers -- Marek Zarychta From nobody Sat Sep 6 00:59:50 2025 X-Original-To: freebsd-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 4cJZd71vcXz66gLb for ; Sat, 06 Sep 2025 01:00:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4cJZd56jMQz3FVK for ; Sat, 06 Sep 2025 01:00:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pbKKgLvM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757120403; bh=p/l13adT8ZWY+HPEMchBPCOlYtvfRu75X+rWfc9RtpY=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=pbKKgLvMp6q6rE4sdrdHUIYy17lIUeAqPbyzbmKE/izAkqshScmNoNIdR+3MoETee7q9ahDVxmTyjDBJZplHIYc0zVNaC+xLbeyYNsM0SEFa+gUbQYkOBfnlAmphugQR5Vwa9otSS5i1dSIZvmcifwoTWONrt0E47lua91UwIHC1d3KfJYjj8ICfb6u3U8YdsJ8A0PxeFfPK6p2CLN/KdTxeiPZTmjOCduaZTCEeN/IodzQ+z3JZ7qP2q2nf+QTJ+HwEH+jzh5/+66t2TdFGgeMH2GNJPpULVxoMR5lmtci+XQBaJbg/ypbNTWMnva3JT8dpqDmpNnPAi3GiPkHbhQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757120403; bh=nNmbYGs6c0cTzneXvQzBo9SmCgWa53BIWYmia5RRvqh=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=VSvT8Z4Ev0inW4J/qQ9oE/AzDdu+/8eyocksKgo7N3zUe5kP/evgWEgzYnuDO+2RrHfQedGISnkjZiP3DVhFQ8T1lz/u5RPwXVrJy4+yrrEXjLNpNQefqbiPEzS+akM1CotB1wVIC0kfPziKRoAs58ux50qvccDDkyLgPqxYVHq6Au2mg2R5pQZOgck36pJx35OMUqJspHlPug+1Fmd4EclBDENudWipWwqJZcm4vK343RCY5YfaLNRxb1zSO7iAnTMaDJZdzuIUr+SDwr7VfOAVL933eJSgZL8WwEIogGOBKuVnEpDdaaa2qWndKhfHOfH+xL4UfvA6KOpAhXJSfA== X-YMail-OSG: guL68vUVM1kq2zFB8ncqexWAERhcG6_NJy4zkoOOfZc1nyLvwW5rhu4zMMRP_3J b6fQWD1o2p.6jBOm1adOekiIw0QSJE4JkApIgi8o6w_SyvALS5HWXmLblLRlswEg9eoKTTIs3j1z 65YEYc.RfoUXzGxv8tckIjNmAWR5LSPgbxNo6F06yHbs9aijB0iK5RnXGxd.z3owlzRtvMqy.xS0 iGR2MjD1wRbiUcGK16lJyJVKrRzr9WXi5ViBMeS5mNEL3JKQP6Af66nb2LAN4GUztlxjWuZ1WPnz UVVA7S3cAt_5TypRA7tSXv4Y2aUwnPhMZcY9RHsQkGPOs7V.exK.tVAEBFPFj8YtGERTqN_ELf69 jIqcn9nFbiJLYLnlps2_.nI9YV68RpUM2LkJMcONuhJF0Zjxiy3pVCua5PMzHAN259Rk31RV_vDa fRu59TPycge4fADi7ftVpls.Vvgd05bb0dGZ2wn86LVfGAfSdPPoWC6Vhgp8tt.LRsNXOpOHxP5u bxJy6b3CXQR8otttV6oYmYq.7g3uZwhy9WEjjs8hd8085pGyYPtxF60GTTqxjgjHKIlxdlI6ZR2A KJtZErs.VdHFchQY5Kjt7XI77tA_qEogDwPTDU.OoMXw6tYcn0BXARUqer3x80QEo0dNlb3JN_dY Pu1Vgead0f4JG8_VgQ9N_86s6Ix2MHf6iybp.ANnmRmVlxgVTPlQ4nq2MdcKErpTjjWZZ.dwe5IJ pjoXt9RzJhnk8RRiZsxPc.qLa7NoLOzD4kWVe72WCC9pTgykjqDGPF1VO9n3UmicCueUPFTSYhGh fPUAiWMxQXpEqDYXn16iZ0bNseAfRGQV1TbXuK6BzpvDHdvqWIBj3jPhKlUe3jjgnz0Ygd1tHLG8 CL.ISIOKJoR9h5KzkNdiA6Bob6oLm3A0QuNItrZeSWex33rIjOnMm8VPctZEXu_m8zhvcj0AnaTq wYIp6OP56cevJNuo2THrXoSSAs3S8vPn.QV6IQbKn6g1K6wKrg3r2D8HzdKJcQmsfmXseG0hw3hn 4k5uv7BrcWtIa_7vJxRoY__LyNvl9qJGaXaiu7DetSHdQm9S3aeiTEKI79OBDFp6eXLZyBtb8C4u Rjz6nawnldJJouyWeuV6bt0aSnLrNrCRI5oqdZIgYR3i59V1AaZSrh51WB16mp4aJSLhP64cCgHP JkqSryYT1NssmPN59r1mcv1cb0PJxkJXCd.XSp7YjlpnnyBtBYKjN3L1FgQA6Az9MYPpceM5AVgn PdmTY4ESjvWiMAwO_8hZqDKDMe0SM9EbalhNg2CWrz7sHuWknvtPRuXt6s86G.cAW_r.KG7MfABo F7If8tD.7yl_TUvfz6f0F6fCv4nAqQF67Q.JYFQIyM1_p_acwfAjXXCOv8YpzIHtOz6yvEy52uwP aEjL5H2BcMA.RobJ8aMK9D37VIcUM5_cRg8inUdY7OrVC_1lWA4t6kXmuqO.X9miwfqrFMfKp5tX U62LpRCanbCDnVm29fuF_R7qGhLxtx3zrT9f1ZDRsRQwt3DcgrUn_P.NmLIAyZTEMCIbH7.cGBa1 Ez6BwCzGbwzvqeec1jIXPpwLXfVg3uxc00RYzJqh9yKm5SJpYBh6f2Zb7C6MmLFTnTKPWNUx2b50 kssujpNMOhGkVOwEsbVbixk9Z65orFd38mR9Uy657jo5nm0lnLnSLnIzrWBf41uyE9L3YGg_DHy9 OOsBSHdy_Ok1DBz3sLKu.Z0xUlJo2kzCVXSyZ.ZUQxVVhiJyhDINfVpfpXvYcMA9UR17JnO3_CRE DfwvIvmHFe15RWpMN6rT.1E2LRYqTkAe.6GRn0ei8R9_B0FvTg2xKMm1miQ4s10_hqBH6MLb5nUJ mZdIvuzwxNee6x8Qmb8o_ELXQ8hU3s3ARSF2HtSYBD0JAQAcg6w9pO9sW7X9uuAgbJJH_P834C7e dkE_HwoBVliWy1yWhh7v5Fd_L5wySe8nD8HK5Cql59OeLfN0fLrgMXPh.KmTipYCVsdIUQsF83OW MtZD1dVCSuaI5WRXSu5OALJ1NueXxnvExLnNvKl0v3mPtX.xwILYIoHksP4dg8appuS9OFi89ybx EO98O87WxwH7ucU0_CxfCyR0asm5fIE04nc8R900tPP3ZCqgw4SkKsiOX8.mzmFSo3k4cGVwUCjR aS9dg6pUoJpRG8x2q7vmZBfnBO2TkHHz6JVhc0GzchdlR9AZDjYQOnWU9o0p86X1lURXA4s2VhLy yuKt3Emyh0MqaEHJV3o1pIoN0T.SQctOG5Yx9Q76zXJ1gUp98ppJQEticI_6RzKGN.xF.68hzRU0 JliLH X-Sonic-MF: X-Sonic-ID: 9335adaf-e1fb-4fdd-ada6-6731990c07f7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 6 Sep 2025 01:00:03 +0000 Received: by hermes--production-gq1-7bfc77444d-7pvrb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 82205769917de969487556018c7bccc4; Sat, 06 Sep 2025 01:00:00 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: git: af60084978a4 - main - Add description for WITH_PTHREADS_ASSERTIONS [turning off debug for personal builds of main ( and stable/* )] Message-Id: Date: Fri, 5 Sep 2025 17:59:50 -0700 To: Nuno Teixeira , FreeBSD-STABLE Mailing List , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from] X-Rspamd-Queue-Id: 4cJZd56jMQz3FVK Nuno Teixeira wrote on Date: Fri, 05 Sep 2025 22:27:07 UTC : > Thanks for the hint, I missed 642cd511028b . >=20 > Think I'm good now: >=20 > /etc/src.conf > WITH_MALLOC_PRODUCTION=3Dyes > WITHOUT_LLVM_ASSERTIONS=3Dyes > WITHOUT_PTHREADS_ASSERTIONS=3Dyes Another potential one is: QUOTE > Is there a reason that ASSERT_DEBUG > ( in share/mk/bsd.opts.mk ) is left enabled > ( listed in __DEFAULT_YES_OPTIONS )? QUOTE You might want: WITHOUT_ASSERT_DEBUG=3D See: = https://lists.freebsd.org/archives/freebsd-stable/2025-September/003110.ht= ml for Colin's comment about why it is unchanged in official stable/* and releng/*.* builds (instead staying like in main) and my reply. What you want to do for ASSERT_DEBUG might depend on your security context's requirements if you are willing to use a setting that FreeBSD official builds never use. Side note: I'll note that the usage of all 4 of these ignore the "yes" text detail and are tested only for being defined vs. not. "no" would get the same result. > Cheers! >=20 >=20 > Colin Percival escreveu (sexta, 5/09/2025 =C3=A0(= s) > 23:07): >=20 > > On 9/5/25 14:57, Nuno Teixeira wrote: > > > For people that turn off debug on main, should = WITH_PTHREADS_ASSERTIONS > > be > > > turned off? > > > > > > e.g. > > > /etc/src.conf: > > > WITH_MALLOC_PRODUCTION=3Dyes > > > WITHOUT_LLVM_ASSERTIONS=3Dyes > > > > According to commit 642cd511028b running WITHOUT_PTHREADS_ASSERTIONS > > improves > > mutex performance by 5-18%. So yes if you want maximal performance = on HEAD > > you should probably turn this off. > > > > Colin Percival =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Sep 6 14:21:06 2025 X-Original-To: freebsd-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 4cJwPK6sSrz66gRk for ; Sat, 06 Sep 2025 14:21:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJwPJ4pn7z3k64 for ; Sat, 06 Sep 2025 14:21:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror); spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.32 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id uqdRu0Np89JM2utmuuwcV9; Sat, 06 Sep 2025 14:21:08 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id utmtuxJKhWX70utmuuFKUB; Sat, 06 Sep 2025 14:21:08 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=d71WygjE c=1 sm=1 tr=0 ts=68bc4354 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=pcJxfTGPG_QVHFLFXHEA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id F341EBD for ; Sat, 06 Sep 2025 07:21:06 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id BEC45282; Sat, 06 Sep 2025 07:21:06 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-current@freebsd.org Subject: Discuss Bug 289320 - graphics/drm-66-kmod: Page fault on 16-CURRENT 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: text/plain; charset=us-ascii Date: Sat, 06 Sep 2025 07:21:06 -0700 Message-Id: <20250906142106.BEC45282@slippy.cwsent.com> X-CMAE-Envelope: MS4xfCwYgzb0QLoTuJOpcH6tvnD4+ycD6kIIyugDFnwdFZe1OsbDZrtGPl4tOZgrM8/MRsi+aHom00lvQ0B39+1FXfognyEbf5hIp8SVQ8kGWfDDnH6HNS/a SonJGvRtKvMU2g5ZKqAv0hbFDJ92XR/JoZxDBfWC14cpKvOBpZbvsT9EEcEPnQ511aQYPopJLMeQmfF7vkNMSP1cP/AFg+Vrwno= X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.22 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.92)[-0.916]; MV_CASE(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.32:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4cJwPJ4pn7z3k64 Hi, I'd like to open up discussion about a weird bug I stumbled across on Thursday. You can get the gory details, including backtrace in PR/289320. Long story short, after the FreeBSD version bump from 15 to 16 amdgpu panics on a kernel page fault. For fun I reverted, locally, the commit that updated the version strings in FreeBSD-CURRENT from 15 to 16, reverting 8b4e4c2737305df8807abc6cd054a32586085c93 on that particular machine, a Framework 13 laptop. The panic was solved. My other machines don't use amdgpu, they either don't use X or in the case of my HP 840, it uses the i915 driver (also part of drm-66-kmod), which works after the 15 to 16 version bump. But the 15 to 16 version bump causes amdgpu also from drm-66-kmod to reference a NULL pointer. What in drm-66-kmod would be sensitive to a FreeBSD version bump? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0 From nobody Sat Sep 6 15:19:31 2025 X-Original-To: freebsd-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 4cJxj03Tdpz66kht for ; Sat, 06 Sep 2025 15:19:48 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJxj01DmRz3pZT for ; Sat, 06 Sep 2025 15:19:48 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-625f7457475so673136a12.0 for ; Sat, 06 Sep 2025 08:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757171985; x=1757776785; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DJV1zWbJFb/mt39omaBW7vPNby8h20L2vseroJY1byo=; b=HVEXPCB9aIYsR+omYtab8HSiQoCwoOCSEX6W8tE21khnSrPNxozQeLtlnl4YrfOThT GkPPCjaX5Iu4aVDEd3Nuy7/KMRvO9G7EURqF80gIGwb5bHDlDet6TfFPMbXeZL5MCs21 8APlsk6GWiCFcPkUxmVBsq9RziN/5hWD48pXX0epio3YXY+Mth1OxqxHc+gLIhm8gk4q /md0zj4oItXD3XMrQwoG4t61LvH9NvwXe9bgjLbSg4u7Tc1qlCGlOorNqhAUWGjiIQKs BQ4o5wQ5l3fp7GzaRId269Vz9lOxIsyAwmjAvzzmSAelOEv0g5ObQZFKxi/Bc7jZ8nEw eKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757171985; x=1757776785; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DJV1zWbJFb/mt39omaBW7vPNby8h20L2vseroJY1byo=; b=itSvnBGQzseaYosnunzc1nvHcB7FlrcJycwvWpZ/nrM9CWYe7RQA0HEDErzptnfXFX LmQpJLGn3Roe/KJ1EEWxCyS2PeG/fz7NoqWeBVZ0KgPjdsrrNPSmUh2B8vBFOZhhEUq/ DzCAA/Cb9/FkUP/hHJZl/sj9DgtNyRzoy0o2rs4WxT9dUVntT794l5zDAPuk4ARclokW JdbNE63JKtL6J5wENXTmdEVDPQoL6bkj1Z/1/6kdxsQ8qe+IAF7okIYepav5VPr2ACJU +Rw5yNKKwXeKVNFD3JHUIf4m2Kf21pn1KDah/pVWo7NEvW/XezGOUyppd0tE69iF352g NHSg== X-Gm-Message-State: AOJu0YxGQJQD0+4fz50zbhhwuMipxF/XzDstImYqg4RJhDEzT2ezWnAy +dwtZ9W3pzSGXJOAhq/cU+LeeFom5ziwGn+8R81J6hPYHgxCJaXBnSl00jqwUPFw4IzuuuuR/MR FV7pVhiCtu3k2KjPGxwJusbteOytXsg== X-Gm-Gg: ASbGncu6gwi6+QfXp2x9IXOAFSh6EVVbnK3J2s5gpwxJZUwReEDL+bF7Zr5xOAp0iGN xMSorhpi86YnKftsixcagQt8ubHxk23DQw31YjBK9XL2nYLwCBBBq4vjnRLj4gCJp9FLj/nD7gV 4AL/YD72O8KbDDpDAq87Yo5U9LeerMoZhUxIOKOx7NFR9sOlwSrlTKa6Qrllxw0QRW3Y2aUXsxe 3Bk2KP4NH7uf0stXLTdtEDrD6al4Jx42gy4KSXvg/t8lNUJyQ== X-Google-Smtp-Source: AGHT+IHiyKCQSwVK+4MXn/fyKazg6rKiIarmHFSb4Zuu6jCyl0embX5pDKNusbcp1AoiwsEFZ7CzaAV2nn3smdx6Lk0= X-Received: by 2002:a05:6402:5208:b0:61d:1d16:19b1 with SMTP id 4fb4d7f45d1cf-62373df6640mr2282660a12.14.1757171985030; Sat, 06 Sep 2025 08:19:45 -0700 (PDT) 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 References: <20250906142106.BEC45282@slippy.cwsent.com> In-Reply-To: <20250906142106.BEC45282@slippy.cwsent.com> From: Rick Macklem Date: Sat, 6 Sep 2025 08:19:31 -0700 X-Gm-Features: Ac12FXwB96hj2XzEkwbI37Rti2OEpeUVrXiGUnyNYARRrNuNOrEea6K2L0sdKfU Message-ID: Subject: Re: Discuss Bug 289320 - graphics/drm-66-kmod: Page fault on 16-CURRENT To: Cy Schubert Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cJxj01DmRz3pZT On Sat, Sep 6, 2025 at 7:21=E2=80=AFAM Cy Schubert wrote: > > Hi, > > I'd like to open up discussion about a weird bug I stumbled across on > Thursday. You can get the gory details, including backtrace in PR/289320. > > Long story short, after the FreeBSD version bump from 15 to 16 amdgpu > panics on a kernel page fault. For fun I reverted, locally, the commit th= at > updated the version strings in FreeBSD-CURRENT from 15 to 16, reverting > 8b4e4c2737305df8807abc6cd054a32586085c93 on that particular machine, a > Framework 13 laptop. The panic was solved. > > My other machines don't use amdgpu, they either don't use X or in the cas= e > of my HP 840, it uses the i915 driver (also part of drm-66-kmod), which > works after the 15 to 16 version bump. But the 15 to 16 version bump caus= es > amdgpu also from drm-66-kmod to reference a NULL pointer. > > What in drm-66-kmod would be sensitive to a FreeBSD version bump? Blame it on quantum entanglement.. One a slightly more serious note, I'd grep for uses of MODULE_KERNEL_MAXVER in the sources as a starting point. rick > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e**(i*pi)+1=3D0 > > > From nobody Sun Sep 7 17:21:54 2025 X-Original-To: freebsd-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 4cKcMl28fpz66VXh; Sun, 07 Sep 2025 17:22:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cKcMk42HWz3rBF; Sun, 07 Sep 2025 17:22:10 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-6237202020bso2030308a12.3; Sun, 07 Sep 2025 10:22:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757265729; x=1757870529; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R8ELZIptlcATR0J+76VrvIcTSJ5f2pf1Kdo7t9kSRQs=; b=D/Y28yQG3EvDe+WTwsLlge/Mr1zayqsig9phxirAoC0ZKUv2QKYwZzSG7WG7SBZUEo FULffYz0TJnBc0Pxct6+o028uQJfsjsWstdyhXIdehnrdDj/NUYED/jjiWCJlPWAsc31 +q0aML71QDoicNif7RhZEXSJSJ2tLgJLGIQlbzhxBJUVBTACD/x7KG2v5zcCpewByvxz VWvEIwtXkyDK/g+Zlh13ND17vBMjd+0mefByHzw+kRfBewrKWY5arFhh5yKyhBoaMf9b jMChgiOvhNijPXGfzf+4Iu/zLaiUcQAWe2mO+8ty4ngbngWjyd9ayHVQDIGBBNTc+Zsm SzqQ== X-Forwarded-Encrypted: i=1; AJvYcCVcR85bTtjkRgHL2w0IoirWYiOQiF8F8MmXja2kgGiupqbg6nz/T0TE9BieU+9TheBNCl07LAAIDSTVaCMtvtw=@freebsd.org, AJvYcCWx6xKBK0HNhrdIeK12dsyODPHaHOn89Yx64LwT00IzIhNcHFq3bVNysSP+jqouAHgwooRIoeFKGocm2w==@freebsd.org X-Gm-Message-State: AOJu0Yz0bjlvX76f3ektAjK4qsc6/0/s3sHn/yVGeit5ugyGLuqGdCXB HlTJr7dUp20FESeQ9tPVeHorWCoM0TDJz2nT2Eo2HYp+r7YF2S2lvraOW2KU8Y5z4l9+IahQaBD UXZrCW6A2MMfWKk1i5LXJEQ0zlamvzQLhMg== X-Gm-Gg: ASbGncuqS6TElpZm5GVeG9I/DC3ZcbpRQfr9udMm1aVmq3B36zSnuKhkExkSXSjFCcj 8kT7C4g8bVP4L8it2eVKXS94FH/r52aTYA+FWM+JQXnpvIao1CJlBc/3XBC4XMgJhoSVHucz2JW NVHOQo/G/ub6KyAKQC+kw89fgyaelx0iYLBKeLEYAOINIIBESPR3aPmZ8Mm47PyPrgZBSbBtEzz pN2nGnNORZEKG6rqQ== X-Google-Smtp-Source: AGHT+IFcxBnjF510XEWR5PoHT7ZW4PpsbhVUjal596B3b5h74vVHwGU0L2OJrm9jWzHuP7S/vaKrIlxE1Te5VdqBpmI= X-Received: by 2002:a05:6402:27d2:b0:617:b662:2272 with SMTP id 4fb4d7f45d1cf-623786455b1mr4232552a12.33.1757265728603; Sun, 07 Sep 2025 10:22:08 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Sun, 7 Sep 2025 11:21:54 -0600 X-Gm-Features: AS18NWAKnbM8vm7Q7yfHY7otuMSdxdipXY4RTO1Ysunp3B_Uxcha4Xf5TvlXTTE Message-ID: Subject: Re: Fuse issue with attr caching expecting write lock To: Konstantin Belousov Cc: obiwac , freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: multipart/alternative; boundary="00000000000087890e063e394f99" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.41:from]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.41:from]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-fs@freebsd.org]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4cKcMk42HWz3rBF --00000000000087890e063e394f99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 4, 2025 at 6:15=E2=80=AFPM Konstantin Belousov wrote: > On Fri, Sep 05, 2025 at 01:36:39AM +0200, obiwac wrote: > > Hi! > > > > When trying to access a large file with sshfs (on fuse), I get a > > kernel panic because fuse_internal_cache_attrs is asserting a write > > lock when it is sometimes being called from fuse_internal_do_getattr, > > which only asserts a read lock. > > > > To me (i.e. someone who has never touched VFS or fuse code) this code > > looks wrong, and fuse_internal_do_getattr should be acquiring a write > > lock around its call to fuse_internal_cache_attrs, but clearly it has > > been working just fine for a while now as this code hasn't changed > > super recently so I could be missing something. > It is only the assertions that were enabled recently. > > Mark merged DEBUG_VFS_LOCKS option into INVARIANTS. > I'm not surprised to see bugs like this one, for the reason Kib stated. I suspect that there are many more, because DEBUG_VFS_LOCKS was historically rarely used. If you can come up with an easy reproduction case, please open a ticket on bugzilla and CC me. And BTW, my FreeBSD user name is "asomers", not "alan.somers". --00000000000087890e063e394f99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 4, 2025 at 6:15=E2=80=AFPM Konstantin B= elousov <kostik= bel@gmail.com> wrote:
On Fri, Sep 05, 2025 at 01:36:39AM +0200, obiwac wrote:
> Hi!
>
> When trying to access a large file with sshfs (on fuse), I get a
> kernel panic because fuse_internal_cache_attrs is asserting a write > lock when it is sometimes being called from fuse_internal_do_getattr,<= br> > which only asserts a read lock.
>
> To me (i.e. someone who has never touched VFS or fuse code) this code<= br> > looks wrong, and fuse_internal_do_getattr should be acquiring a write<= br> > lock around its call to fuse_internal_cache_attrs, but clearly it has<= br> > been working just fine for a while now as this code hasn't changed=
> super recently so I could be missing something.
It is only the assertions that were enabled recently.

Mark merged DEBUG_VFS_LOCKS option into INVARIANTS.
=C2=A0I'm not surprised to see bugs like this one, for the= reason Kib stated.=C2=A0 I suspect that there are many more, because DEBUG= _VFS_LOCKS was historically rarely used.=C2=A0 If you can come up with an e= asy reproduction case, please open a ticket on bugzilla and CC me.=C2=A0 An= d BTW, my FreeBSD user name is "asomers", not "alan.somers&q= uot;.
--00000000000087890e063e394f99--