From nobody Sun Nov 2 23:59:52 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 4d0BY16WLbz6FmLW for ; Mon, 03 Nov 2025 00:00:05 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d0BY12fQCz45cQ for ; Mon, 03 Nov 2025 00:00:05 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=none; 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 5A2NxrNS065433; Sun, 2 Nov 2025 15:59:59 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Sun, 02 Nov 2025 15:59:52 -0800 From: Chris To: Lars Tunkrans Cc: FreeBSD CURRENT Subject: Re: Why is the DVD image so large? In-Reply-To: <0b0432cb-1f7c-4c62-bf25-65e243163f25@gmail.com> References: <0b0432cb-1f7c-4c62-bf25-65e243163f25@gmail.com> User-Agent: UDNSMS/17.0 Message-ID: <8cb72b717229553bb4ca6849ca590298@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_07f3f61c2d930badc0ca3ab4282dff41" X-Spamd-Bar: + X-Spamd-Result: default: False [1.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; 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]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Rspamd-Queue-Id: 4d0BY12fQCz45cQ --=_07f3f61c2d930badc0ca3ab4282dff41 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-11-01 12:44, Lars Tunkrans wrote: > Den 2025-11-01 kl. 15:06, skrev Dennis Clarke: >> >> >>     * * * I am happy to ask the dumb questions * * * >> >> >> This morning I see that we have FreeBSD 15.0 BETA4 iso stuff : >> >> https://download.freebsd.org/releases/ISO-IMAGES/15.0/?C=M&O=D >> >> For doing a test install onto some real hardware I felt it would be nice to >> try out the iso images for ye old fashioned DVD. Worth a try? >> >> However I see : >> >> FreeBSD-15.0-BETA4-amd64-dvd1.iso     5150257152  2025-Oct-31 12:38 >> FreeBSD-15.0-BETA4-amd64-dvd1.iso.xz  4276839812  2025-Oct-31 12:38 >> >> Now the dvd1 image seems a tad large for an actual DVD media. I think >> this has been the case for a very long time now. >> >> Why is the DVD image so large?  Can something/anything be trimmed out? >> > > HI   Dennis > >    Beta3    did  not  have  the  KDE  Packages    and  was  4 GB  .   BETA4  >   > has  the  KDE  packages    and  is  4.8 GB >     Just 100  MB    to  large  for  a  standard   DVD of  4.7 GB >    I looked  at  the  cost  of  DVD-R   media   and  DVD-DL  ( Double Layer > )  > media   at  Amazon .  And  prices  is  very similar   for  50  DVD  & > DVD-DL  > spindle packs. >    There is no  economic  reason   for not  buying   8.5 GB DVD-DL media . >    SO  its  possible  to put even  more  packages  on  a DVD-DL_ISO    (  > Up  to  > 8,5 GB )    which  would make offline installation  a  lot easier. How does this pertain to reader/writers? Different burners have different capabilities. > >     All  thats  needed  is  to  Document  that   DVD-DL  media is  required  >   > for  the  DVD-DL_ISO > > Regards -- There is no such place as the internet --=_07f3f61c2d930badc0ca3ab4282dff41 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----- --=_07f3f61c2d930badc0ca3ab4282dff41-- From nobody Mon Nov 3 00:09: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 4d0Bm43FJjz6Fr5f for ; Mon, 03 Nov 2025 00:09:40 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d0Bm406nhz47y8 for ; Mon, 03 Nov 2025 00:09:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=bsdforge.com; 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 5A309Svp017773; Sun, 2 Nov 2025 16:09:34 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Sun, 02 Nov 2025 16:09:27 -0800 From: Chris To: Lars Tunkrans Cc: Sulev-Madis Silber , freebsd-current@freebsd.org Subject: Re: Why is the DVD image so large? In-Reply-To: <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_1bb9ef85f619be7e7cb7369ecd848066" X-Spamd-Bar: / X-Spamd-Result: default: False [0.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[bsdforge.com,reject]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Rspamd-Queue-Id: 4d0Bm406nhz47y8 --=_1bb9ef85f619be7e7cb7369ecd848066 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2025-11-01 13:01, Lars Tunkrans wrote: > Den 2025-11-01 kl. 17:19, skrev Sulev-Madis Silber: >> >> On November 1, 2025 4:06:48 PM GMT+02:00, Dennis >> Clarke wrote: >>> Why is the DVD image so large? Can something/anything be trimmed out? >> it's kind of funny >> >> because cperciva was just asked to fill up the apparant "empty" wasted >> space seen in beta3 dvd >> >> which he did! even overachieved the task slightly, apparently? >> >> so in order to not generate full war we would need to either cut back, >> remove or abadon actual dvd size in some images >> >> or maybe make image remotely or locally customizable >> >> or provide separate images (tiny, medium, huge) which are just offline >> repos >> >> or finally start shipping images with various de's which users ask but >> which can't be easily done as disks don't self-expand. and then you need to >> archive it all too >> >> or something else >> >> p.s.: btw, i was not able to install ports from b3 dvd for some reason, i >> didn't check why and completed the test setup from remote > > HI > > Yes I started this ..... > I notices that B2 did not include the DVD: ./packages/repo directory and > contents. > this was fixed in B3. but B3 was Void of KDE packages. B4 now have KDE > packages > but is 4.8 GB , > I propose to abandon DVD 4.7 GB format and that future DVD-ISO packages use > DVD-DL > 8.5 GB discs. Why stop there? Why not abandon DVDs entirely and require 16GB and require a 16+ GB thumb drive? IMHO The easier for someone to get FreeBSD on their target, the better. It used to be on CD. Now it's available in DVD. But why restrict it to the largest DVD possible? > > Regards -- There is no such place as the internet --=_1bb9ef85f619be7e7cb7369ecd848066 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----- --=_1bb9ef85f619be7e7cb7369ecd848066-- From nobody Mon Nov 3 00:59:05 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 4d0CsG4Gzkz6Fy57 for ; Mon, 03 Nov 2025 00:59:14 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 4d0CsF6GTqz4GRd for ; Mon, 03 Nov 2025 00:59:13 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-594259bc5f1so854119e87.2 for ; Sun, 02 Nov 2025 16:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762131547; x=1762736347; darn=freebsd.org; h=in-reply-to:organization:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Y7vzHytZEZi0JVJN007+tbJBFDZ95e7WGFrGNBWEqCw=; b=YVUcso+V2qaBxqEGEzhkASJZ8yRVG+b0ahguwiMPqiObYjJ0JeDIJfQTBuR3FIrhDm fMyWNnMXZJcypMPt6FKTNl/PNm9gW+JlmU10uQeFGhipM8IZHWZ7TOYnrrwMOSFXMDTf W8sQGK8tv+n7se94SDWfiZss/cMk2hPXeeGA3Q/T+6yWGU0769Y7qQzZNXx0kAQrdCp+ t7XwnPgQKVboIDHZL5Gbn5q84f2Lo1HTdqF7a5Q3fQoF42KkBx5ysToOIsSn9LAdRnvL 3kSgywJMoJdIEpqRb30PTrtPj/4HWqfXCHNRP0vptRScjsDpJ/cFp19a/1tWC3RJNavu sUpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762131547; x=1762736347; h=in-reply-to:organization:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Y7vzHytZEZi0JVJN007+tbJBFDZ95e7WGFrGNBWEqCw=; b=K9FcsLT6L1L2o6Mv7n9S/KzqENooAunmz+hgVfsRPyZpvNEDLSwOmLhWZ2kiQQzGHt VS+0YYiIpGc6/rm16UYv2f/ncALcJBf1pebk6KJx3fCs28qrbGmEWvyOb8CuSUYzdVAd +ntqZSUQgBFFpg/PXugOeeemgoUO8geQcznNtM1q3OEMh7B1srmYd3Fm4LBoZJ9FMwUD /u/KJvqZqMl+xCjDD9aNkexlhzuZ0nbPYsc3rnDd6TE9cFZn9PnMGoQG8gLXVxka515Q vBG7Z7z2ejvWfxJgR/KPPW35O0W4Vs6XogRcNCY3RlV0IC514KdGeKjuLCdRpuSF1fdH 4dzg== X-Gm-Message-State: AOJu0Yw+SPBqe21IDXECMek9I2NV1sGDryfrL+i5zzKi5uk5UfqLuhmg ZXLieoFM+8E/jI9YM+EsRPxRjs2pgLotzNOkNSRXf+QZXL9WkeockbR/zRGH6g== X-Gm-Gg: ASbGncvBl47shDftA8MN9X5z8ieZF2g17Z7fKo/oM+jJtp+mPbKBeC9nvuEPxKVqm27 2EJRiBN8Yd2Ur9VFyVGFE5BIBBFKsb5ztZrsNROnZBfb1CjZPD4Z6odX7o3vmO1yt2gt/87Kbt5 QTtBCDxDDeRfRQTj5qNAocKJCR+FHD3aOYjtV5GuHuHgwgh4L6e2is3B4Wli0LJbyHJEz/oWBwR P53GjVFzlh5UCATkxgeKrZ5ysv4f4HCWqpK55vbGVmxQyg63swmmWMv/jwb0AzSSKulSMLqA9zT n/mBr0V3eFksu5/yOatKcQkuAGEG+I7TOB2PKUBDY5abRFnlzKJOpUgVInX6vBVaGrj0GHJPi8/ 09a5N0U1l1N0Qy9tDNF4e/gtAN0UlYSUgQyFxLXdAgCxPVbYOkfMOZdzueJrYR1f1rOAmkpCpcM Lh4Arx5KfU3ytRs4ZUIjmqpeBNynAJqg== X-Google-Smtp-Source: AGHT+IHrHD50Ofh7AwxXeANv52AVASRiuKvA26xSF7FJPgJjjSQcfKSuQ7NOGGdkT3Re0rZrR0y57Q== X-Received: by 2002:a05:6512:3985:b0:594:2c51:f27b with SMTP id 2adb3069b0e04-5942c51f422mr656947e87.18.1762131546414; Sun, 02 Nov 2025 16:59:06 -0800 (PST) Received: from [192.168.2.131] (host.62.13.8.86.bitcom.se. [62.13.8.86]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5941f3a3505sm2407726e87.48.2025.11.02.16.59.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Nov 2025 16:59:06 -0800 (PST) Content-Type: multipart/alternative; boundary="------------FRXEik3gPyCmiCSgfQn9twkD" Message-ID: Date: Mon, 3 Nov 2025 01:59:05 +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: Why is the DVD image so large? To: Chris Cc: FreeBSD CURRENT References: <0b0432cb-1f7c-4c62-bf25-65e243163f25@gmail.com> <8cb72b717229553bb4ca6849ca590298@bsdforge.com> Content-Language: sv-SE From: Lars Tunkrans Organization: Retiered In-Reply-To: <8cb72b717229553bb4ca6849ca590298@bsdforge.com> 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: 4d0CsF6GTqz4GRd This is a multi-part message in MIME format. --------------FRXEik3gPyCmiCSgfQn9twkD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Den 2025-11-03 kl. 00:59,  Chris wrote : > On 2025-11-01 12:44, Lars Tunkrans wrote: >> Den 2025-11-01 kl. 15:06, skrev Dennis Clarke: >>> >>> >>>     * * * I am happy to ask the dumb questions * * * >>> >>> >>> This morning I see that we have FreeBSD 15.0 BETA4 iso stuff : >>> >>> https://download.freebsd.org/releases/ISO-IMAGES/15.0/?C=M&O=D >>> >>> For doing a test install onto some real hardware I felt it would be >>> nice to try out the iso images for ye old fashioned DVD. Worth a try? >>> >>> However I see : >>> >>> FreeBSD-15.0-BETA4-amd64-dvd1.iso     5150257152  2025-Oct-31 12:38 >>> FreeBSD-15.0-BETA4-amd64-dvd1.iso.xz  4276839812  2025-Oct-31 12:38 >>> >>> Now the dvd1 image seems a tad large for an actual DVD media. I think >>> this has been the case for a very long time now. >>> >>> Why is the DVD image so large?  Can something/anything be trimmed out? >>> >> >> HI   Dennis >> >>    Beta3    did  not  have  the  KDE  Packages    and  was  4 GB  .   >> BETA4 >> has  the  KDE  packages    and  is  4.8 GB >>     Just 100  MB    to  large  for  a  standard   DVD of  4.7 GB >>    I looked  at  the  cost  of  DVD-R   media   and  DVD-DL  ( Double >> Layer ) >> media   at  Amazon .  And  prices  is  very similar   for  50 DVD  & >> DVD-DL >> spindle packs. >>    There is no  economic  reason   for not  buying   8.5 GB DVD-DL >> media . >>    SO  its  possible  to put even  more  packages  on  a DVD-DL_ISO  >>   (  Up  to >> 8,5 GB )    which  would make offline installation  a  lot easier. > How does this pertain to reader/writers? Different burners have > different capabilities. *The DVD-R DL format was released   to   the market in 2005.   ( according  to  the  Google AI   & Wikipedia ) *  Your  DVD Writer/Reader     needs  to  have been  bought   for more  than  15   years  ago,  to not  support DVD-DL format. basically  three  Computer generations. > >> >>     All  thats  needed  is  to  Document  that   DVD-DL  media is  >> required >> for  the  DVD-DL_ISO >> >>    Regards > -- ------------------------- Lars Tunkrans Oracle SPARC/Solaris System Administrator Fujitsu M12 SPARC Specilaist --------------FRXEik3gPyCmiCSgfQn9twkD Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


Den 2025-11-03 kl. 00:59,  Chris wrote :
On 2025-11-01 12:44, Lars Tunkrans wrote:
Den 2025-11-01 kl. 15:06, skrev Dennis Clarke:


    * * * I am happy to ask the dumb questions * * *


This morning I see that we have FreeBSD 15.0 BETA4 iso stuff :

https://download.freebsd.org/releases/ISO-IMAGES/15.0/?C=M&O=D

For doing a test install onto some real hardware I felt it would be nice to try out the iso images for ye old fashioned DVD. Worth a try?

However I see :

FreeBSD-15.0-BETA4-amd64-dvd1.iso     5150257152  2025-Oct-31 12:38
FreeBSD-15.0-BETA4-amd64-dvd1.iso.xz  4276839812  2025-Oct-31 12:38

Now the dvd1 image seems a tad large for an actual DVD media. I think
this has been the case for a very long time now.

Why is the DVD image so large?  Can something/anything be trimmed out?


HI   Dennis

   Beta3    did  not  have  the  KDE  Packages    and  was  4 GB  .   BETA4   
has  the  KDE  packages    and  is  4.8 GB
    Just 100  MB    to  large  for  a  standard   DVD of  4.7 GB
   I looked  at  the  cost  of  DVD-R   media   and  DVD-DL  ( Double Layer ) 
media   at  Amazon .  And  prices  is  very similar   for  50  DVD  & DVD-DL 
spindle packs.
   There is no  economic  reason   for not  buying   8.5 GB DVD-DL media .
   SO  its  possible  to put even  more  packages  on  a DVD-DL_ISO    (  Up  to 
8,5 GB )    which  would make offline installation  a  lot easier.
How does this pertain to reader/writers? Different burners have different capabilities. 
 

The DVD-R DL format was released   to   the market in 2005.   (  according  to  the  Google AI   & Wikipedia )  
 Your  DVD Writer/Reader     needs  to  have been  bought   for more  than  15   years  ago,  to not  support DVD-DL format. 
basically  three  Computer generations.  




    All  thats  needed  is  to  Document  that   DVD-DL  media is  required   
for  the  DVD-DL_ISO

   Regards 

-- 
-------------------------
Lars Tunkrans
Oracle SPARC/Solaris System Administrator
Fujitsu M12 SPARC Specilaist
--------------FRXEik3gPyCmiCSgfQn9twkD-- From nobody Mon Nov 3 01:15:37 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 4d0DDG4cKHz6G0LD for ; Mon, 03 Nov 2025 01:15:42 +0000 (UTC) (envelope-from groenveld@acm.org) Received: from 004.mia.mailroute.net (004.mia.mailroute.net [199.89.3.7]) (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 "mailroute.net", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d0DDF3VqTz4J7g for ; Mon, 03 Nov 2025 01:15:41 +0000 (UTC) (envelope-from groenveld@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=acm.org header.s=mr01 header.b="uqo0H/pJ"; dmarc=pass (policy=reject) header.from=acm.org; spf=pass (mx1.freebsd.org: domain of groenveld@acm.org designates 199.89.3.7 as permitted sender) smtp.mailfrom=groenveld@acm.org Received: from localhost (localhost [127.0.0.1]) by 004.mia.mailroute.net (Postfix) with ESMTP id 4d0DDD1vcczm87FW for ; Mon, 3 Nov 2025 01:15:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= message-id:date:date:content-transfer-encoding:content-id :content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:received:received; s=mr01; t= 1762132539; x=1764724540; bh=pnwXumQ4+Qov+lRy4UlFb2lZuhPkjmJrCHu YHl08MiE=; b=uqo0H/pJydRhkZaXpIYxUu2YmW9nxisf56czvKcJr0bJM75aZJB Qd3VXQHld/j/phbK2YZqpSmOwnWilJv15m/Xj7ZjG8ELzGT8eK7+IMhahW750XqJ HFhUQ/wppETOR6OaqnKF8rNNLdTreKnru0v2fWrkcSrRd5LGhRkZ2yRxo9YKwR0o xzrsMzLkmvizxH8LoUOOeHRwdjnTVkKYy+Slqzro+SaETbM74IOt4OXeEO6pXRuK 1MHS88Q/0buuKuMItLTf4mdOUrVuK55Cl9yYYkvoFsQ8rUFt4QtKiuUoBsmKlbCs ugJBbGqcgiAul/EZ60oDE5Hz7PtfLSJnUqQ== X-Virus-Scanned: by MailRoute Received: from 004.mia.mailroute.net ([127.0.0.1]) by localhost (004.mia [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id xj438uoxP3WJ for ; Mon, 3 Nov 2025 01:15:39 +0000 (UTC) Received: from mail.groenveld.us (mail.groenveld.us [207.68.114.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: groenveld@acm.org) by 004.mia.mailroute.net (Postfix) with ESMTPSA id 4d0DDC2q2lzmCjM5 for ; Mon, 3 Nov 2025 01:15:38 +0000 (UTC) From: John D Groenveld X-uri: To: freebsd-current@FreeBSD.org Subject: Re: Why is the DVD image so large? In-reply-to: Your message of "Sat, 01 Nov 2025 13:21:38 -0400." References: <72691b30-633d-433e-a28d-dfbd2529722a@gmail.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-ID: <4518.1762132537.1@mail.groenveld.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 02 Nov 2025 20:15:37 -0500 Message-Id: <4d0DDC2q2lzmCjM5@004.mia.mailroute.net> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.09 / 15.00]; DWL_DNSWL_MED(-2.00)[acm.org:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[acm.org,reject]; R_DKIM_ALLOW(-0.20)[acm.org:s=mr01]; R_SPF_ALLOW(-0.20)[+ip4:199.89.0.0/21]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[199.89.3.7:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_HELO_LOCALHOST(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[acm.org:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; ASN(0.00)[asn:8100, ipnet:199.89.3.0/24, country:US]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4d0DDF3VqTz4J7g In message , Dennis Cl= arke = writes: >> = >>> ... dvd1 image is also almost at its limit, which is 4.7GB for single = >>> layer DVD (FreeBSD 14 dvd1 is 4541104128 bytes=3D4.54 GB). >> = >> = >> 5150257152 does seem to exceed this. >> = | Before you begin downloading an ISO | Make sure you have: | = | An internet connection (internet service provider fees may | apply). | Sufficient data storage available on the computer, USB, or | external drive you are downloading the .iso file to. | A blank DVD disc with at least 8GB (and DVD burner) to create a | bootable disc. We recommend using a blank USB or blank DVD, because | any content on it will be deleted during installation. | If you receive a "disc image file is too large" message while | attempting to burn a DVD bootable disc from an ISO file, consider | using a higher capacity Dual Layer DVD. $ wc -c SW_DVD9_Win_Pro_11_24H2_64BIT_English_Pro_Ent_EDU_N_MLF_X23-69812.= ISO 5722114048 SW_DVD9_Win_Pro_11_24H2_64BIT_English_Pro_Ent_EDU_N_MLF_X23-69= 812.ISO $ fetch --print-size https://download.freebsd.org/releases/ISO-IMAGES/15.0= /FreeBSD-15.0-BETA4-amd64-dvd1.iso 5150257152 I do not have dual-layer DVD blank media handy and I am unsure if my DVD recorder can write to it, but both ISOs work with the virtual DVD readers I have tested. John groenveld@acm.org From nobody Mon Nov 3 03:30:37 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 4d0HCP2npBz6GBWB for ; Mon, 03 Nov 2025 03:30:09 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4d0HCM5B72z3Gjf for ; Mon, 03 Nov 2025 03:30:07 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 91706 invoked from network); 3 Nov 2025 03:30:07 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 3 Nov 2025 03:30:07 -0000 Date: Sun, 2 Nov 2025 19:30:37 -0800 From: Graham Percival To: freebsd-current@freebsd.org Cc: Colin Percival Subject: FreeBSD Git Weekly 2025-10-27 to 2025-11-02 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=us-ascii Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.83)[-0.830]; NEURAL_HAM_MEDIUM(-0.77)[-0.766]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from] X-Rspamd-Queue-Id: 4d0HCM5B72z3Gjf Hi all, I'm happy to announce FreeBSD git weekly for 2025-10-27 -- 2025-11-02: https://freebsd-git-weekly.tarsnap.net/2025-10-27.html It's a list of the 217 commits in that week, split into categories. No highlighted commits this week. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Mon Nov 3 03:54:52 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 4d0HmB5G1bz6GD7l for ; Mon, 03 Nov 2025 03:55:06 +0000 (UTC) (envelope-from bounces+SRS=7YfAi=5L@junipernetworks.onmicrosoft.com) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.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 "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d0Hm95CbWz3Kgm for ; Mon, 03 Nov 2025 03:55:05 +0000 (UTC) (envelope-from bounces+SRS=7YfAi=5L@junipernetworks.onmicrosoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=MJd1gc02; dkim=none ("invalid DKIM record") header.d=juniper.net header.s=selector1 header.b=AetJF59j; dmarc=pass (policy=reject) header.from=juniper.net; spf=fail (mx1.freebsd.org: domain of "bounces+SRS=7YfAi=5L@junipernetworks.onmicrosoft.com" does not designate 208.84.65.16 as permitted sender) smtp.mailfrom="bounces+SRS=7YfAi=5L@junipernetworks.onmicrosoft.com"; arc=pass ("microsoft.com:s=arcselector10001:i=1") Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5A32WqPE2016835; Sun, 2 Nov 2025 19:55:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=I1XwH4lL56WQ4 ibmTYtTuGvPuSXWW0F4VYYEIEMnvV4=; b=MJd1gc02WtTx9h4YWvJ+JsVDjBB1V TpKasMP79R9H+9Lj2CvwwOlewapc+i4OqFMCzsak6Ro7JJ3vfTT6zaff6Iz4VoGJ BM/DQFAEm3i77u10XEItJGyPYVEIZFKEWnpxFUdyWQil5BuooLDz0j8wRzBjw7X6 63xjtYMBgCr/D4plwLl+z9WlJex2Tjvnji/xbcfmtIE3VQaJBDI0RzgGTSnPvUyP b3tTQm2xQy+9Unckj+6GZS2IuYRbfG0EuujqfmLqDvU63cXOYYxMcor/6oure7ns zyTc14jaPBWV4XJsfWamfUx1fnN5snCQvwKLV+UhyE9SKyl+0586zvaaA== Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11011037.outbound.protection.outlook.com [40.107.208.37]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 4a5dwmaewv-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 02 Nov 2025 19:55:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G9+C/LjztWCedADzMp4REyjhtBxGg9p705h8BmChrx1IW4psOQPEGf/q7wJ5ihtNcLXKuEJSKmR08H8mAaqiz1ahh9ms6eSDK3JuChp/DMsBwRT843l1tbjU7stTOKymBuphRwGb6jb1akWHH77QeiKLEFPyC+G6CCeSV5vGJAWcV4VuMq83lQEmfX4b3GcldAv9WDQS0RxQR8Lx0IVEn33req0Y0KVhcaOKMhSLQBQHE4chDsJMB2lwRnFZxBCTkYxTHjuADju8XUcxOTG7m3voBIHMbO420CKpOlk6MBiLzp91bnnGCW5aXmUn9w276Rd1xF5DWSPATi1r7dPlBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=I1XwH4lL56WQ4ibmTYtTuGvPuSXWW0F4VYYEIEMnvV4=; b=eEuGdCoK3nPzPVLaAukmQwNwtDpVSLE+ByqDQVVQf6qPz/84sU57E7yWv5h16aBWETpqmW+2jE0c0o4iSwTXbsP0i5fds06fL4pMYFEgK6H7uoOvzB2gmQH592ZPZF9cPAsHWlrF4eb/+cfkjtSYFb0qntDNpx3ZPPKAvGCRxxaTVtttn4HD+PLqiGvsekIAgHKblYBIGBNuQ3AT03dAPNhtgG0oeOoWjIA4RsjPDT5GJ6t521eIp7G6ryerR//v8Sq70VU2e/eA4xuTnv+hq+G2hP/iWxaFLvwNWmhLU8nvNj3OTWlRflqFjFSaYzoS7Mup6zYnunw7lmahmbd8/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none (sender ip is 66.129.239.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=eng-mail03.juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I1XwH4lL56WQ4ibmTYtTuGvPuSXWW0F4VYYEIEMnvV4=; b=AetJF59jS5X7dhJcSDCt8uyS59SuSNZlTlhx6hmFFKvEGXk5s/7I2+tD1ky10P6xMXINYUaUfp84si4zS4VabnXMsg0CELcuR+TEtFojAmsUdTf8PWuRe2VUdufBijeOkoiWo54XNQrt51Ay7KWoNGNUt3MtiW00mceGH5/o3Qc= Received: from CH2PR18CA0035.namprd18.prod.outlook.com (2603:10b6:610:55::15) by DS0PR05MB9400.namprd05.prod.outlook.com (2603:10b6:8:13a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9275.16; Mon, 3 Nov 2025 03:54:57 +0000 Received: from CH3PEPF0000000C.namprd04.prod.outlook.com (2603:10b6:610:55:cafe::5b) by CH2PR18CA0035.outlook.office365.com (2603:10b6:610:55::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9275.16 via Frontend Transport; Mon, 3 Nov 2025 03:54:50 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 66.129.239.14) smtp.mailfrom=eng-mail03.juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: None (protection.outlook.com: eng-mail03.juniper.net does not designate permitted sender hosts) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9298.6 via Frontend Transport; Mon, 3 Nov 2025 03:54:56 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Sun, 2 Nov 2025 21:54:56 -0600 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Sun, 2 Nov 2025 21:54:56 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14 via Frontend Transport; Sun, 2 Nov 2025 21:54:56 -0600 Received: from eng-mail03.juniper.net (eng-mail03.juniper.net [10.108.22.11]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 5A33stGb022579; Sun, 2 Nov 2025 19:54:55 -0800 (envelope-from sjg@eng-mail03.juniper.net) Received: from eng-mail03.juniper.net (localhost [127.0.0.1]) by eng-mail03.juniper.net (8.18.1/8.18.1) with ESMTPS id 5A33ssf7031061 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 2 Nov 2025 19:54:54 -0800 (PST) (envelope-from sjg@eng-mail03.juniper.net) Received: (from sjg@localhost) by eng-mail03.juniper.net (8.18.1/8.18.1/Submit) id 5A33sr5P031060; Sun, 2 Nov 2025 19:54:53 -0800 (PST) (envelope-from sjg) To: Dennis Clarke CC: , Subject: Re: a really big question : why not "^C" for a CTRL-C with default /bin/sh ? In-Reply-To: <0c09c6fa-7071-4119-b97e-fc6d83f9fc3f@blastwave.org> References: <864EE1FC-1533-47D4-A395-C24F25269EE0@freebsd.org> <342c6a91-a8a1-483d-861e-8e8c6d79998f@blastwave.org> <9ea41e44-7160-40eb-9d80-b8bf13a7f396@mm.st> <0c09c6fa-7071-4119-b97e-fc6d83f9fc3f@blastwave.org> Comments: In-reply-to: Dennis Clarke message dated "Sat, 01 Nov 2025 21:48:56 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.1 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-ID: <31057.1762142092.1@eng-mail03> Date: Sun, 2 Nov 2025 19:54:52 -0800 Message-ID: <31059.1762142092@eng-mail03> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|DS0PR05MB9400:EE_ X-MS-Office365-Filtering-Correlation-Id: 752b3f45-3946-4803-f7d1-08de1a8cc114 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|35950700016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Dvc+8Ay/5ZTn1LYHQGPxrDmg6vCnIDZU3XUrk5cgpr1kUcDL4sv+MbWyFSZv?= =?us-ascii?Q?0aGMsM1P8WWrDOsQ/MinqRYvQedXCPXH2VTMv1rYlbgeFLLLHhU5pWt49gJD?= =?us-ascii?Q?7w5m135I/Tp73YfZhNUgs7imUgg9PYy7Xe2nEz8ri27hVYxqpAwzlTT7mh+i?= =?us-ascii?Q?G2+l6VVHUaPRAt9TtdSKm0zCEiMlZfO0L7W8JWxM2hqpJ+JxOkoaetLKOvEF?= =?us-ascii?Q?je6/20S/g/LQY/jnmuUGEiYoFCbk4IPEGhi6hCj/HH3mZUaAxeEmB140jd+q?= =?us-ascii?Q?2eng7Sdl/xftOGZOYvkZOwYVTKcgSpJSZbZLvOck5toYyzKuMrfz7+euv8S/?= =?us-ascii?Q?u8dteyxJVRqFkISqrpHqCZ9J8uzVNJiJwtlU1DjGz51SvlGWU/vxxd+Au3II?= =?us-ascii?Q?DIe6XvLninqjVur57pxlCuh4OjkfTYrNpyyi7h4BuTJSw5ZqU+Ah39ASp6GW?= =?us-ascii?Q?kWyvgnBQBDkJ3Xk/WXAgHSmdxwagGZzaYvo9tMdiT2NwB/DL+X5GH91Ms78S?= =?us-ascii?Q?cSY73AUIWZEoVrfkqsxnsGPvxNv8P2eGfTqwzmrY+MTm7Zz8BLVVFl+AaOka?= =?us-ascii?Q?D8H6BIlNQU8lAl12XZwweeuC++rnhumNKTxs68qTVzU8PnAR2k/M0lJbsJe6?= =?us-ascii?Q?y7MrXjPySpMKLRTI5Ge+e5aO4TrBUqLnpMYsoPsTv1e9ljuASiByhRFz/HWp?= =?us-ascii?Q?7LdHCss2Dpl6DYZ8DtXClLVM8IEIZLSEOIzFOxYeYQFMMXb2yVQq5LSO+rvj?= =?us-ascii?Q?AulK+YMAzY6ixyA3USLfxfgEPsvKU41RJEqOa+GggCB/CWH/twdP/AWPg91u?= =?us-ascii?Q?e5zwUwtRT/cxQjelJzZnO323ws0dzyXD3qOynYSI19Z2tI31RYXOAd4Oh46W?= =?us-ascii?Q?1Qq2NzcBjfooI5lyBZbaXybd7nksTVJx3gHN9dtIUJk/dw0FvjTocbz/O+Sn?= =?us-ascii?Q?qZIicV1Tvya8T+ji8TilYY3ndEwfh7h03Ssc7N7TJmTRC83/KrbU8I8kl2VB?= =?us-ascii?Q?NUEo4YUjg93buGy3VftxO1gECMbjTUiXUJUxDqbfW2D/hkts1lmGektrt0zS?= =?us-ascii?Q?Op7fMW3TFXjJRpOT3H/Qy2XmhuSWuzCP+3wepaZQSQ5M2wNB1gWbkrmFmjPO?= =?us-ascii?Q?AAUnb3oyo/c7fbw+O3O8ix2ejWSVl16wxa0BrhzZmeOiy2JHMkbgreUNghIs?= =?us-ascii?Q?rX4JQ6IhVWAU2T9RA+Ijftvvq1/w2AbQfvz3E6MtL7+s0k0ky5WX66V6Cb70?= =?us-ascii?Q?oJcNzCIDR/FsrFsVPCkHvcauxPa7H6oHU+mbtTA3MzIWTVOTezcs7j7pSNd2?= =?us-ascii?Q?VWVbR75P0aaFoykzLEpMFk7PjHiwfGFG3o5TWVZK7T1bxIcybIopIsFWGzK7?= =?us-ascii?Q?TJ3/1aF5bUmMFjWEChSSwrOgTVSLexu05WH9r/QFGcQFBSJdPjP1EA41espJ?= =?us-ascii?Q?g+OBvtb8HUrwwxkwsb4k7m8MH65m3abGzs9Qb3uA99R1Jxz3yX6GRND/f35e?= =?us-ascii?Q?sh/8yUkSIS9ULTc=3D?= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(35950700016);DIR:OUT;SFP:1101; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2025 03:54:56.9262 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 752b3f45-3946-4803-f7d1-08de1a8cc114 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF0000000C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR05MB9400 X-Proofpoint-GUID: di5ho_M04zJ8bTHV5Wy60BSPN7ZxW167 X-Proofpoint-ORIG-GUID: di5ho_M04zJ8bTHV5Wy60BSPN7ZxW167 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMTAzMDAzMyBTYWx0ZWRfX2noQDCsDlHIx 2lwM1+1PjMe15/h+orEHzSjtSc+s8vSApZ/hsxUjuRn6/x5HOtBgeYnX9BWbmcYIALLnrxfkDqk Kd6YabMGl0Vs/9D/+nwHL324Yvk1jhOVxGlEMJy/X2N5tC/bmjj0ZmqOgXNIQSoA4R4cODz9r2J qgrfXkKgeqzmFZ/SehBfml/cDowFBS4UKZ/daB34lA9xXOIZxxhqNRUtbchDOexa7pRoTxyo4zO erV3ONLHn7Kyb00vf3YYvaak/sY4BNuo7eF38TUVJArSI6+RFub8qzM2Y9nRm8slqQ7Y75xH0vx u2Q44bIkY6lhufcD9JPd0FOqZFPV2GCtjl1yDxao77mKrjv7V66yQ7aL6JQZdfr4Wstgt2/Tigz XJFcWVd8qWowUOJjRgmWeddKGAO+lw== X-Authority-Analysis: v=2.4 cv=IPcPywvG c=1 sm=1 tr=0 ts=69082794 cx=c_pps a=9z8yexD6E2gW5LInT/Y/IQ==:117 a=f/rncuQqEjTEF/G1odkJ9w==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=nzlzuQcQTLV5zrUS:21 a=kj9zAlcOel0A:10 a=6UeiqGixMTsA:10 a=s63m1ICgrNkA:10 a=rhJc5-LppCAA:10 a=VkNPw1HP01LnGYTKEx00:22 a=0depPUPBAAAA:8 a=ZoZ7At24RKuzUF0RL44A:9 a=CjuIK1q_8ugA:10 a=9Mj9kZDtLjIA:10 a=uu40koo1Yu1oziLcvR5q:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-11-02_02,2025-10-29_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 suspectscore=0 clxscore=1011 priorityscore=1501 spamscore=0 malwarescore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2510240001 definitions=main-2511030033 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector10001:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; FORGED_SENDER(0.30)[sjg@juniper.net,bounces@junipernetworks.onmicrosoft.com]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[208.84.65.16:from]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[SRS=7YfAi=5L]; R_DKIM_PERMFAIL(0.00)[juniper.net:s=selector1]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_POLICY_ALLOW(0.00)[juniper.net,reject]; FROM_HAS_DN(0.00)[]; DKIM_MIXED(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[sjg@juniper.net,bounces@junipernetworks.onmicrosoft.com]; DKIM_TRACE(0.00)[juniper.net:+,juniper.net:~]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US]; R_SPF_FAIL(0.00)[-all]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_SEVEN(0.00)[11] X-Rspamd-Queue-Id: 4d0Hm95CbWz3Kgm Dennis Clarke wrote: > Those both hide the CTRL-C "^C" chars ? pdksh displays ^C after return, but not otherwise it seems bash always displays ^C zsh - too annoying to try ;-) From nobody Mon Nov 3 09:12: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 4d0Qpr29z4z6FDf7 for ; Mon, 03 Nov 2025 09:12:52 +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 4d0Qpq582hz3pRC for ; Mon, 03 Nov 2025 09:12:51 +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 5A39CWur032804; Mon, 3 Nov 2025 18:12:33 +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=1762161155; bh=ZzFeoS6phL2soUfIQjqRkMFczi0xp+mjPRlOvEjlN4g=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=rcqPwXs2XlHlwEXlLc1MSW1EuftCKGKpUz1IovkhwTod8ImEVgma+py9I95ULE7CH m8bwOGhpF+wDMWgRbPq6ZvghDFawoYmlfh4YyJh05CYQLDK3+fFegu+DYEZ08mkngz B6GDZ/NX/pEH221UmEHTMSckLJUA2GZCZ8qOwg+U= Date: Mon, 3 Nov 2025 18:12:32 +0900 From: Tomoaki AOKI To: Chris Cc: Lars Tunkrans , Sulev-Madis Silber , freebsd-current@freebsd.org Subject: Re: Why is the DVD image so large? Message-Id: <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> In-Reply-To: References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 4d0Qpq582hz3pRC On Sun, 02 Nov 2025 16:09:27 -0800 Chris wrote: > On 2025-11-01 13:01, Lars Tunkrans wrote: > > Den 2025-11-01 kl. 17:19, skrev Sulev-Madis Silber: > >> > >> On November 1, 2025 4:06:48 PM GMT+02:00, Dennis > >> Clarke wrote: > >>> Why is the DVD image so large? Can something/anything be trimmed out? > >> it's kind of funny > >> > >> because cperciva was just asked to fill up the apparant "empty" wasted > >> space seen in beta3 dvd > >> > >> which he did! even overachieved the task slightly, apparently? > >> > >> so in order to not generate full war we would need to either cut back, > >> remove or abadon actual dvd size in some images > >> > >> or maybe make image remotely or locally customizable > >> > >> or provide separate images (tiny, medium, huge) which are just offline > >> repos > >> > >> or finally start shipping images with various de's which users ask but > >> which can't be easily done as disks don't self-expand. and then you need to > >> archive it all too > >> > >> or something else > >> > >> p.s.: btw, i was not able to install ports from b3 dvd for some reason, i > >> didn't check why and completed the test setup from remote > > > > HI > > > > Yes I started this ..... > > I notices that B2 did not include the DVD: ./packages/repo directory and > > contents. > > this was fixed in B3. but B3 was Void of KDE packages. B4 now have KDE > > packages > > but is 4.8 GB , > > I propose to abandon DVD 4.7 GB format and that future DVD-ISO packages use > > DVD-DL > > 8.5 GB discs. > Why stop there? Why not abandon DVDs entirely and require 16GB and require a > 16+ GB thumb drive? > IMHO The easier for someone to get FreeBSD on their target, the better. It > used to be on CD. > Now it's available in DVD. But why restrict it to the largest DVD possible? > > > > Regards > > -- > There is no such place as the internet Another option (far more difficult, though) would be switching to Blu-ray disks. Why difficutlt? Because it would be strongly expected supports for newer UDF that BD requires, if official BD image is provided, even if the media is actually in ISO 9660. And UDF support on FreeBSD is outdated that cannot mount BD. Regards. -- Tomoaki AOKI From nobody Mon Nov 3 11:31:42 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 4d0TvP6dMgz6FYJx for ; Mon, 03 Nov 2025 11:32:01 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 4d0TvP4jGkz41X8 for ; Mon, 03 Nov 2025 11:32:01 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-7864cef1976so40648267b3.0 for ; Mon, 03 Nov 2025 03:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1762169516; x=1762774316; 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=+tNOH0M6Jb3qOy0nUnDxomPaSmE2oLJh8qWRT41wODQ=; b=DsUDdwv8geOx8UCS+/tQv8w6an5XN0vSI+tSgnYNYKIzyIt9yoEIhjuAfM8KVGfLNo q6mo25/y0CiU7OPXhKcbaf62Eq8Yd82Yvs1wW+Ak84WoCL82Em7lXiwXwWcPemoxJbmu vxBmtfhg1VPOVL5O2zRZZnNmiyh3L+7b+55QG6wxItxTRCA2f4F1Jv57mARrieiQezKZ 1cgUztJHTF73XNh39G2XcemmBVpyBAXWaGf9e7UjRzGIGSQw3THsu31yZRZxQJ/4ZlUD FmB6OVQndjDewO8iiG7uv80WJX7TAWoQboE8Bwa33K7Dwhgr0dVSJ1LU3noemsFua3IY 5q8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762169516; x=1762774316; 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=+tNOH0M6Jb3qOy0nUnDxomPaSmE2oLJh8qWRT41wODQ=; b=plftB3Bzdv7adViQxvfokFoYg/CuxqJkBfe0lGIAumrq4i+qz+d0pIBY/ni2HIDpZ1 rpY54EQxjMek8gdFH82mgqNar0xOMqhqBOk/IpstQpC6TAKlR5PCXtv6BLQZNw2/8QUG dCYL4WQ6eRbJ/Ce0Vfv9lSOasD5DmfjR6uTwlyoQcedFfYAM64eOFvp/+bJ/2Rtxm6o1 FXw3UjX7Nl3usRX757YYmshNDiwKQ99edayVZu1JLp+BVRAIjbrAmnKAdKIFe52LBc5h kW9/+bqEKp0M5g8BtvmaaUGZqxxW0oOvBDjVy32czSLIZVBzK9fPWTjzrYldw5EDz8Um d+rg== X-Forwarded-Encrypted: i=1; AJvYcCUTHlcb6eOvsAfdV7OxUToJik9BFhc+ZXLbW+YI/wDyMBmIaveRBp9EVl7iuIZL41YfpIAWUaGAZfHByd6SY5Y=@freebsd.org X-Gm-Message-State: AOJu0YynslQo+HaAxXf+nPZAAW3KlGbcbVmSotsUsOSJ1Pc+x/Pxvp42 TRXywoY7sxKbPnIkmLmZu6sQ0KA0okFUitwJideJAPifwOoHZ3LxqWwYgA1sV/HLiN9yAWvWDDr mFh8= X-Gm-Gg: ASbGnctBp5+Rr4+kZ0uLShhlY9H54aPYq3xWItHOvPJZnkb7vhNG+OtizfuDIf9g4rg 5BP95RxJel9hF8PzS9it0dm4gPMorLwkrc2nCkXYCDFxgPfdZzRivVGS6pqfSBwg2I9uG+BHrUO v/bOjg5JC3DzBf4TSzxDCK5OR5h597rKytym4IqPDVN/NdSCb5jnK0oIDaehw9Yxs81Tp4sizrD 6wlR7Jlem7+UCq8Oj85gW/hD9AriSEnJ41/d7ppsaDXUL+sGu/Lrc1EcnGlnlugHLLJKmH7bcUL Io7ZO+7bspuAnICp1B1ogQLRHmxgzVrSOcgZr5vtTelAMmuWu3EAnicUjkKLfoOh/raoQ/eUMnx XmJObXXcOLFHFTIPbU5XsfjtHNjtoLEQMSRaFDPSElrpChgeq45VK/ZiSji1SMR/PmO7R8fRVbV qzXkq0U43hp0kcwOKsZ7ZI/RoWG0yZ2ESM9xsP1QRHLqfhrNU= X-Google-Smtp-Source: AGHT+IGjJHKlJ0XA5Fir1Rs37PDejO3bdCuO6e+spfO0iLYdFLs2EJKZf3VSf8+wYbyiyIB0eX/mVw== X-Received: by 2002:a05:690c:62c4:b0:786:6066:128b with SMTP id 00721157ae682-786606633d9mr56503947b3.25.1762169515730; Mon, 03 Nov 2025 03:31:55 -0800 (PST) Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com. [209.85.128.173]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78686e2bd6fsm4618827b3.46.2025.11.03.03.31.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Nov 2025 03:31:54 -0800 (PST) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-7867497ad2fso12075447b3.0 for ; Mon, 03 Nov 2025 03:31:54 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXvE+juxE/YSLgJdzcd6Y34l58Uoz5LnDiETwm4mlXBzUjbewExbBTCX2TvK37gWds8IvEYejr/hdrBosKVD3I=@freebsd.org X-Received: by 2002:a05:690c:a9c:b0:784:8bcd:4082 with SMTP id 00721157ae682-78639050225mr132541257b3.35.1762169513962; Mon, 03 Nov 2025 03:31:53 -0800 (PST) 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: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> In-Reply-To: <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> From: Tomek CEDRO Date: Mon, 3 Nov 2025 12:31:42 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_blVQkYwvMlbxyw0NqiobIhCytYolPoK50OZ0ptW3YIxrhYl8Swnjo1OxYY Message-ID: Subject: Re: Why is the DVD image so large? To: Tomoaki AOKI Cc: Chris , Lars Tunkrans , Sulev-Madis Silber , 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)[]; 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: 4d0TvP4jGkz41X8 On Mon, Nov 3, 2025 at 10:12=E2=80=AFAM Tomoaki AOKI wrote: > Another option (far more difficult, though) would be switching > to Blu-ray disks. > > Why difficutlt? Because it would be strongly expected supports for > newer UDF that BD requires, if official BD image is provided, > even if the media is actually in ISO 9660. And UDF support on FreeBSD > is outdated that cannot mount BD. Hmm I have two 5.25" SATA BD recorders (Pioneer and Asus) using them for backups with BD-R (25GB) and BD-R DL (50GB) and BD-RE DL (50GB rewritable) disks with no problem. Also tested external USB BD recorders work fine but a bit more expensive (looks like Pioneer in Europe is sold by Verbatim?). These are not that expensive and can burn dvd, cd, and mdisk too. Because DVD-RW-DL are hard to find I just bought whole bunch of BD-RE DL and use them in cycles no to waste plastic. For clients with one time use BD-R and BD-R DL are fine and cheaper. I trust Verbatim disks as there are many different types of physical medium just marked BD-R* but burner firmware must support them to write correctly. You just need to create hybrid ISO9660 + UDF (plus -iso-level 3 or 4 if you have single files over 2GB) with mkisofs and then burn the image with cdrecord or just growisofs or k3b or whatever you prefer. Then if you mount it with mount_iso9660 files looks a bit weird, but if you mount_udf all looks fine. But this does not seem the case for FreeBSD installer as it is simple ISO9660 not even UDF nor hybrid :-) I also tend to use mdconfig to mount iso and compare files inside iso with files to backup before burning just to make sure all landed as expected (i.e. sometimes i forget to add -iso-level 3 so big files are gone). Then disk verification with iso can be performed after burning. I found VENTOY [1] extremely helpful because it allows having many ISO files on a single USB drive and choose one from its boot menu, it supports BIOS and UEFI boot, adding boot keys, and other utilities.. so there is no need to have single usb drive per iso anymore just one usb drive with many iso :-) [1] https://www.ventoy.net/ ps/2: What I really miss about UDF implementation in FreeBSD is modern version support with R/W access so we could just use UDF filesystem as standard platform independent disk format (i.e. for pendrive in place of fat32 / vfat /ntfs). But other systems also have this support varying in version support and on the fly write so this is Universal Disk Format only in theory and still mainly used for optical disks :-P --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Nov 3 12:59: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 4d0Ws22WFkz6Fhkt for ; Mon, 03 Nov 2025 13:00:06 +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 4d0Ws15TCnz3DNn for ; Mon, 03 Nov 2025 13:00:04 +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 5A3Cxm0K058561; Mon, 3 Nov 2025 21:59:50 +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=1762174791; bh=3wrITUshyn3DXHFD5G8seo3Ohppu1go9mVjUUF5Ulr8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=m1jOMjg/ExEj/do659JuTqVaIWWEPbS8dB2f3HlCM07X9H2mhQOijF//3qihKu0nG nm1H9rV6p29/2KcIbGo/4/BjxPPuuo9HNJnIbnOb4hnMH98sKLUyZDbJ1mWyBsZhQ7 1DbfebGmUQnV4DjD4zqTGa/fAXyQMCnh8T96C/kE= Date: Mon, 3 Nov 2025 21:59:48 +0900 From: Tomoaki AOKI To: Tomek CEDRO Cc: Chris , Lars Tunkrans , Sulev-Madis Silber , freebsd-current@freebsd.org Subject: Re: Why is the DVD image so large? Message-Id: <20251103215948.e6702b0314189b0943503e58@dec.sakura.ne.jp> In-Reply-To: References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.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 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: 4d0Ws15TCnz3DNn On Mon, 3 Nov 2025 12:31:42 +0100 Tomek CEDRO wrote: > On Mon, Nov 3, 2025 at 10:12 AM Tomoaki AOKI wrote: > > Another option (far more difficult, though) would be switching > > to Blu-ray disks. > > > > Why difficutlt? Because it would be strongly expected supports for > > newer UDF that BD requires, if official BD image is provided, > > even if the media is actually in ISO 9660. And UDF support on FreeBSD > > is outdated that cannot mount BD. > > Hmm I have two 5.25" SATA BD recorders (Pioneer and Asus) using them > for backups with BD-R (25GB) and BD-R DL (50GB) and BD-RE DL (50GB > rewritable) disks with no problem. Also tested external USB BD > recorders work fine but a bit more expensive (looks like Pioneer in > Europe is sold by Verbatim?). These are not that expensive and can > burn dvd, cd, and mdisk too. Because DVD-RW-DL are hard to find I just > bought whole bunch of BD-RE DL and use them in cycles no to waste > plastic. For clients with one time use BD-R and BD-R DL are fine and > cheaper. I trust Verbatim disks as there are many different types of > physical medium just marked BD-R* but burner firmware must support > them to write correctly. Writing ISO9660 into BD* media on BD drive would be fine if the drive is actually recognized as "writtable". I've never succeeded writing anything usign USB BD drive on FreeBSD yet, while reading ISO9660 and DVD in pre-BD version of UDF are fine and DVD videl playback is OK on the exact same USB BD drive. I had chance to try reading backup BD-R written by BD writer running on Windows (can read its contents on Windows) on FreeBSD, without success (too old UDF support). Maybe newbies who noticed a BD media (even though it's actually formatted in ISO9660 or old UDF) is accessible on FreeBSD could think that FreeBSD can at least read every BD disks unless the disk is encrypted, which is not true for now. > You just need to create hybrid ISO9660 + UDF (plus -iso-level 3 or 4 > if you have single files over 2GB) with mkisofs and then burn the > image with cdrecord or just growisofs or k3b or whatever you prefer. > Then if you mount it with mount_iso9660 files looks a bit weird, but > if you mount_udf all looks fine. But this does not seem the case for > FreeBSD installer as it is simple ISO9660 not even UDF nor hybrid :-) > > I also tend to use mdconfig to mount iso and compare files inside iso > with files to backup before burning just to make sure all landed as > expected (i.e. sometimes i forget to add -iso-level 3 so big files are > gone). Then disk verification with iso can be performed after burning. > > I found VENTOY [1] extremely helpful because it allows having many ISO > files on a single USB drive and choose one from its boot menu, it > supports BIOS and UEFI boot, adding boot keys, and other utilities.. > so there is no need to have single usb drive per iso anymore just one > usb drive with many iso :-) > > [1] https://www.ventoy.net/ > > ps/2: What I really miss about UDF implementation in FreeBSD is modern > version support with R/W access so we could just use UDF filesystem as > standard platform independent disk format (i.e. for pendrive in place > of fat32 / vfat /ntfs). But other systems also have this support > varying in version support and on the fly write so this is Universal > Disk Format only in theory and still mainly used for optical disks :-P > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Exactly. It would be wanted, but maybe lower priority than cutting edge GPUs and WiFis. Regards. -- Tomoaki AOKI From nobody Mon Nov 3 14:35: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 4d0Yzd6XG7z6Frvb for ; Mon, 03 Nov 2025 14:35:57 +0000 (UTC) (envelope-from jhb@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 4d0Yzd5lsXz3SK8; Mon, 03 Nov 2025 14:35:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762180557; 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=NB2kdwKLOWDDWrU5XssATcoNXd4k1iJCljTRSfzXlmI=; b=JH4DD2IU7vqsum2U0ns2d4VyesAro/nxrIeGZ++L/DCPQrm3WNpV8AJ+2yAuO0MiQHyx6K RqQAwa0ShvJElGR5xefdN7qzCDsFF3PqXagPtlr4Xvqdfwbf2wZlvMO0PZf5QkPwVZy+4w wGjTr29glfVK2++TP/OunHk0Fhs8C+KiPdvLSJEP4UgW6j76Nnu0FwMyTwykb99/zSGfNO zPTO5TNAnmdYazPWaz18tlGrHgdk3r92a/+K0cjyJ4+zfSLXbhQTj473h+4CbwpjeinGQr 1zveDhkej1Ar4Jaq4dXGLt8teVDzCo8AD2+S/5Ibr/VOHlgYFea9LTYOPX/oGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762180557; 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=NB2kdwKLOWDDWrU5XssATcoNXd4k1iJCljTRSfzXlmI=; b=wwzJNnE9E+WMqc3r7S/SJp6aFRtfJo9/xpMgVZZz8Ad2W60tVcBLPVlN0wMZDRB7sJiCux LCuuCh8GO/vgO6PeBDNjy9TtcRKBNryBmo/yMDKNBiX6n//vwZtLfeuvnXf2HeIx2EGu9i jlRc5xDI6upsjkWPugD4v6imd5BbURvqb0h2Vu9HuKI1hLr3ppOmL24KZpJj/0U4Wme8Sj m1kFS42mTq9n+Z3GSsbqd0vzXHL8IP6K1SX8C/gMK0j492CJJGtyh2oYAWlV+I6c5/nIS3 oX8cwDQjULubBClloUp5l0mxVhL2Vmg792J5/zdlEq++RqhOm/BGXG/eB3Twhw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762180557; a=rsa-sha256; cv=none; b=S1D/eOGNVqhm7+Mc3djc5n4yyNm97wHFM7PSbF9Y82RQib9+IkcmFbiMFQmXsj/GEZMc/W V8QoNhjFgqigT6hehRWHw4aVNAeGsj7a6kw/Id9vNMzewhlVWfI/msjAV5pshly1yOCYoN ArybOMHgxsvP0dBiYPmr+1BF5HzyjsbmAwfTu0zosWVh8mlP55uGrA3g7dvNSDKVLa/yBE 3X2UtgRPLaMwmFX2CJgeiKL0xNgC+UvK1NNqLtVAvsz1EiwTuL8xm0Utc8WUYSEYzE4/hV O0i9iGb1hHiak+QbC4LfaNnWA8pIzf4ANbP1zyRSApDIF8DocccN/TB766ga4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5c0:4202:5670:ac49:a53f:963:aaba] (unknown [IPv6:2601:5c0:4202:5670:ac49:a53f:963:aaba]) (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: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d0Yzd2ZFcz17CP; Mon, 03 Nov 2025 14:35:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 3 Nov 2025 09:35:56 -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: RFC: NFS over RDMA Content-Language: en-US To: Rick Macklem , Konstantin Belousov Cc: FreeBSD CURRENT , Navdeep Parhar , "erj@freebsd.org" , "aehrenberg@nvidia.com" , slavash@nvidia.com, "sreekanth.reddy@broadcom.com" References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/1/25 17:26, Rick Macklem wrote: > On Sat, Nov 1, 2025 at 2:10 PM Konstantin Belousov wrote: >> >> On Sat, Nov 01, 2025 at 02:03:59PM -0700, Rick Macklem wrote: >>> On Sat, Nov 1, 2025 at 1:50 PM Konstantin Belousov wrote: >>>> >>>> Added Slava Schwartsman. >>>> >>>> On Sat, Nov 01, 2025 at 01:11:02PM -0700, Rick Macklem wrote: >>>>> Hi, >>>>> >>>>> I've had NFS over RDMA on my todo list for a very loonnnggg >>>>> time. I've avoided it because I haven't had a way to test it, >>>>> but I'm now going to start working on it. (A bunch of this work >>>>> is already done for NFS-over-TLS which added code for handling >>>>> M_EXTPG mbufs.) >>>>> >>>>> >From RFC-8166, there appears to be 4 operations the krpc >>>>> needs to do: >>>>> send-rdma - Send on the payload stream (sending messages that >>>>> are kept in order). >>>>> recv-rdma - Receive the above. >>>>> ddp-write - Do a write of DDP data. >>>>> ddp-read - Do a read of DDP data. >>>>> >>>>> So, here is how I see the krpc doing this. >>>>> An NFS write RPC for example: >>>>> - The NFS client code packages the Write RPC XDR as follows: >>>>> - 1 or more mbufs/mbuf_clusters of XDR for the NFS arguments >>>>> that precede the write data. >>>>> - an mbuf that indicates "start of ddp-read". (Maybe use M_PROTO1?) >>>>> - 1 or more M_EXTPG mbugs with page(s) loaded with the data to be >>>>> written. >>>>> - 0 or more mbufs/mbuf_clusters with additional RPC request XDR. >>>>> >>>>> This would be passed to the krpc which would... >>>>> - the mbufs up to "start of ddp" in the payload stream. >>>>> - Would specify a ddp-read for the pages from the M_EXTPG mbufs >>>>> and send that in the payload stream. >>>>> - send the remaining mbufs/mbuf_clusters in the payload stream >>>>> >>>>> The NFS server end would process the received payload stream, >>>>> putting the non-ddp stuff in mbufs/mbuf_clusters. >>>>> It would do the ddp-read of the data into anonymous pages it allocates >>>>> and would associate these with M_EXTPG mbufs. >>>>> It would put any remaining payload stream stuff for the RPC message in >>>>> additional mbufs/mbuf_clusters. >>>>> --> Call the NFS server with the mbuf list for processing. >>>>> - When the NFS server gets to the write data (in M_EXTPG mbufs) >>>>> it would set up a uio/iovec for the pages and call VOP_WRITE(). >>>>> >>>>> Now, the above is straightforward for me, since I know the NFS and >>>>> krpc code fairly well. >>>>> But that is where my expertise ends. >>>>> >>>>> So, what kind of calls do the drivers provide to send and receive >>>>> what RFC-8166 calls the payload stream? >>>>> >>>>> And what kind of calls do the drivers provide to write and read DDP >>>>> chunks? >>>>> >>>>> Also, if the above sounds way off the mark, please let me know. >>>> >>>> What you need is, most likely, the infiniband API or KPI to handle >>>> RDMA. It is driver-independent, same as for ip NFS you use system IP >>>> stack and not call to ethernet drivers. In fact, most likely the >>>> transport used would be not native IB, but IB over UDP (RoCE v2). >>>> >>>> IB verbs, which is the official interface for both kernel and user mode, >>>> are not well documented. An overview is provided by the document >>>> titled "RDMA Aware Networks Programming User Manual", which should >>>> be google-able. Otherwise, the Infiniband specication is the reference. >>> Thanks. I'll look at that. (I notice that the Intel code references something >>> they call Linux-OpenIB. Hopefully that looks about the same and the >>> glue needed to support non-Mellanox drivers isn't too difficult?) >> OpenIB is perhaps the reference to the IB code in Linux kernel proper >> plus userspace libraries from rdma-core. This is what was forked/grown >> from OFED. >> >> Intel put efforts into the iWARP, which is sort of alternative for RoCEv2. >> It has RFCs and works over TCP AFAIR, which causes problems for it. > Heh, heh. I'm trying to avoid the iWARP vs RoCE wars.;-) > (I did see a Mellanox white paper with graphs showing how RoCE outperforms > iWARP.) > Intel currently claims to support RoCE on its 810 and 820 NICs. > Broadcom also claims to support RoCE, but doesn't mention FreeBSD > drivers and Chelsio does iWARP, afaik. > > For some reason, at the last NFSv4 Bakeathon, Chuck was testing with > iWARP and not RoCE? (I haven't asked Chuck why he chose that. It > might just be more convenient to set up the siw driver in Linux vs the > rxe one? He is the main author of RFC-8166, so he's the NFS-over-RDMA guy.) > > But it does look like a fun project for the next year. (I recall jhb@ mentioning > that NFS-over-TLS wouldn't be easy and it turned out to be a fun > little project.) Konstantin is right though that sys/ofed is Linux OpenIB and has an interface that should let you do RDMA (both ROCEv2 and iWARP). I'm hoping to use the APIs in sys/ofed to support NVMe over RDMA (both ROCEv2 and iWARP) at some point as well. > rick > >> >>> >>> Btw, if anyone is interested in taking a more active involvement in this, >>> they are more than welcome to do so. (I'm going to be starting where I >>> understand things in the krpc/nfs. I'm not looking forward to porting rxe, >>> but will probably end up there. I have already had one offer w.r.t. access >>> to a lab that includes Mellanox hardware, but I don't know if remote >>> debugging will be practical yet.) >>> >>> rick >>> >>>> >>>> The IB implementation for us is still called OFED for historical reasons, >>>> and it is located in sys/ofed. >>>> >>>>> >>>>> As for testing, I am planning on hacking away at one of the RDMA >>>>> in software drivers in Linux to get it working well enough to use for >>>>> testing. Whatever seems to be easiest to get kinda working. >>>> Yes rxe driver is the sw RoCE v2 implementation. We looked at the >>>> amount of work to port it. Its size is ~12 kLoC, which is compatible >>>> with libibverbs (userspace core infiniband interface). Interesting. I'm currently working on merging back several OFED commits from Linux to sys/ofed (currently I have about 30 commits merged, some older than Hans' last merge, and some newer, some of the newer ones should permit removing compat stubs for some of the newer APIs that are duplicated in bnxt, irdma, and mlx*). When I get a bit further along I'll post the branch I have for more testing (it is a bunch of individual cherry-picks rather than a giant merge). Porting over rxe could be useful for me as well for some work I am doing. -- John Baldwin From nobody Mon Nov 3 15:45:24 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 4d0bX45WQjz655NT for ; Mon, 03 Nov 2025 15:45:40 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 4d0bX43N6sz3bxk for ; Mon, 03 Nov 2025 15:45:40 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-7866aca9ff4so15055497b3.3 for ; Mon, 03 Nov 2025 07:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1762184738; x=1762789538; 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=NlygEmeB1Rv2BX8d59p89eItQSqOHfw5ovpyG4yOl7w=; b=RFVoptLXMRo2lK3T+TGFo2GBDLBLfk+iT197nz2piMWvRbI2G07Wyb6ys5IW0BDjJ2 pw4GaoxbLK0DYwcK3ScGo54UgRavwhsbNqmWITrHNHIkBwxsTk6tkbMZE8Zbij6NXU1o xE7YIJe7YrOMpxDhFnRnEyGT+ON1TiIHxqmJ4r2LNYD7n/w7AFn+ctF/FzUwjQ5uqYqz NleruC9dHA6GnmBWHcHTA+TygqfrNC+Yv3zmFrD4vJ8JKWnfGtPXMv3zmj+sjFtyQk3/ KJQL9XvERAh2aKz6QPm8GcC9T7xSsGcsiemXHv2MVaCssOupsAZg2WuZcT30LJJ7P6/p fmnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762184738; x=1762789538; 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=NlygEmeB1Rv2BX8d59p89eItQSqOHfw5ovpyG4yOl7w=; b=NYQeS8qZ6U1S+jei3z3u7q46f/gWyW/8IcrwCQXAlu953Sk8sMAVkh5P2qo6va13IA 4Unk0xTxqiKkI9Z9z/4ME9KCP0Xvyvdz7bQSQLg7LBlbw5FFBa7kWmVGD7xQe4bEIY1t 9zC9dusGEyVvbE5eUlN1YspHFgRTflacLaGHeDl6cOm8ayOwxwtIyhWOaY/X9lFfc09s WtcDCU4nfvMRLAaPJuZVaS+wAJQR8xUucTbnje/UwJqUYeC+UKmej93QsoHxQmGD+osO 1OKF7B/AByvvxFyD1JFSofrT0YxKO841UCHWTbmceRESidzBR3Xtij3qkrMOQqoYdKVa 4cAg== X-Forwarded-Encrypted: i=1; AJvYcCXsUJDLaPxtCcxiG8pyJuGKYgFBB8SPaMfjBK2WIVyZ2Wo8Fh1KM3PrbghtfCUwvRckkE7UKDSez0aj6U5gGMA=@freebsd.org X-Gm-Message-State: AOJu0Yy9WHleHzXZNAOcFQFpmvJL5eqmENUxgGO5ZugypR/PgHXkFB8j z373lL4VQ0/fIP3Hfka0ZOokzs9w/DltWn8Q41cVynIoqUsi5SmgSj5d32ixl5knd8l7zjQqp4y QKYg= X-Gm-Gg: ASbGncs+ipmK2mxPeM760QFRi4QlxC8oLC723172fw176GqhwNGbM3SJkAsJ1NE8U4R OoQqUD7Otvj2kCwNJthQcjRTDbG5lmeZOYrPIt32pesPZI8LS6sqLq4NEElobwsddHkFZuWhVKH nIikyHFM5DQUVFRR6THg9wRdDF4K6UzBz85UZD+pDPhuyIsqmbxK75gg9ZwfJcXGTfg6J36JhNq t4N9itQHAYZHFv21viJD8YHjd/7U/D01q1wyJmqFW3DfvMsP1s6eeasUZMXwsyBlxRxsXptUf7o D61MEbJ7uxJgWi+N35WJIBN2d4HkjKdyK04UDNRljhoDOXlEbOMs3JxWHF2tKd/3YlxdHBYKg+5 H0ZKTp5JZCsNJ6SHZc4bUugCDaJJuUwqbyj/zg1AH2XASOwrmd950moLWXy25/Jn6q4XSnnAz/u Hwsc/mS8x2hQjaem8tNpbHR/EAT2mBFD5qYs3F X-Google-Smtp-Source: AGHT+IH2GEufvypIKQH9k0bDRzn3SrcA6fr2ZoDpRBpNyC62MasmaW6ZsQHrX/EQXA911lX97n87hw== X-Received: by 2002:a05:690c:7444:b0:786:6b92:b200 with SMTP id 00721157ae682-7866b92b3b3mr62418177b3.30.1762184737653; Mon, 03 Nov 2025 07:45:37 -0800 (PST) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78691fd9a86sm1585027b3.28.2025.11.03.07.45.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Nov 2025 07:45:36 -0800 (PST) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-78677ff31c2so10577117b3.2 for ; Mon, 03 Nov 2025 07:45:36 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUjLnvSu/gJgqpYAusBc46GNrC1pi+cbgx0jff/jagoOYZkEeBR88pRYGTkq2FssbTWKIOz6mQr4ihKdV650PQ=@freebsd.org X-Received: by 2002:a05:690c:60ca:b0:786:2f01:16fb with SMTP id 00721157ae682-786483ffca3mr117373347b3.26.1762184735896; Mon, 03 Nov 2025 07:45:35 -0800 (PST) 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: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> <20251103215948.e6702b0314189b0943503e58@dec.sakura.ne.jp> In-Reply-To: <20251103215948.e6702b0314189b0943503e58@dec.sakura.ne.jp> From: Tomek CEDRO Date: Mon, 3 Nov 2025 16:45:24 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bluMwku27865l41dR9HLLNxcfhZDZr6mBmhzQxhBRJ7C2CQIiHnIm1p4_o Message-ID: Subject: Re: Why is the DVD image so large? To: Tomoaki AOKI Cc: Chris , Lars Tunkrans , Sulev-Madis Silber , 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)[]; 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: 4d0bX43N6sz3bxk On Mon, Nov 3, 2025 at 2:00=E2=80=AFPM Tomoaki AOKI wrote: > On Mon, 3 Nov 2025 12:31:42 +0100 > Tomek CEDRO wrote: > > On Mon, Nov 3, 2025 at 10:12=E2=80=AFAM Tomoaki AOKI wrote: > > > Another option (far more difficult, though) would be switching > > > to Blu-ray disks. > > > > > > Why difficutlt? Because it would be strongly expected supports for > > > newer UDF that BD requires, if official BD image is provided, > > > even if the media is actually in ISO 9660. And UDF support on FreeBSD > > > is outdated that cannot mount BD. > > > > Hmm I have two 5.25" SATA BD recorders (Pioneer and Asus) using them > > for backups with BD-R (25GB) and BD-R DL (50GB) and BD-RE DL (50GB > > rewritable) disks with no problem. Also tested external USB BD > > recorders work fine but a bit more expensive (looks like Pioneer in > > Europe is sold by Verbatim?). These are not that expensive and can > > burn dvd, cd, and mdisk too. Because DVD-RW-DL are hard to find I just > > bought whole bunch of BD-RE DL and use them in cycles no to waste > > plastic. For clients with one time use BD-R and BD-R DL are fine and > > cheaper. I trust Verbatim disks as there are many different types of > > physical medium just marked BD-R* but burner firmware must support > > them to write correctly. > > Writing ISO9660 into BD* media on BD drive would be fine > if the drive is actually recognized as "writtable". > I've never succeeded writing anything usign USB BD drive > on FreeBSD yet, while reading ISO9660 and DVD in pre-BD version > of UDF are fine and DVD videl playback is OK on the exact same > USB BD drive. > > I had chance to try reading backup BD-R written by BD writer > running on Windows (can read its contents on Windows) on FreeBSD, > without success (too old UDF support). > > Maybe newbies who noticed a BD media (even though it's actually > formatted in ISO9660 or old UDF) is accessible on FreeBSD could > think that FreeBSD can at least read every BD disks unless the disk > is encrypted, which is not true for now. > > > > You just need to create hybrid ISO9660 + UDF (plus -iso-level 3 or 4 > > if you have single files over 2GB) with mkisofs and then burn the > > image with cdrecord or just growisofs or k3b or whatever you prefer. > > Then if you mount it with mount_iso9660 files looks a bit weird, but > > if you mount_udf all looks fine. But this does not seem the case for > > FreeBSD installer as it is simple ISO9660 not even UDF nor hybrid :-) > > > > I also tend to use mdconfig to mount iso and compare files inside iso > > with files to backup before burning just to make sure all landed as > > expected (i.e. sometimes i forget to add -iso-level 3 so big files are > > gone). Then disk verification with iso can be performed after burning. > > > > I found VENTOY [1] extremely helpful because it allows having many ISO > > files on a single USB drive and choose one from its boot menu, it > > supports BIOS and UEFI boot, adding boot keys, and other utilities.. > > so there is no need to have single usb drive per iso anymore just one > > usb drive with many iso :-) > > > > [1] https://www.ventoy.net/ > > > > ps/2: What I really miss about UDF implementation in FreeBSD is modern > > version support with R/W access so we could just use UDF filesystem as > > standard platform independent disk format (i.e. for pendrive in place > > of fat32 / vfat /ntfs). But other systems also have this support > > varying in version support and on the fly write so this is Universal > > Disk Format only in theory and still mainly used for optical disks :-P > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > Exactly. It would be wanted, but maybe lower priority than cutting edge > GPUs and WiFis. Hmm, this update to at least mount and read modern UDF filesystem commonly used on the BlyRay disks sounds like a task for LDWG (Laptop Dekstop Work Group). Forwarding :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Nov 3 17:06:04 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 4d0dKd1Rvnz65CgG for ; Mon, 03 Nov 2025 17:06:45 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4d0dKc4mWmz3nSr for ; Mon, 03 Nov 2025 17:06:44 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=GcTrqluH; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762189598; bh=FT/x82YXDL73cx9S+jhc/5RsnvPQy/UGZWuJY1ckGHc=; h=Date:From:To:Subject:In-Reply-To:References; b=GcTrqluHxvdcard0a+f39EG+EBitCyF/CA6+qh179/+UtTrYEwH55svgq5aX+bQbU 0WeO9NUafJ/ooD4y+JW69+9qJhV/tNECx0hfnINRvrKO1Vz5uYuq635h42Z2fk/QNN resVFR9nbA7G1AKrsBUEU15YsbkWAVot9THNTyYNej9FkIaHxD2juIjicaAmZvpdtG 2fKSfoP7jU6FE8I78axGPBB24bsC42lVOfd/XL7rpkzBkOJ/2kjdV7kQJCahANUKB4 FMqqoZ7qe1BSASSJsY1zNm/BbLy21F46/k0Wq4lTnODwDLzXe57HwhAUFyUyn37sQC A0+1OXqTzuL0oLZNPike2Oo+NFm9Fjpk8HtK9VeWDtPwH471+k48h2UW5KceWu9qoa m4gF8tp0RUWj9G7CbJKAi4cKSdmTJXr15CQjepqXqcee0YpSx1aPsB4yNnhhXl2ODe UQ/vdhCVviyxeq0l7LYRSJh5RTpkLqjk4GYnyViTx/f9U+R3Vzyl36PaUBR8KNOHLk 0KuQyyl3a3sROP1PlnbAb//1YauXtl4XNbXif+y6ABR78Wb/9FxpenOAMCXaK2jKIT XclSDdj1XBHHO9iz6WG0S7VtGA0YBSpH9oG1kGJWDgxrjtKDUhxCkqzmOc4pMZ+xxM a4MGNYf5Q+u3F++E4BdQgsko= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 68D435C9A68 for ; Mon, 03 Nov 2025 19:06:38 +0200 (EET) Date: Mon, 03 Nov 2025 19:06:04 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: Why is the DVD image so large? User-Agent: K-9 Mail for Android In-Reply-To: <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> 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-Spamd-Bar: / X-Spamd-Result: default: False [0.21 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56:c]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4d0dKc4mWmz3nSr how much of the hw that the fbsd targets now, even has a physical place you= can insert any optical disk into? and which doesn't have at least usb2=2E0 port i proposed creating a "maxi" memstick too but i learned that memstick is w= anting to go away entirely=2E since you can use iso on usb=2E not always th= o, not very well the optical disks are most of cases readonly, they could retain data well,= could be pressed into permanent disk, would be allowed in high security en= vironments where usb would be not maybe i miss the optical use cases here, anyone give me insight? aren't the most of installers going into usb now, for temporary, which are= very fast now=2E very large, very cheap=2E they go past every known br siz= e, while being so small you can't it out of usb port afterwards=2E we are s= eeing usual sizes getting somewhere into entire whole terabyte range now wh= ich is insanely large for a installer consisting xz packed files i tried to ask a stupid question of are there anything with br reader you = usually see yourself installing to, but didn't find anything=2E esp=2E, any= servers oh and, you can make your own installer too, with contents and size as you= please=2E which i assume wouldn't be a problem if you obviously use fbsd t= hat much kind of side view to that iso too small too large too small cycle or at least we could leave dvd alone and could offer saner alternatives or whatever? From nobody Mon Nov 3 17:32: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 4d0dwG26dZz6F96f for ; Mon, 03 Nov 2025 17:33:18 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb134.google.com (mail-yx1-xb134.google.com [IPv6:2607:f8b0:4864:20::b134]) (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 4d0dwF71pXz3rlR for ; Mon, 03 Nov 2025 17:33:17 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yx1-xb134.google.com with SMTP id 956f58d0204a3-63f9beb26f7so2401325d50.2 for ; Mon, 03 Nov 2025 09:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1762191192; x=1762795992; 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=s1hrw/iY+q/FlK4FRDSj8ThQQrhaTvY8bJMelQsieS8=; b=MlbiTmdZ66r1i6B6IOpBr/xXI4RcgjW2cEPygW/tmXRpiLAg0AcKtHISlMWEsBvPHC qNgE7tvtb5bps2Dw1AaOFyg32fMbK+mKxlre08BUCaN8ZMZ2ROf9MsquX9pjBh4p6ww5 bes1PSX7qzbmPjYVuIrRIbetgT1Go/UYnbiW817Nc32zLjjBzEbxgb7mtGJDm7x1Dkpw rNfQSryscogbfj6WRiPqEtUn9zLO7wy6tshbqQAT4TQILC5HdjeOAEjAS4uzEM4AH/Fs iuvz34Jjel+oL/rM2E0845LjALB7yk/ZXm+c3RzVFFNcions6KmR6DcBhcZA73TCrAbZ f23w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762191192; x=1762795992; 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=s1hrw/iY+q/FlK4FRDSj8ThQQrhaTvY8bJMelQsieS8=; b=MutsX7cEKxl33LUUpGvasoM+f2rJyP4HVx+vBdUNTN6EvlNu1f78+omIB4ynK8DVtc UJ33Fp3Lkgxd6Kr+ikNOkYp3BIT5QtzDj2pb2eeE7rLTeJ42EZ9XiCModTU1dm+C2hPk kAAufkC6G5n0lMespZ2gBCCeXMUNRk3/bc3h1u3VM+sm4BqIWLZbZnxUNoTerphvzt8y jzj3e8prGPuE0+/CoULSKhro78bDtk17jx45Ad4RaxIW6aLsa0f7knA6SkDnWkTIn7go YBQwtEDwCSd7aDlS90xwJTfeOSt3fuqms27L8h7wxks4Q2iL7Si7LGX5JXpa8T549oMq LQnw== X-Gm-Message-State: AOJu0YyFfNU1ZpmgmOR/IE+N1cL7rtlnXDRcUllM3F6++n5vLdRlIBRd aar89UCr7BRw8vXUB5WyYA7o9DSci8W9bpGdlESs7/gKJe7F+AGx4RP0qmakpXmaY3BTxLE3vue s/J0= X-Gm-Gg: ASbGncvZvd9up40+p+wAUNVP1xICYeGw8BwvQTICL2JJ9sGsiG5eunvnrFNG6j+i/Xv yMQTfkdpcQb1+rgT9GuJy/93oFCSU8pUjx8Uzwz7wNm1HEtWWgbzfuz1p2CXuRNQZR2IBkZGUcZ 7LrMvflk40OLjK2xGrW3psuriYRfReHNQy+ntrMlJaNxAYce4CZw9bO4OZ9YVizeg7Psh8lUSjj V11uA2RimxdBdpXIsuRycGyCyoJBP/G6wcgrtGk2J62S9P8jWrpBUA4q9bVUq2hoKg08QG2Fzby 9+8sok7TTUw+zHCYyacJaNL32Tlpx9KAuZt6874RZguGXGhFp5ynzxaUwDrgdNdwemiPYvMCNrU 53ADWz7OW5l7yeUCWYm+5+jad99TTAjy0TI04KIXqAg/agQCZjTIaG13bhI2Uv0Oe7QQ+Eek8C3 N55HCcvq8RZN9da/9FH8aRuu4fysMU5DTlJxA/eSJkhIk= X-Google-Smtp-Source: AGHT+IH81RlIDDcgE8eUMCm+HmuAHRYFEaCjXHghrIb8U/VOZ4PdUOOkvzIHx/WO4JaqnsixlygLMg== X-Received: by 2002:a05:690c:e06:b0:786:3ca8:6bd9 with SMTP id 00721157ae682-786483ea024mr201020957b3.4.1762191191977; Mon, 03 Nov 2025 09:33:11 -0800 (PST) Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com. [74.125.224.48]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-63f96a50fa5sm3172020d50.16.2025.11.03.09.33.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Nov 2025 09:33:11 -0800 (PST) Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-63e10cd6efeso4419014d50.0 for ; Mon, 03 Nov 2025 09:33:11 -0800 (PST) X-Received: by 2002:a05:690c:968f:b0:786:266c:5bd0 with SMTP id 00721157ae682-786484df431mr209316837b3.42.1762191190760; Mon, 03 Nov 2025 09:33:10 -0800 (PST) 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: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> In-Reply-To: From: Tomek CEDRO Date: Mon, 3 Nov 2025 18:32:59 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bksvHCysajHraHCX4b8cexRqm6Ascu9aZzp-Uop__LrEPoH961rno5va04 Message-ID: Subject: Re: Why is the DVD image so large? To: Sulev-Madis Silber 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)[]; 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: 4d0dwF71pXz3rlR On Mon, Nov 3, 2025 at 6:06=E2=80=AFPM Sulev-Madis Silber wrote: > (..) > the optical disks are most of cases readonly, they could retain data well= , could be pressed into permanent disk, would be allowed in high security e= nvironments where usb would be not maybe > > i miss the optical use cases here, anyone give me insight? 1. read only / immutable. 2. no moving parts =3D immune to mechanical malfunction like hdd. 3. no electronics parts =3D immune to esd / emp like ssd. 4. long life time far exceeding hdd/ssd (i.e. hard coat, or mdisk). 5. small and light. --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Nov 3 18:22: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 4d0g1V1Qqhz6FDcT for ; Mon, 03 Nov 2025 18:22:54 +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 4d0g1T43Pbz3xX0 for ; Mon, 03 Nov 2025 18:22:53 +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 5A3IMiAC097985; Tue, 4 Nov 2025 03:22: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=1762194166; bh=AOBqE6jnkMulc/u71tIVlO+uS8N/fIEKSGadIfgE7WM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZA0JWcNmMOeERud9uM0JQG3SahQidLgifbhJ8eTw/WJdIiYBrOqX4Z6TSEgGtAnki 1Ewt7Lw/7v38eObDZERN1g152Txyw+9Nb/edGbZ2yHl+ESLAVztrXCQd/+FHFIJlnR dUxgVRCLuTIsLcPgzXKOWzM/eqDKyDDcNAcY/DKA= Date: Tue, 4 Nov 2025 03:22:44 +0900 From: Tomoaki AOKI To: Tomek CEDRO Cc: Sulev-Madis Silber , freebsd-current@freebsd.org Subject: Re: Why is the DVD image so large? Message-Id: <20251104032244.f9fbf3cf8d67897a0ea84ac0@dec.sakura.ne.jp> In-Reply-To: References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.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 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: 4d0g1T43Pbz3xX0 On Mon, 3 Nov 2025 18:32:59 +0100 Tomek CEDRO wrote: > On Mon, Nov 3, 2025 at 6:06 PM Sulev-Madis Silber > wrote: > > (..) > > the optical disks are most of cases readonly, they could retain data well, could be pressed into permanent disk, would be allowed in high security environments where usb would be not maybe > > > > i miss the optical use cases here, anyone give me insight? > > 1. read only / immutable. Some types of optical disks are re-writable, while most of writable optical disks are write-once. And re-writable disks are roughly categorized into two. a) Erase and write for the whole disk at once. (Example: CD-RW and DVD-RW) b) Can read/write just like a HDD. (Example: MO, PD, DVD-RAM) IIRC, DVD-RAM needed to be formatted and written as UDF, while MO and PD were mimic'ing HDD and partitionable. > 2. no moving parts = immune to mechanical malfunction like hdd. MO, PD and some of DVD-RAM media are provided as "cartridges" and had shutter on access hole. https://en.wikipedia.org/wiki/Magneto-optical_drive https://en.wikipedia.org/wiki/Phase-change_Dual https://en.wikipedia.org/wiki/DVD-RAM > 3. no electronics parts = immune to esd / emp like ssd. > 4. long life time far exceeding hdd/ssd (i.e. hard coat, or mdisk). > 5. small and light. > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- Tomoaki AOKI From nobody Mon Nov 3 18:42: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 4d0gSf0scmz6FHHf for ; Mon, 03 Nov 2025 18:42:58 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4d0gSd0Jq9z41fp for ; Mon, 03 Nov 2025 18:42:57 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=RkcjDnV2; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762195361; bh=KfG/10SrxTqt4IlVId23MPc5XUnCMP//SdzLyTXHcEA=; h=Date:From:To:Subject:In-Reply-To:References; b=RkcjDnV2VeUcXCftCvkUzhfWJU/mpRihNEOElZ+89akB2ExYi0JmGYtVQvvo67ec3 kJFdqoSzaoRvY1Wyw3i84+lpQElz8skGn+qVzLu7Rp90IhJZNJF7BOCxUoAoVkKE/r Jyw4lE0kPuLPkN9XAMDt8i/j5hyg0txYmbjNKPldvl/hWyVO7P83Sp97glEPM8QoUE W5UzzUaLChRLAacrpnqteG4783wgBiHNhqFV3GfU4Zu5ri/sZ/UORfoa21LnZd5pHv QfTpLnDjU6V1ByQVMHFcfLFM9+Ohf4K8q/eOiIbiy91WfUeFVf9J1TlZR8cq6jWKwe SmHqENEhaChmObgoAyWVG/VisA1/nWXYgAg25hqgiqfJzsKZz01w81+GxDLPD5OZnP K5ZeTBH3fRzYM+BnDtXLliJjoEaoVy8rfq68VI6CVrwVk4qTNdV91/kPZGy4l3jUYE 6RyrD7JHJ1fuQ82vmK1LVozhQlJNkEBdKaB8nFwkBr2sh7JtN+O4O0lMG3w6elu59v mRft0vSg/w1cBqt9DhzFnZcBnbmVgkwWOGCaz6QOi0QmOz6I31l99oTwsxz1nDY7Mv /vazywYLOsubWb50hyWvZH3vc6L+DRiz8UT0x6rblQbejqPwSH7rUrdwlM/EHsb1w+ L9hNhs533Nj/F+9iNF7zUfi8= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 7C4725CA46A for ; Mon, 03 Nov 2025 20:42:41 +0200 (EET) Date: Mon, 03 Nov 2025 20:42:39 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: Why is the DVD image so large? User-Agent: K-9 Mail for Android In-Reply-To: References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> 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-Spamd-Bar: / X-Spamd-Result: default: False [0.37 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.83)[-0.835]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-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)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4d0gSd0Jq9z41fp On November 3, 2025 7:32:59 PM GMT+02:00, Tomek CEDRO = wrote: >On Mon, Nov 3, 2025 at 6:06=E2=80=AFPM Sulev-Madis Silber > wrote: >> (=2E=2E) >> the optical disks are most of cases readonly, they could retain data we= ll, could be pressed into permanent disk, would be allowed in high security= environments where usb would be not maybe >> >> i miss the optical use cases here, anyone give me insight? > >1=2E read only / immutable=2E >2=2E no moving parts =3D immune to mechanical malfunction like hdd=2E >3=2E no electronics parts =3D immune to esd / emp like ssd=2E >4=2E long life time far exceeding hdd/ssd (i=2Ee=2E hard coat, or mdisk)= =2E >5=2E small and light=2E > in installer context or all storage? i do hdd/flash here and i have writte= n some cd-r's=2E one rw=2E of course all are pretty much correct, or fully,= depending anyway it was about installer=2E i don't know if somebody wants to burn li= ke bd-r for install so how many isos is practical? and i wonder if larger usb stick owners could take dvd dl or some blu or we still need separate usbs? with usb there is no standard size=2E with= 64g, avg size, you could iirc fit a quite a de's there and their deps i wonder if image maker is solution=2E has own issues=2E how to verify it whatever From nobody Mon Nov 3 19:10: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 4d0h4G3GWhz6FKWR for ; Mon, 03 Nov 2025 19:10:22 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4d0h4G0QKDz43dJ for ; Mon, 03 Nov 2025 19:10:22 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-5943421baa6so254701e87.1 for ; Mon, 03 Nov 2025 11:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762197015; x=1762801815; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=mctoELPJwsSUbCdIgT85mIdyiZARtLXEY34yLPZMxZw=; b=b5qDAlwiW8L68UqcKhwu4yNBi8q3RUSFSiqdbcJz/docxKK2n7PUYYmMSgrQBd8nT7 kVoyHvHlNBHIj7G6/VCVRr/s4rH+wda5Lo4wZoh99BbuWxBev7lSRlXMu3/RM+YX57Kp eSa6/HCj2GlZHQDl2sjL77ctAQmRxbYZIUDhYSttOtckGjBsKaTd6d13YTqLnvXr4m0h jMltnjEWM8rdPhqghA+oZ1c4HsfFsASiickuFWRNcwsc1lmDfwJysDv09Ra5OUe3nx47 JnzMldqPT8PNuVYFRt62bRc1ZsiP2UoWg3JQIN6SCZ+EclwdepgNVe3JsrOBT1BeLJdA yojw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762197015; x=1762801815; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mctoELPJwsSUbCdIgT85mIdyiZARtLXEY34yLPZMxZw=; b=UN/bWXTqwfwYiLcwDGgmPn31YvV5qGnvS3FvrNIoHzvXHae7PZSpmltczNHhaMUgmD +OznIiXI9LM6g830YZMy/qGSUyPBQVfTIUrzlpj3P+u4rTTCyUwor3AvuHnp0tlCqZwB l2EEPg+Yegmdusm9aMp6OjwtFPRA2RTPWtyeIv1GwiHQTLFll+hS+vI9YokYYqSTvC/Y 5DmlsFQCAirdEl8MWx0/TxcLE9QovE13ziYTmjMUCj8wGpFspRtje9FDibcmTWJWtFwc iPlXHaqt5uBTNiTi/NPdbArZe7phVFDthUyJatHrzNiVHG7im+PnIKR19OboIGFC/9hN zRaw== X-Forwarded-Encrypted: i=1; AJvYcCV2ouC8L0GeiWqVuaccHecxX3761by0azlf2mVjrtJgEUtNSL4WM97bTaLjCT5NULnxJzgL2YSDW60M1zQsMZQ=@freebsd.org X-Gm-Message-State: AOJu0Yyp1o962yVVsjzNXAZP3ztYBkkMdoB1I/nGF4XjrHUKsgauBsSN HDY8glUdznc3Rj/zGJLTn/cZipvuxf87dL3bFHoMZfWd0c2WYw1l5J1mccucUw== X-Gm-Gg: ASbGncul0SyqseUt6/ANcdmlrrSxoqiodG1i5uUPyry8Z6lAMhKM3fIZc8ftGXa/exJ bzcZgFQH8hZgUYfhGBlHFzn90meESM4CmlHdQwfTmfuj2/6N+KYN+OUxmVwcLZ3MG6oDn3xPtOy 0zMRqaaGSJ5aWPmxs92P6+HmkLcMTSehrrpfLmvX4tOtZv/Yw83yQQhhTPRRN7h3L4J/1YM646x S7MYeynJzzQtf08Icy5rfCuu2zSUJbjhEd33ENeTRmiGlOmPMlq2quT8hxKt8zTUIW1SoMfHA+x tS31Q9eZ3DtPIVPJ7UwqACWHUg3BwOnfYRd90nI8jMpQFEncwX6cdHix6YHnp33GbnSxO43RAeO svyyxp6A87oUwqTvO2rT5B4OGFOOa9ZRR/khioZs2+thKGXVUn6ntRIslDx+84DLFGQKmOAg9+a GM1Hc95Cf7rcfLRGyKoLm53elRh85fsw== X-Google-Smtp-Source: AGHT+IE8LQ/dB7tLVjhMQ6BqyBSlwnzpDqFWKAcY+1UeAaCqCxZSP8Tg45nMsXCXoKV1xPVi4swyVQ== X-Received: by 2002:a05:6512:3056:b0:57e:ad46:b0a9 with SMTP id 2adb3069b0e04-5941d504c0fmr4141124e87.16.1762197014839; Mon, 03 Nov 2025 11:10:14 -0800 (PST) Received: from [192.168.2.131] (host.62.13.8.86.bitcom.se. [62.13.8.86]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59434452957sm115804e87.97.2025.11.03.11.10.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Nov 2025 11:10:14 -0800 (PST) Message-ID: <12aa0299-9b79-4523-850e-898fe61ec9a9@gmail.com> Date: Mon, 3 Nov 2025 20:10:14 +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: Why is the DVD image so large? To: Sulev-Madis Silber , freebsd-current@freebsd.org References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> Content-Language: sv-SE From: Lars Tunkrans Organization: Retiered 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: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: 4d0h4G0QKDz43dJ Den 2025-11-03 kl. 19:42, skrev Sulev-Madis Silber: > > On November 3, 2025 7:32:59 PM GMT+02:00, Tomek CEDRO wrote: >> On Mon, Nov 3, 2025 at 6:06 PM Sulev-Madis Silber >> wrote: >>> (..) >>> the optical disks are most of cases readonly, they could retain data well, could be pressed into permanent disk, would be allowed in high security environments where usb would be not maybe >>> >>> i miss the optical use cases here, anyone give me insight? >> 1. read only / immutable. >> 2. no moving parts = immune to mechanical malfunction like hdd. >> 3. no electronics parts = immune to esd / emp like ssd. >> 4. long life time far exceeding hdd/ssd (i.e. hard coat, or mdisk). >> 5. small and light. >> > in installer context or all storage? i do hdd/flash here and i have written some cd-r's. one rw. of course all are pretty much correct, or fully, depending > > anyway it was about installer. i don't know if somebody wants to burn like bd-r for install > > so how many isos is practical? > > and i wonder if larger usb stick owners could take dvd dl or some blu > > or we still need separate usbs? with usb there is no standard size. with 64g, avg size, you could iirc fit a quite a de's there and their deps > > i wonder if image maker is solution. has own issues. how to verify it > > whatever The cost for BD Media and BD drives are not noticably higher than cost for DVD-DL media and drives. The risk that a User needs to re-invest in a New BLuray writer drive is significant, while the risk that your present drive cant write DVD-DL format is exeedingly small as it needs to be older than 15 years for that to occur. I did not try writing BD media on Freebsd. I can test it if needed. I have never used UDF format AFAIR. To stipulate use of DVD-DL media to get rid of the 4.7 GB limitation is presently very low risk and has no economic impact for the end user. ( I have used DVD-DL for 15-ALPHA & 15-BETA isos.) Joerg Shilly's CDrecord / K3B can write DVD-DL. To stipulate BluRay BD media has possible hardware replacment issues and UDF format risks. Regards - ------------------------- Lars Tunkrans Oracle SPARC/Solaris System Administrator Fujitsu M12 SPARC Specilaist From nobody Mon Nov 3 19:11:10 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 4d0h5W2Ljvz6FKZv for ; Mon, 03 Nov 2025 19:11:27 +0000 (UTC) (envelope-from kib@freebsd.org) 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 4d0h5V4tvjz44q5; Mon, 03 Nov 2025 19:11:26 +0000 (UTC) (envelope-from kib@freebsd.org) 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 5A3JBAmk068521; Mon, 3 Nov 2025 21:11:13 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5A3JBAmk068521 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5A3JBA5g068520; Mon, 3 Nov 2025 21:11:10 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 3 Nov 2025 21:11:10 +0200 From: Konstantin Belousov To: John Baldwin Cc: Rick Macklem , FreeBSD CURRENT , Navdeep Parhar , "erj@freebsd.org" , "aehrenberg@nvidia.com" , slavash@nvidia.com, "sreekanth.reddy@broadcom.com" Subject: Re: RFC: NFS over RDMA 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham 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)[]; TAGGED_RCPT(0.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: 4d0h5V4tvjz44q5 On Mon, Nov 03, 2025 at 09:35:56AM -0500, John Baldwin wrote: > On 11/1/25 17:26, Rick Macklem wrote: > > On Sat, Nov 1, 2025 at 2:10 PM Konstantin Belousov wrote: > > > > > > On Sat, Nov 01, 2025 at 02:03:59PM -0700, Rick Macklem wrote: > > > > On Sat, Nov 1, 2025 at 1:50 PM Konstantin Belousov wrote: > > > > > > > > > > Added Slava Schwartsman. > > > > > > > > > > On Sat, Nov 01, 2025 at 01:11:02PM -0700, Rick Macklem wrote: > > > > > > Hi, > > > > > > > > > > > > I've had NFS over RDMA on my todo list for a very loonnnggg > > > > > > time. I've avoided it because I haven't had a way to test it, > > > > > > but I'm now going to start working on it. (A bunch of this work > > > > > > is already done for NFS-over-TLS which added code for handling > > > > > > M_EXTPG mbufs.) > > > > > > > > > > > > >From RFC-8166, there appears to be 4 operations the krpc > > > > > > needs to do: > > > > > > send-rdma - Send on the payload stream (sending messages that > > > > > > are kept in order). > > > > > > recv-rdma - Receive the above. > > > > > > ddp-write - Do a write of DDP data. > > > > > > ddp-read - Do a read of DDP data. > > > > > > > > > > > > So, here is how I see the krpc doing this. > > > > > > An NFS write RPC for example: > > > > > > - The NFS client code packages the Write RPC XDR as follows: > > > > > > - 1 or more mbufs/mbuf_clusters of XDR for the NFS arguments > > > > > > that precede the write data. > > > > > > - an mbuf that indicates "start of ddp-read". (Maybe use M_PROTO1?) > > > > > > - 1 or more M_EXTPG mbugs with page(s) loaded with the data to be > > > > > > written. > > > > > > - 0 or more mbufs/mbuf_clusters with additional RPC request XDR. > > > > > > > > > > > > This would be passed to the krpc which would... > > > > > > - the mbufs up to "start of ddp" in the payload stream. > > > > > > - Would specify a ddp-read for the pages from the M_EXTPG mbufs > > > > > > and send that in the payload stream. > > > > > > - send the remaining mbufs/mbuf_clusters in the payload stream > > > > > > > > > > > > The NFS server end would process the received payload stream, > > > > > > putting the non-ddp stuff in mbufs/mbuf_clusters. > > > > > > It would do the ddp-read of the data into anonymous pages it allocates > > > > > > and would associate these with M_EXTPG mbufs. > > > > > > It would put any remaining payload stream stuff for the RPC message in > > > > > > additional mbufs/mbuf_clusters. > > > > > > --> Call the NFS server with the mbuf list for processing. > > > > > > - When the NFS server gets to the write data (in M_EXTPG mbufs) > > > > > > it would set up a uio/iovec for the pages and call VOP_WRITE(). > > > > > > > > > > > > Now, the above is straightforward for me, since I know the NFS and > > > > > > krpc code fairly well. > > > > > > But that is where my expertise ends. > > > > > > > > > > > > So, what kind of calls do the drivers provide to send and receive > > > > > > what RFC-8166 calls the payload stream? > > > > > > > > > > > > And what kind of calls do the drivers provide to write and read DDP > > > > > > chunks? > > > > > > > > > > > > Also, if the above sounds way off the mark, please let me know. > > > > > > > > > > What you need is, most likely, the infiniband API or KPI to handle > > > > > RDMA. It is driver-independent, same as for ip NFS you use system IP > > > > > stack and not call to ethernet drivers. In fact, most likely the > > > > > transport used would be not native IB, but IB over UDP (RoCE v2). > > > > > > > > > > IB verbs, which is the official interface for both kernel and user mode, > > > > > are not well documented. An overview is provided by the document > > > > > titled "RDMA Aware Networks Programming User Manual", which should > > > > > be google-able. Otherwise, the Infiniband specication is the reference. > > > > Thanks. I'll look at that. (I notice that the Intel code references something > > > > they call Linux-OpenIB. Hopefully that looks about the same and the > > > > glue needed to support non-Mellanox drivers isn't too difficult?) > > > OpenIB is perhaps the reference to the IB code in Linux kernel proper > > > plus userspace libraries from rdma-core. This is what was forked/grown > > > from OFED. > > > > > > Intel put efforts into the iWARP, which is sort of alternative for RoCEv2. > > > It has RFCs and works over TCP AFAIR, which causes problems for it. > > Heh, heh. I'm trying to avoid the iWARP vs RoCE wars.;-) > > (I did see a Mellanox white paper with graphs showing how RoCE outperforms > > iWARP.) > > Intel currently claims to support RoCE on its 810 and 820 NICs. > > Broadcom also claims to support RoCE, but doesn't mention FreeBSD > > drivers and Chelsio does iWARP, afaik. > > > > For some reason, at the last NFSv4 Bakeathon, Chuck was testing with > > iWARP and not RoCE? (I haven't asked Chuck why he chose that. It > > might just be more convenient to set up the siw driver in Linux vs the > > rxe one? He is the main author of RFC-8166, so he's the NFS-over-RDMA guy.) > > > > But it does look like a fun project for the next year. (I recall jhb@ mentioning > > that NFS-over-TLS wouldn't be easy and it turned out to be a fun > > little project.) > > Konstantin is right though that sys/ofed is Linux OpenIB and has an interface > that should let you do RDMA (both ROCEv2 and iWARP). I'm hoping to use the APIs > in sys/ofed to support NVMe over RDMA (both ROCEv2 and iWARP) at some point as > well. > > rick > > > > > > > > > > > > > Btw, if anyone is interested in taking a more active involvement in this, > > > > they are more than welcome to do so. (I'm going to be starting where I > > > > understand things in the krpc/nfs. I'm not looking forward to porting rxe, > > > > but will probably end up there. I have already had one offer w.r.t. access > > > > to a lab that includes Mellanox hardware, but I don't know if remote > > > > debugging will be practical yet.) > > > > > > > > rick > > > > > > > > > > > > > > The IB implementation for us is still called OFED for historical reasons, > > > > > and it is located in sys/ofed. > > > > > > > > > > > > > > > > > As for testing, I am planning on hacking away at one of the RDMA > > > > > > in software drivers in Linux to get it working well enough to use for > > > > > > testing. Whatever seems to be easiest to get kinda working. > > > > > Yes rxe driver is the sw RoCE v2 implementation. We looked at the > > > > > amount of work to port it. Its size is ~12 kLoC, which is compatible > > > > > with libibverbs (userspace core infiniband interface). > > Interesting. I'm currently working on merging back several OFED commits from > Linux to sys/ofed (currently I have about 30 commits merged, some older than > Hans' last merge, and some newer, some of the newer ones should permit removing > compat stubs for some of the newer APIs that are duplicated in bnxt, irdma, and > mlx*). When I get a bit further along I'll post the branch I have for more > testing (it is a bunch of individual cherry-picks rather than a giant merge). Talking about merges. There is a long-time rotten series of patches from supposedly Juniper that added some features to our IB. Largest features seems to be tunnelling modes, but there are a lot of scattered bug fixes as well. This was advertised as necessary for native DPDK support on mlx5 (PMD). See the patches starting at https://reviews.freebsd.org/D32176. I revived them and rebased on top of main, see https://people.freebsd.org/~kib/git/deviant3.git/ branch devx. I was unable to contact the author of the reviews, and we (NVidia) are not sure how to proceed with this stuff. We do not want to allow it to rot further. If anybody has the right contact either for author or for the team that uses this series of patches, it would be helpful. > > Porting over rxe could be useful for me as well for some work I am doing. Thank you for noting this. From nobody Mon Nov 3 19:28: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 4d0hTh6lk3z6FMCp for ; Mon, 03 Nov 2025 19:28:56 +0000 (UTC) (envelope-from avg@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 4d0hTh65FRz47ff for ; Mon, 03 Nov 2025 19:28:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762198136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8CyGDSrp2bN5LUAY9O+O+ulgbdOzGpZvSLrzX7ByLWw=; b=iq/GU3UQeA0gjzhtzBKWYbHpqtmDYX/C1GIa45DEpgA/NYySYsZ+1QWI4b7H1b+vJpljui I/A5FQ3xCon4UKfMWK4wJJB9Q+JwAgOf6AhsPhh37W6YBLx2k3ZsZGdGrhnIZb0h+KYRZb UWWZREeCXh/5Vu5VJvhKSUlzLqKERitFLkkwnVBOZxA23+RfURa4KyiPHKEkSFr1hZlb4J q81CRTK8JPEIpxNFvVX28yXHfyu3BZ74sT9+RWsbiW6ao6oflbchSbd3CAPo5+EY2RhbHp 4S3/3OJs4TEdrYEyBLxq2DcFGU4xz2gWRdk8ydoBvA5lIhIPtcvh2PDah6B8Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762198136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8CyGDSrp2bN5LUAY9O+O+ulgbdOzGpZvSLrzX7ByLWw=; b=BRhXa9CjYDnnFaAz2zUN9QNkOT0cOg0Qt5NA7yjyCys1uCvFeKI1N5wMUT+3/WTlLMg38f h51goYsJfSZIpgHX5jOBt3Qh5L6fIllyDUinncu+0ZvbK7wmDOfhFMj43+OjhJ+VrpCKti 28/2/LR+RyeBjjh3swEvhNKECQB89wKNPe/IQfb2/zoSL7aF2aQOxABa2WB6QEAgpyU5e9 ZpnB2HyriVWP+estGWIZqKx/+D4GtM6SaZmmAr/aBqNe5VryiA2q2Xfw79+cQwRD7dfIeK 6vyQosTIuhcwdKKZLdOA7XfECBm6qAOQBkQ5qK0z0tkHBx3tkCb+teqDw3Gr4g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762198136; a=rsa-sha256; cv=none; b=vZ4BnuTMK/I8jqUv0zi8iKQ/kWQfucoSi3V2QHstsdPmMd89g/ByLRJlI5mSgSREuB5oRg edoQRZR8v4P4fbn3gdnwwG6ZD4vw2KcTcvcJUQxrQCqlwok7Xg7njLh98gmGJCydnZnSqH DgF+wzfGGQ2MxaMn5u+T2awoNvdrjVO7CPN8EL2GBgUlWV2jUBALT15m9jz4fcw/71BwA5 SWwsPDvBKMhvhF3/4Aol+sb1xgdxxDNuw3NCiSoJByNKW0WfP9sjJRYyTEMOeWvfm5dfNu dmM8KBgkZHcj6Rdc0zjdyQE/fSocvgRKll1nu7IbDVgvsqoQLXbl7X9Fa1h00w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.0.88] (unknown [93.188.39.137]) (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: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d0hTh3p9FzCD for ; Mon, 03 Nov 2025 19:28:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <6a85330c-6802-46e1-aa66-eb692bc918f9@FreeBSD.org> Date: Mon, 3 Nov 2025 21:28: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: Why is the DVD image so large? To: freebsd-current@freebsd.org References: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> Content-Language: en-US From: Andriy Gapon In-Reply-To: <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 03/11/2025 11:12, Tomoaki AOKI wrote: > Another option (far more difficult, though) would be switching > to Blu-ray disks. > > Why difficutlt? Because it would be strongly expected supports for > newer UDF that BD requires, if official BD image is provided, > even if the media is actually in ISO 9660. And UDF support on FreeBSD > is outdated that cannot mount BD. Just in case somebody would want to revive this: https://reviews.freebsd.org/D9614 But I personally believe that optical media is a thing of the past from the mass market perspective now. And so is UDF (the filesystem). -- Andriy Gapon From nobody Mon Nov 3 20:57:55 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 4d0kSl1x9Gz6Flpv for ; Mon, 03 Nov 2025 20:58:15 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb133.google.com (mail-yx1-xb133.google.com [IPv6:2607:f8b0:4864:20::b133]) (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 4d0kSk6vjvz3SRq for ; Mon, 03 Nov 2025 20:58:14 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yx1-xb133.google.com with SMTP id 956f58d0204a3-63f9beb27b9so3077099d50.1 for ; Mon, 03 Nov 2025 12:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1762203489; x=1762808289; 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=sxtkT5bUItoAjPTYH1YR+DEOeRmmZycVI5NMGhEQs6U=; b=C15/0OjNeNtGZFasTWBu6wiDP8k9kNmn0cUddq3WgqzeXCWdXEGSn0w54qq4H8zY9M 2Ehm2m0cUQS2nbys3f4dliMp+oa1nGpAg/O4xbyWb77PulLWtCdZD+IawULGh5HpZcOz RB0IBc0mkLGboxbjuK6wbtXVbqcML0bixIMbVf1viNx3kteaZ1b+uyN1bSnIY4n80Fas nYi+cqLidQox9gzyZQiMyTXlwtdXb9F83EeHIXENOnr/v76cZCnc2uuGaLy0661gAmTu zACcJ7821fMGlRkuxILEm/db+VVMS27iZMYWJ79FCJeASxdjVswIV1qpU0DyhN4JnplL 4ozA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762203489; x=1762808289; 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=sxtkT5bUItoAjPTYH1YR+DEOeRmmZycVI5NMGhEQs6U=; b=gbUmfud9v1GriVe5q1bsD2QTbRRjwNuGs7v8vOQmrcVoLwgzRulFsf2AsbwooWWN88 wknqhDcVhOUUbwtMvVXVdUvd23J2XGOhlOyqOE+Me+NY/tr52u/javOWfmq294nym3Xs zoQwhR27jgIjwtg7Kubgs/m8pZcZTR7XKqPvAR3nQuATQnwHSRF3BhquHy7DjiK0X0EP S4NUZFwAcopeJJu1dYZBJFZmZb4pzTWenBoeSu8tPcuLN+GRryv5oXoCbXSGxt7d5gZB EKlrProh0gxEwyxhXv1YOWGLr/lFBbU/jM+gOwHXM69V7VyKf4NLYpr7fC/IxDvfcFn3 9kYQ== X-Forwarded-Encrypted: i=1; AJvYcCWsYVs33hpfyaH3lblMRtNUAnR4yKKVD+LiQ7UcYCMLGUsa3W+XNLyigAlzcFHEyztCWCGW0Fkccrxnj7bEjeU=@freebsd.org X-Gm-Message-State: AOJu0Yzo1GkaePrVhkoEnxuiHtPI8+4yGagd8gHbX3vcQXBE6KDhBgEd 8+hywvhS0ixC4b7r1Wvsek0e1v4niuys/ZCKmyUj+/b+GzedfkU6HCNtS+oZTQn/rRL94dDSQlz UOj0= X-Gm-Gg: ASbGncvzc7a55IyKSRFeSWSqktcubGGdhpGWsnQZhhUL0/F5Jm7+PliEoBwZeNhfRj3 aVanu/Gmb4ZMS7bqDhWGPRdehJ2xq+Ypuod5nV0scxnxX3p29J7/PEM5la3nNRrDNJVjNbj5nFH mhvCc6t+6iq2rDJHHuwf3FNj+FeqdifRzaRMC09xn3/XgpWR3LAOW7GmBJMIJjktMPYCs23JFLk ICEYiySYh6qCFFTFyDdjXm9nJIAYEo+jcgDcanIb3TORTgeXMm6fbwg6skTD30bbwlRmeW80puI wWMAY1zrBh6Dk7o5/OcxKoquoOBnz+fgHd+JCMBf5ZM/iq2+wggBgCUnYjC464Wjmpset1RHtUN LXbqiKJwj55lMNLuzMc6QLs4P+7Q/ZZLsKfKCk7lGPFVRDPwu/8rIbEzcts10haq2JKPdm+vHiz ms12sNC4cjw4C4azqSrj6Jf/pfuuSjsfXsaJ6aWtFY+uPsQtU= X-Google-Smtp-Source: AGHT+IEsXOwKVeMzHB1F+SremTeXfsUoU2oXFdyjy14LLwYQPhzoiVKOTqZOIMSy+ck75lNtD/9jPQ== X-Received: by 2002:a05:690e:d4e:b0:63f:b3b6:4654 with SMTP id 956f58d0204a3-63fb3b64794mr4312937d50.35.1762203488831; Mon, 03 Nov 2025 12:58:08 -0800 (PST) Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com. [209.85.128.173]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-63fc95a249bsm33837d50.14.2025.11.03.12.58.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Nov 2025 12:58:07 -0800 (PST) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-7866e9e62e1so18085797b3.2 for ; Mon, 03 Nov 2025 12:58:07 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWQfKX9FSzS/+pU4X46BTKR5Q1GeIiZLkko4rOXZtPQn/8nGe370Nl/ZVSGkPFNAd0egZ472FjYY16cZjJ7oik=@freebsd.org X-Received: by 2002:a05:690c:6f92:b0:786:87b1:9631 with SMTP id 00721157ae682-78687b19a0amr26204277b3.66.1762203487302; Mon, 03 Nov 2025 12:58:07 -0800 (PST) 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: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> <20251104032244.f9fbf3cf8d67897a0ea84ac0@dec.sakura.ne.jp> In-Reply-To: <20251104032244.f9fbf3cf8d67897a0ea84ac0@dec.sakura.ne.jp> From: Tomek CEDRO Date: Mon, 3 Nov 2025 21:57:55 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bnNsQReVDqFlMJibllCJNbLq6bH7UL60NyoNx3dbzpjCgmmI0u8VPQbHgo Message-ID: Subject: Re: Why is the DVD image so large? To: Tomoaki AOKI Cc: Sulev-Madis Silber , 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)[]; 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: 4d0kSk6vjvz3SRq On Mon, Nov 3, 2025 at 7:22=E2=80=AFPM Tomoaki AOKI wrote: > On Mon, 3 Nov 2025 18:32:59 +0100 > Tomek CEDRO wrote: > > > On Mon, Nov 3, 2025 at 6:06=E2=80=AFPM Sulev-Madis Silber > > wrote: > > > (..) > > > the optical disks are most of cases readonly, they could retain data = well, could be pressed into permanent disk, would be allowed in high securi= ty environments where usb would be not maybe > > > > > > i miss the optical use cases here, anyone give me insight? > > > > 1. read only / immutable. > > Some types of optical disks are re-writable, while most of writable > optical disks are write-once. > > And re-writable disks are roughly categorized into two. > > a) Erase and write for the whole disk at once. > (Example: CD-RW and DVD-RW) > b) Can read/write just like a HDD. > (Example: MO, PD, DVD-RAM) > > IIRC, DVD-RAM needed to be formatted and written as UDF, > while MO and PD were mimic'ing HDD and partitionable. > > > 2. no moving parts =3D immune to mechanical malfunction like hdd. > > MO, PD and some of DVD-RAM media are provided as "cartridges" > and had shutter on access hole. > https://en.wikipedia.org/wiki/Magneto-optical_drive > https://en.wikipedia.org/wiki/Phase-change_Dual > https://en.wikipedia.org/wiki/DVD-RAM Okay, so I found our local optical disk magician (mr. hocuspocus lol), and he said "DVD-RAM DL disks never existed. JVC made DVD-RW DL but they never reached the market". So the easiest way is to just get a bunch of DVD-R DL double layer one time writable which are easily available and cheap.. or a BD-RE disk :-) On the other hand I found this on wikipedia (https://en.wikipedia.org/wiki/DVD-RAM) about DVD-RAM "Holds more data when using Double Sided discs than dual-layer DVD+RW and DVD-RW - 9.4GB for DVD-RAM vs 8.5GB for DVD+RW DL and DVD-RW DL". Does that mean optical disks were also double sided not only double layer? They had to be swapped by hand just like 5.25' floppies :D Also I just found and ordered to play around: BD-RE XL (100GB rewritable Sony disk ~17EUR no enclosure) and DVD-RAM (4.7GB Panasonic disk ~5EUR no enclosure).. lets see if my recorder firmware supports them and would it be possible to just mount DVD-RAM and read-write as standard disk but slow :-P --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Nov 3 22:43: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 4d0mpx6Yfrz6FwfP for ; Mon, 03 Nov 2025 22:44:09 +0000 (UTC) (envelope-from tschweikle@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 4d0mpx1S4tz3dbn for ; Mon, 03 Nov 2025 22:44:09 +0000 (UTC) (envelope-from tschweikle@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="YV4/05Y7"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of tschweikle@gmail.com designates 2607:f8b0:4864:20::832 as permitted sender) smtp.mailfrom=tschweikle@gmail.com Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-4ed411e8a29so35188861cf.3 for ; Mon, 03 Nov 2025 14:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762209843; x=1762814643; 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=23ksd7NIVe8aVLjyh+mKMCXzv8UzBFN4ROg3u/tO6/I=; b=YV4/05Y7lterIthMHKPoJvF+RvQdzCideEs8ukSlNAtAeTM6cfiwapicLgkQVulvBc uBcTtlHJaLdQ9KVpsQHLOhT+C9VUz4D0cBiVQyM7t/BoJcVVx1Y9jOiCcGAkW41Vf4zN DDVLbbJaqIL2o+xrCgR1wXtS1k3+Ar296yx9G1yU4zwub3n4WEM1GjzDuEJT4ythShZY 2w9mzGuka3HZazpt3wp56Suwjh22Vlx8fiud3Bm8699m53phcAcqR9bhtqQwoiPWMGdU ne87ScyIlD9m8BXtsxqAydYM9VZUaDOJOO9iHFqpGKeZ8dFTd18gV50FcocpoSd1uDrv Jmiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762209843; x=1762814643; 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=23ksd7NIVe8aVLjyh+mKMCXzv8UzBFN4ROg3u/tO6/I=; b=SdzLLEzPYkweovfWlfHuFXEPyArvJwX7TfWnQT3/4jpGK/ZolrxFsBtWGW5jnlxQCx +TtJVP45TcfOLU3MAxq23488VhB6I8Mkwwoi7YUCEKLxUkxYbEviPVSD6inzxOOSFtfO xj1XKFXtMZ748XhlVumAnadlJ6ONql60eLzn5yBC2/JAfVZV/cYB+oI9LcbLjH0ywDtx gT7yXf3XaZXr+qSwGTzTOSCO1lJhGpziVZSE5cfbKTR8fDS8/y6CTfGBwz/frhXmGA2g QiKIVUhndhyTHYGTZ6qLuUxzSpjiFHaiDhVzcrXY37GmjLSsBKMhmUWPmroRApFRZNpW Ofnw== X-Gm-Message-State: AOJu0YyYTufnxPpp+LEk5IpLdSuTnhLeI77qtlHWbBT5iNaFFW8azcz9 ytSbMZ/9Bq7mMZ6hyNXUpWZL/SA7rqAUM68xNeXoH8cFZSVuVL9votEWFMfD+DJAodsBnJ8E+RW 8psXtP4LARfLwigD5EE97RFHn9H7b6hQPJeAp X-Gm-Gg: ASbGncunXErvvi63Ud3LgFoeYTKpss1F3Od3hJSFAZdpR4h+x0P32CfU+g3AUpvUdXo nwmLcOgjAc32OxE8sF3jUVg5Fk56JIA0DePhll/BoyW2NhIc4vqMiHizXidiITWX7RwT85cC/4N NWREfDxbW/jdivDnTBlr5L6h1M5Bafdj9GIJ62iuwCwwnOrIRyXrMmOzDlgKUDcPRBxhxLnx71a 4AWDRS0JWGJPRHgbgw0dvGUdHn3BX1qS+zG+C8N9OrVFzEZnhjjCPd39y6RS3RasWuWIT8gCxKB yuBVZpwQb6CMS0GfIkNK46MAewHuW0RCFMMlooV2ou64KAOnBJZNBxeHB67zoepJWowLQmRzVHL k+SNjTxK+DwpwrA== X-Google-Smtp-Source: AGHT+IFqNT/H9vBSEIdFjcpaSETR7H0SjgP4fB5SclNeCAmvPVjeoYz0Ql8rO8+XqXiWd7UaCJ9YnEAv7gqppPb9aYQ= X-Received: by 2002:ac8:574b:0:b0:4ed:8ab:e7aa with SMTP id d75a77b69052e-4ed30d9288fmr173639301cf.11.1762209842940; Mon, 03 Nov 2025 14:44:02 -0800 (PST) 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: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> In-Reply-To: <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> From: Thomas Schweikle Date: Mon, 3 Nov 2025 23:43:51 +0100 X-Gm-Features: AWmQ_bkT6i2V1gZbpxL8MpU0AEaYN9mLm2WBr3RKb8Q-QwvDVK8du0hH3NoGvj0 Message-ID: Subject: Re: "etcupdate extract" -- Failed to build new tree. To: Marek Zarychta Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b552110642b87302" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-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:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from] X-Rspamd-Queue-Id: 4d0mpx1S4tz3dbn --000000000000b552110642b87302 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Followed your idea: # make buildworld # make buildkernel # mergemaster # etcupdate extract Failed to build new tree. It is broken. It only works if you unpack installation from CD, DVD or file. In all other cases it breaks. etcupdate has a "henn and egg" problem. If you build from sources it wont work. Regardless at which position you'll try to "etcupdate extract". It only works if you unpacked "/etc" from CD, DVD, or file. If it was cloned by "git clone https://github.com/freebsd/freebsd-src.git /usr/src" followed by "git checkout" or not it will break. It will even break if you first build world and or not kernel. It goes haywire if you just wipe sources, and start from scratch. etcupdate needs something not there, if you build "/usr/src" by "git clone https://github.com/freebsd/freebsd-src.git /usr/src", then building world, and kernel but it is there if you unpack sources from tarball. On Tue, Oct 28, 2025 at 3:30=E2=80=AFPM Marek Zarychta < zarychtam@plan-b.pwste.edu.pl> wrote: > W dniu 28.10.2025 o 14:37, Thomas Schweikle pisze: > > > > On Tue, Oct 28, 2025 at 1:35=E2=80=AFPM Dag-Erling Sm=C3=B8rgrav > wrote: > >> Thomas Schweikle writes: >> > Dag-Erling Sm=C3=B8rgrav writes: >> > > Thomas Schweikle writes: >> > > > Dag-Erling Sm=C3=B8rgrav writes: >> > > > > How was this system installed? >> > > > By compiling 15-STABLE from latest available 14.3 getting sources >> via >> > > How did you install 14.3? >> > Same way. It was Upgraded from 13-STABLE. And this was upgraded from >> > 12-STABLE. If I remember it right, the system installed from >> > disquettes was 5.0-RELEASE some way back in time ... >> >> Do you understand the difference between the words =E2=80=9Cinstall=E2= =80=9D and >> =E2=80=9Cupgrade=E2=80=9D? >> >> What did you use prior to etcupdate? When was /etc last updated? > > > The last time mergemaster was available. Later on it was done manually, > since etcupdate did not work. > > My findings: etcupdate just does not work, because right after cloning et= c > is not in a working state. It is, after running > > make _legacy > > in "/usr/src". Then it runs > > etcupdate extract > etcupdate diff > > without this "Failed to build new tree.", but it then fails run > > etcupdate -p > > right after building world, kernel and installkernel, exhausting: "No > previous tree to compare against, a sane comparison is not possible." jus= t > because there is no tree to compare against, or better: "etcupdate extrac= t" > created an empty tree without any files within.It is just "make _legacy" > creates all the folders, etcupdate expects, but not the files. It seems a= ll > those advices given within the handbook or at various places within the > internet all give it the wrong way: > > clone > ettupdate extract > etcupdate diff > make buildworld > make buildkernel > make installkernel > etcupdate -p > reboot > make installworld > etcupdate -B > reboot > > But > > clone > make buildworld > make buildkernel > etcupdate extract > etcupdate diff > make installkernel > etcupdate -p > make installworld > etcupdate -B > reboot > > because you will never have a working etc before building world and > kernel. And in tune you'd never will have anything you could extract. You > are assuming something to extract, but there isn't anything before > building. mergemaster did get this right (comparing the fresh build > /usr/src etc against /etc). etcupdate does not -- at least if it is used > the way the handbook advises. It would only work this way, if you did not > clone the working tree right fresh into an empty directory (or after "git > reset hard" -- removing anything from /usr/src what was created after the > last "git pull" simulating "git clone" as far as possible). > > -- > Thomas > > Hello Thomas, > that=E2=80=99s splendid - it=E2=80=99s impressive that you=E2=80=99ve man= aged to upgrade FreeBSD > from version 5.0! FreeBSD truly is an amazing operating system; being abl= e > to upgrade continuously for 25+ years without ever needing to reinstall i= s > a real achievement. Well done; my oldest installations that are still bei= ng > upgraded date back only to the FreeBSD 6.x era. > > Anyway, it=E2=80=99s time to say goodbye to mergemaster - you won=E2=80= =99t regret it. > The FreeBSD Handbook covers this transition in detail [1]. To perform the > upgrade correctly, you should run mergemaster(8) for the last time under > FreeBSD 14, and before rebooting, you=E2=80=99ll also need to run etcupda= te(8) too. > > Here=E2=80=99s the sequence that worked for me many times in recent weeks= : > # make buildworld > # make buildkernel > # mergemaster > # etcupdate extract > # etcupdate diff > # etcupdate -B > # make installkernel > # make installworld > # reboot > # pkg upgrade > # make delete-old > # make delete-old-libs > bootloader upgrade > # zpool upgrade > # reboot > > It=E2=80=99s a bit risky and not entirely in line with the Handbook to sk= ip the > first reboot, but if you=E2=80=99re upgrading from a relatively recent 14= .3-STABLE > and your root filesystem is on ZFS, you can create a backup Boot > Environment (BE) as a safeguard in case something goes wrong. > Even better, you can create a testing BE and perform the installation int= o > that BE after mounting it by using DESTDIR. Just remember that both > mergemaster and etcupdate must also be executed with respect to this > DESTDIR path. > > If you=E2=80=99ve used etcupdate in the past and weren=E2=80=99t satisfie= d with its > behavior, and therefore continued using mergemaster, I recommend cleaning > the cruft by running the following command before starting the final > transition to etcupdate: > > # rm -rf /var/db/etcupdate/ > > > 1. > https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-qui= ck-start > > Cheers > Marek > --=20 Thomas --000000000000b552110642b87302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Followed your idea:

# make buildworld# make buildkernel
# mergemaster
# etcupdate extract
Fail= ed to build new tree.

It is broken. It only works if you unpa= ck installation=C2=A0from CD, DVD or file. In all other cases it breaks. et= cupdate has a "henn and egg" problem. If you build from sources i= t wont work. Regardless at which position you'll try to "etcupdate= extract". It only works if you unpacked "/etc" from CD, DVD= , or file. If it was cloned by "git clone=C2=A0https://github.com/freebsd/freebsd-src.git=C2=A0/usr/= src" followed by "git checkout" or not = it will break. It will even break if you first build world and or not kerne= l. It goes haywire if you just wipe sources, and start from scratch.=
etcupdate needs something not there, if you build = "/usr/src" by "git clone=C2=A0https://github.com/freebsd/freebsd-src.git=C2=A0/usr/= src", then building world, and kernel but it is t= here if you unpack sources from tarball.

<= br>
On Tue, Oct 28, 2025 at 3:30=E2=80=AFPM Marek Zarychta <= zarychtam@plan-b.pwste.edu= .pl> wrote:
=20 =20 =20
W dniu 28.10.2025 o=C2=A014:37, Thomas Schweikle pisze:


On Tue, Oct 28, 2025 at 1:35=E2=80=AFPM Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> wrote:
Thomas Schweikle <tschweikle@gmail.com>= ; writes:
> Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> writes:
> > Thomas Schweikle <tschweikle@gmail.com> writes:
> > > Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> writes:
> > > > How was this system installed?
> > > By compiling 15-STABLE from latest available 14.3 getting sources via=C2=A0 =C2=A0
> > How did you install 14.3?
> Same way. It was Upgraded from 13-STABLE. And this was upgraded from
> 12-STABLE. If I remember it right, the system installed from
> disquettes was 5.0-RELEASE some way back in time ...

Do you understand the difference between the words =E2=80=9Cins= tall=E2=80=9D and
=E2=80=9Cupgrade=E2=80=9D?

What did you use prior to etcupdate?=C2=A0 When was /etc last updated?
=C2=A0
The last time mergemaster was available. Later on it was done manually, since etcupdate did not work.

My findings: etcupdate just does not work, because right after cloning etc is not in a working state. It is, after running

make _legacy

in "/usr/src". Then it runs

etcupdate extract
etcupdate=C2=A0diff

without this "Failed to build new tree.", but it t= hen fails run

etcupdate -p

right after building world, kernel and installkernel, exhausting: "No previous tree to compare against, a sane comparison is not possible." jus= t because there is no tree to compare against, or better: "etcupdate extract" created an empty tree without a= ny files within.It is just "make _legacy" creates all = the folders, etcupdate expects, but not the files. It seems all those advices given within the handbook or at various places within the internet all give it the wrong=C2=A0way:

clone
ettupdate extract
etcupdate diff
make buildworld
make buildkernel
make installkernel
etcupdate -p
reboot
make installworld
etcupdate -B
reboot

But

clone
make buildworld
make buildkernel
etcupdate extract
etcupdate diff
make installkernel
etcupdate -p
make installworld
etcupdate -B
reboot

because you will never have a working etc before building world and kernel. And in tune you'd never will have anythin= g you could extract. You are assuming something to extract, but there isn't anything before building. mergemaster did get this right (comparing the fresh build /usr/src etc against /etc). etcupdate does not -- at least if it is used the way the handbook advises. It would only work this way, if you did not clone the working tree right fresh into an empty directory (or after "git reset hard" -- removin= g anything from /usr/src what was created after the last "gi= t pull" simulating "git clone" as far as possible)= .

--
Thomas

Hello Thomas,

that=E2=80=99s splendid - it=E2=80=99s impressive that you=E2=80=99ve m= anaged to upgrade FreeBSD from version 5.0! FreeBSD truly is an amazing operating system; being able to upgrade continuously for 25+ years without ever needing to reinstall is a real achievement. Well done; my oldest installations that are still being upgraded date back only to the FreeBSD 6.x era.

Anyway, it=E2=80=99s time to say goodbye to mergemaster=C2=A0 - you won= =E2=80=99t regret it. The FreeBSD Handbook covers this transition in detail [1]. To perform the upgrade correctly, you should run mergemaster(8) for the last time under FreeBSD 14, and before rebooting, you=E2=80=99ll also n= eed to run etcupdate(8) too.

Here=E2=80=99s the sequence that worked for me many times in recent weeks:

# make buildworld
# make buildkernel
# mergemaster
# etcupdate extract
# etcupdate diff
# etcupdate -B
# make installkernel
# make installworld
# reboot
# pkg upgrade
# make delete-old
# make delete-old-libs
bootloader upgrade
# zpool upgrade
# reboot

It=E2=80=99s a bit risky and not entirely in line with the Handbook = to skip the first reboot, but if you=E2=80=99re upgrading from a relativ= ely recent 14.3-STABLE and your root filesystem is on ZFS, you can create a backup Boot Environment (BE) as a safeguard in case something goes wrong.=C2=A0
Even better, you can create a testing BE and perform the installation into that BE after mounting it by using DESTDIR. Just remember that both mergemaster and etcupdate must also be executed with respect to this DESTDIR path.

If you=E2=80=99ve used etcupdate in the past and weren=E2=80=99t sat= isfied with its behavior, and therefore continued using mergemaster, I recommend cleaning the cruft by running the following command before starting the final transition to etcupdate:

# rm -rf /var/db/etcupdate/


1. https://docs.freebsd.org/en/books/hand= book/cutting-edge/#updating-src-quick-start

Cheers
Marek



--
Thomas
--000000000000b552110642b87302-- From nobody Tue Nov 4 02:44: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 4d0t8d168hz6GJHH for ; Tue, 04 Nov 2025 02:44:49 +0000 (UTC) (envelope-from SRS0=pb5C=5M=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 4d0t8b3H25z47L7 for ; Tue, 04 Nov 2025 02:44:46 +0000 (UTC) (envelope-from SRS0=pb5C=5M=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b=3h54Hy4R; dkim=pass header.d=quip.cz header.s=private header.b=33VhYqGm; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=pb5C=5M=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=pb5C=5M=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8F182D7888; Tue, 4 Nov 2025 03:44:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1762224279; bh=d7TTj2/NVrdMoe7/kF/kPV/6sCHjl9BqpiTizJ49TWw=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=3h54Hy4RTRBK+0fRfq2udmOEjLxBuQrgymS9biGfxZDhUKwWGQcdle6Ufot0mfDEk OeRw2Ezr1MjQvHjuLIc4sDHm+PuyVU30QtEQVPs2FSewRT337F+yWb5x+0Y19BS0gU QNcw7cMgrq0zp+AdxtUmkXesizM3Deysi2jHdQG8= 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 98D7AD7887; Tue, 4 Nov 2025 03:44:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1762224278; bh=d7TTj2/NVrdMoe7/kF/kPV/6sCHjl9BqpiTizJ49TWw=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=33VhYqGmOtMtT/nzYry3hdclgGet1xasyAr8RfH8AYWNK6KDeCLY37v69JEgfdKsk O9D+L/RwBzXDDzm6rRaylR5fKxhJLryAggTRVJoZo3IjUdDj8z6fYKCyOi2ve2+bMm lTJFiB7KW9VEFCU0T5e9mdQLz4vhwZCvgN047szc= Message-ID: Date: Tue, 4 Nov 2025 03:44:38 +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: "etcupdate extract" -- Failed to build new tree. To: Marek Zarychta , Thomas Schweikle Cc: freebsd-current@freebsd.org References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=pb5C=5M=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[quip.cz]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[plan-b.pwste.edu.pl,gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=pb5C=5M=quip.cz=000.fbsd@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4d0t8b3H25z47L7 On 28/10/2025 15:29, Marek Zarychta wrote: > W dniu 28.10.2025 o 14:37, Thomas Schweikle pisze: [..] > Hello Thomas, > > that’s splendid - it’s impressive that you’ve managed to upgrade FreeBSD > from version 5.0! FreeBSD truly is an amazing operating system; being > able to upgrade continuously for 25+ years without ever needing to > reinstall is a real achievement. Well done; my oldest installations that > are still being upgraded date back only to the FreeBSD 6.x era. > > Anyway, it’s time to say goodbye to mergemaster  - you won’t regret it. Well, I am trying to use etcupdate for at least 2 or 3 years and I regret it every time. I am taking care of about 20 machines and every time I need to upgrade them and use etcupdate there are some issues or at least unnecessary conflicts that I must fix manually. Many time in file that I never edited. For me personally the mergemaster worked in much better way. > The FreeBSD Handbook covers this transition in detail [1]. To perform > the upgrade correctly, you should run mergemaster(8) for the last time > under FreeBSD 14, and before rebooting, you’ll also need to run > etcupdate(8) too. > > Here’s the sequence that worked for me many times in recent weeks: > > # make buildworld > # make buildkernel > # mergemaster > # etcupdate extract > # etcupdate diff > # etcupdate -B > # make installkernel > # make installworld > # reboot > # pkg upgrade > # make delete-old > # make delete-old-libs > bootloader upgrade > # zpool upgrade > # reboot [..] From nobody Tue Nov 4 06:10:46 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 4d0ykd6L1Hz6F8Gk for ; Tue, 04 Nov 2025 06:11:05 +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 4d0ykd4Cwgz3CWf for ; Tue, 04 Nov 2025 06:11:05 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-640b4a52950so2280914a12.1 for ; Mon, 03 Nov 2025 22:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762236658; x=1762841458; 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=x4kLL0sEsvOoxsxTijNmNqAYhG1HfcD3i7jZlUvOZZk=; b=mzSTv0F0fbey36TrTWCSGOSmHnNpVJMN207H2KjO4fp8BatnYmmP/spsH+Ov3f/RKn QREcwaV1zIgs9m9htbR1FSX8VDDWcDPd3GPUYTdVbk6yH6MSlsPAkjDPP00KUd3+Na7s hI1QfVsiKgz9atRMDpcyZsV1S/u3u5B2JqYopAIyZtHxCiT4prLbyhJs58cM8PYFInw1 XBaNYGIC/YNKEc/N2UycddFwl5c2usQJ28m5XvkHZHibbF0DbF36c6HgjNa6ZHuQ4wXR H6DEtg76Y5zubARvlEgRpsH5srcSUJ1OA8c51VDDw2QRuvHedH7W0D4zAMQwIykF5j/H kkXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762236658; x=1762841458; 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=x4kLL0sEsvOoxsxTijNmNqAYhG1HfcD3i7jZlUvOZZk=; b=t+LNvqAlH0oMcpfezBLYI+wt2Jyd3Qkipk0BIDenaq+JNdJOnwi8Iq1jV9+rhmShq7 n6HxFxIifbizinWTEag+bNZ/dCrM8VEl5A8D9E3ueoITFyPrhaUXGXji9WgN5Ib6pGY5 Y85peJbLbUJ3FC1RwnOnKSYzWk6GkE8y1LfEc8uNCpY7iRiCfcO2509F3GNgX1yVdTFB MLMVcyV789AXlSfnifAcppWz1MlDd348J3FcgK5FiRnUZVKfD8gM+O42h/fEJBpr7DGT TDy2CxA3E/moSKBblZInvPNV35kAiyX2IC/fI2I/+4sQ3E0w/My2Dda0QZQDw1u1U2ZR RB/w== X-Forwarded-Encrypted: i=1; AJvYcCWSfDyF6iicwQ3kJfl9PzNEk1NIsHbf5L0vc6fJGMZDMwJnovsNdveMewGMrXoQ7gk7FD7IpjY71pugYg1cCas=@freebsd.org X-Gm-Message-State: AOJu0YzWsoZFDZUJXbXq3eCXLAUWPn1tVc6MBEi+3y15Fwd7efTClJVw 81ifXUGuSXnLWKSiLK7HQu063uZ7AfrKOwSB67C1lgbvltrhPaJqS/WDavGonk5MrUcM8hiWcS0 5PTZ9mJyzatXJliRYitf12oLuFIjqUA== X-Gm-Gg: ASbGncsYJO/JLYrMPwp39+Ry6Y1C0di0Kz25n7TSGk4JQ/AUclcrFtcUx3vnl6PU8Li Ezngm0+NfDMskRAMYzGo1SVnlFkXv1lsdUDzGoI4MlzmJTDIAFybvDxazTX20pDXzq55z44rB9x +/gyQBvy+KPpZFEjQy82pk3gAb2bC/uoYbpRPi0t0ekne6HwOmmjlvhKzyRROIqkrvYL4wXpbLL s/wr9obhCRwobWFQZEhNU/iQORyl4WZqGU4F5jBQVfg20TL44y5KNO4PtqItxJCY6cAlvyuE9u4 JoaZB9kPYa+DfbIUmMh99xfQssk= X-Google-Smtp-Source: AGHT+IET8McF7GkgajSviQkcNvEbv7ufl1WlkEAWdvWTODFdL0anmFxXeGtMFEnW1PLYhENiDufs+IkW6B+5n8y9eQA= X-Received: by 2002:a05:6402:350a:b0:640:976f:13ad with SMTP id 4fb4d7f45d1cf-640976f1807mr8909946a12.8.1762236657687; Mon, 03 Nov 2025 22:10:57 -0800 (PST) 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: Rick Macklem Date: Mon, 3 Nov 2025 22:10:46 -0800 X-Gm-Features: AWmQ_bn4acpv6cOazsdjfzNy393APoWc_ma0R0aP_YMlJDvsc1GKClJqI9MWZtU Message-ID: Subject: Re: RFC: NFS over RDMA To: John Baldwin Cc: Konstantin Belousov , FreeBSD CURRENT , Navdeep Parhar , "erj@freebsd.org" , "aehrenberg@nvidia.com" , slavash@nvidia.com, "sreekanth.reddy@broadcom.com" 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: 4d0ykd4Cwgz3CWf On Mon, Nov 3, 2025 at 6:35=E2=80=AFAM John Baldwin wrote= : > > On 11/1/25 17:26, Rick Macklem wrote: > > On Sat, Nov 1, 2025 at 2:10=E2=80=AFPM Konstantin Belousov wrote: > >> > >> On Sat, Nov 01, 2025 at 02:03:59PM -0700, Rick Macklem wrote: > >>> On Sat, Nov 1, 2025 at 1:50=E2=80=AFPM Konstantin Belousov wrote: > >>>> > >>>> Added Slava Schwartsman. > >>>> > >>>> On Sat, Nov 01, 2025 at 01:11:02PM -0700, Rick Macklem wrote: > >>>>> Hi, > >>>>> > >>>>> I've had NFS over RDMA on my todo list for a very loonnnggg > >>>>> time. I've avoided it because I haven't had a way to test it, > >>>>> but I'm now going to start working on it. (A bunch of this work > >>>>> is already done for NFS-over-TLS which added code for handling > >>>>> M_EXTPG mbufs.) > >>>>> > >>>>> >From RFC-8166, there appears to be 4 operations the krpc > >>>>> needs to do: > >>>>> send-rdma - Send on the payload stream (sending messages that > >>>>> are kept in order). > >>>>> recv-rdma - Receive the above. > >>>>> ddp-write - Do a write of DDP data. > >>>>> ddp-read - Do a read of DDP data. > >>>>> > >>>>> So, here is how I see the krpc doing this. > >>>>> An NFS write RPC for example: > >>>>> - The NFS client code packages the Write RPC XDR as follows: > >>>>> - 1 or more mbufs/mbuf_clusters of XDR for the NFS arguments > >>>>> that precede the write data. > >>>>> - an mbuf that indicates "start of ddp-read". (Maybe use M_PROTO= 1?) > >>>>> - 1 or more M_EXTPG mbugs with page(s) loaded with the data to b= e > >>>>> written. > >>>>> - 0 or more mbufs/mbuf_clusters with additional RPC request XDR. > >>>>> > >>>>> This would be passed to the krpc which would... > >>>>> - the mbufs up to "start of ddp" in the payload stream. > >>>>> - Would specify a ddp-read for the pages from the M_EXTPG mbufs > >>>>> and send that in the payload stream. > >>>>> - send the remaining mbufs/mbuf_clusters in the payload stream > >>>>> > >>>>> The NFS server end would process the received payload stream, > >>>>> putting the non-ddp stuff in mbufs/mbuf_clusters. > >>>>> It would do the ddp-read of the data into anonymous pages it alloca= tes > >>>>> and would associate these with M_EXTPG mbufs. > >>>>> It would put any remaining payload stream stuff for the RPC message= in > >>>>> additional mbufs/mbuf_clusters. > >>>>> --> Call the NFS server with the mbuf list for processing. > >>>>> - When the NFS server gets to the write data (in M_EXTPG mbuf= s) > >>>>> it would set up a uio/iovec for the pages and call VOP_WRIT= E(). > >>>>> > >>>>> Now, the above is straightforward for me, since I know the NFS and > >>>>> krpc code fairly well. > >>>>> But that is where my expertise ends. > >>>>> > >>>>> So, what kind of calls do the drivers provide to send and receive > >>>>> what RFC-8166 calls the payload stream? > >>>>> > >>>>> And what kind of calls do the drivers provide to write and read DDP > >>>>> chunks? > >>>>> > >>>>> Also, if the above sounds way off the mark, please let me know. > >>>> > >>>> What you need is, most likely, the infiniband API or KPI to handle > >>>> RDMA. It is driver-independent, same as for ip NFS you use system I= P > >>>> stack and not call to ethernet drivers. In fact, most likely the > >>>> transport used would be not native IB, but IB over UDP (RoCE v2). > >>>> > >>>> IB verbs, which is the official interface for both kernel and user m= ode, > >>>> are not well documented. An overview is provided by the document > >>>> titled "RDMA Aware Networks Programming User Manual", which should > >>>> be google-able. Otherwise, the Infiniband specication is the refere= nce. > >>> Thanks. I'll look at that. (I notice that the Intel code references s= omething > >>> they call Linux-OpenIB. Hopefully that looks about the same and the > >>> glue needed to support non-Mellanox drivers isn't too difficult?) > >> OpenIB is perhaps the reference to the IB code in Linux kernel proper > >> plus userspace libraries from rdma-core. This is what was forked/grow= n > >> from OFED. > >> > >> Intel put efforts into the iWARP, which is sort of alternative for RoC= Ev2. > >> It has RFCs and works over TCP AFAIR, which causes problems for it. > > Heh, heh. I'm trying to avoid the iWARP vs RoCE wars.;-) > > (I did see a Mellanox white paper with graphs showing how RoCE outperfo= rms > > iWARP.) > > Intel currently claims to support RoCE on its 810 and 820 NICs. > > Broadcom also claims to support RoCE, but doesn't mention FreeBSD > > drivers and Chelsio does iWARP, afaik. > > > > For some reason, at the last NFSv4 Bakeathon, Chuck was testing with > > iWARP and not RoCE? (I haven't asked Chuck why he chose that. It > > might just be more convenient to set up the siw driver in Linux vs the > > rxe one? He is the main author of RFC-8166, so he's the NFS-over-RDMA g= uy.) > > > > But it does look like a fun project for the next year. (I recall jhb@ m= entioning > > that NFS-over-TLS wouldn't be easy and it turned out to be a fun > > little project.) > > Konstantin is right though that sys/ofed is Linux OpenIB and has an inter= face > that should let you do RDMA (both ROCEv2 and iWARP). I'm hoping to use t= he APIs > in sys/ofed to support NVMe over RDMA (both ROCEv2 and iWARP) at some poi= nt as > well. > > rick > > > >> > >>> > >>> Btw, if anyone is interested in taking a more active involvement in t= his, > >>> they are more than welcome to do so. (I'm going to be starting where = I > >>> understand things in the krpc/nfs. I'm not looking forward to porting= rxe, > >>> but will probably end up there. I have already had one offer w.r.t. a= ccess > >>> to a lab that includes Mellanox hardware, but I don't know if remote > >>> debugging will be practical yet.) > >>> > >>> rick > >>> > >>>> > >>>> The IB implementation for us is still called OFED for historical rea= sons, > >>>> and it is located in sys/ofed. > >>>> > >>>>> > >>>>> As for testing, I am planning on hacking away at one of the RDMA > >>>>> in software drivers in Linux to get it working well enough to use f= or > >>>>> testing. Whatever seems to be easiest to get kinda working. > >>>> Yes rxe driver is the sw RoCE v2 implementation. We looked at the > >>>> amount of work to port it. Its size is ~12 kLoC, which is compatibl= e > >>>> with libibverbs (userspace core infiniband interface). > > Interesting. I'm currently working on merging back several OFED commits = from > Linux to sys/ofed (currently I have about 30 commits merged, some older t= han > Hans' last merge, and some newer, some of the newer ones should permit re= moving > compat stubs for some of the newer APIs that are duplicated in bnxt, irdm= a, and > mlx*). When I get a bit further along I'll post the branch I have for mo= re > testing (it is a bunch of individual cherry-picks rather than a giant mer= ge). > > Porting over rxe could be useful for me as well for some work I am doing. I have https://github.com/rmacklem/freebsd-rdma. For now, I'll only be doin= g commits to it for the NFS and krpc files. It will be a while before anythi= ng in it is useful for others. I'll email when I get into the rxe port. (If you hurry, you can beat me to = it;-) Others are welcome to push/pull on the above. (Email if you need permission= s changes. I know diddly about github.) rick > > -- > John Baldwin > From nobody Tue Nov 4 12:39:04 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 4d17LL2nlVz6G0X4 for ; Tue, 04 Nov 2025 12:39:06 +0000 (UTC) (envelope-from des@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 4d17LL29qfz3qLM; Tue, 04 Nov 2025 12:39:06 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762259946; 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=Yp8yh2cw1BiZ9lq528VNqHiZIF297Mb/eFyXyrygkb0=; b=llyW/00MEFDfSkv32ud02o7ii4rURKDDlwBwZV2+SsvD/16QqpfU2ra69wbOxM6G7J0B6S 2D/NkM0dNq5+cod8Oy5QvQ3QN1V/sYb7Wgv6k6Nhgps2QLR2Um3KH5j/1hBYCpcPDuNV1H G80MXGaSI3MD6lLWX/q8YogP2bI/LrJQyGLbX34pEL2z2Sk3j65bIUXxoPLvmUgk2aSLB1 bmsueHzoOgWs0YpEsamS0DG/R7kKycSsA8bERIU/tU2yVJUdjUwi4d5beHTgS8JQF3reFb ud0/0vNwX/AKsw7BKFWb6WMzxEFCTPjEPQh2g8e1FJkVsSWI/B5XctQVb5/21A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762259946; 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=Yp8yh2cw1BiZ9lq528VNqHiZIF297Mb/eFyXyrygkb0=; b=VAgv1fQtfqqUzLn3b86+2gzxySj6dOJLs1IXIvmwOAxGcVFNpsdioskTemFSgYh9+oI3DQ CFuD9vJHHqxy8ZalO3Hf9B6658VaPKOly+NXMrVJ3e21i30c2lpdU+jDyUJRa+Mmzg6WXG rkm1B2SZrewqPoOGH7ib1b54j71nWAsFDv2pJ36G6a4CU7BOOF1RYnlHLNfvRJuoyIihBy wIM0T34zbWeuFY2Y/Jirmooxfzl6QNxe69fHwJDd4o7iTSL7XUvs1MVEmJXrVQ4ZgPcKE4 A+CiIOMI+MKoCYfwDQik3vZfmdr3IBdqBLvTW671qhlUb9gzaUh5aMD0DKcjmA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762259946; a=rsa-sha256; cv=none; b=MH6uabQnmKsqZ706T9A7Z+gH75NSr0eac16W6DeD9sUIH1RhDVP/TR3MT+RaUFaDS/E9Q4 h9Y91fUt9y0RgXmXlpoWdnEX8/BfzbsRLMfqEW2gvf1U8V6BdhwyAg8Vm3ZPsU5OvKhBLQ iJaHbhlnj1Si1ZoIWRQODM56JCJAI4UCEbMz1JUDg96ZNCUsvVQ6UgA58iunJFtS3DW31Y oU32y5LhFH6cfR/1RJgiLiIruffLUl7DSdWATFC39mRpKUwh59CZ7vpicDaA8o4pPtC1Te AlnlQIIudrRJEKdrLGwuFIld4+YsF5Px0EzzmYlObNfbfF3+FKQcU0JmJcqIiw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (unknown [IPv6:2a01:e0a:c54:bed0:922e:16ff:fef1:acef]) (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: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d17LL0pr7zLny; Tue, 04 Nov 2025 12:39:06 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 32D8AA5C6E; Tue, 04 Nov 2025 13:39:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Thomas Schweikle Cc: Marek Zarychta , freebsd-current@freebsd.org Subject: Re: "etcupdate extract" -- Failed to build new tree. In-Reply-To: (Thomas Schweikle's message of "Mon, 3 Nov 2025 23:43:51 +0100") References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 04 Nov 2025 13:39:04 +0100 Message-ID: <867bw6vuon.fsf@ltc.des.dev> 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 Thomas Schweikle writes: > It is broken. It only works if you unpack installation=C2=A0from CD, DVD = or > file. In all other cases it breaks. etcupdate has a "henn and egg" > problem. If you build from sources it wont work. Regardless at which > position you'll try to "etcupdate extract". It only works if you > unpacked "/etc" from CD, DVD, or file. If it was cloned by "git > clone=C2=A0https://github.com/freebsd/freebsd-src.git=C2=A0/usr/src" foll= owed by > "git checkout" or not it will break. It will even break if you first > build world and or not kernel. It goes haywire if you just wipe > sources, and start from scratch. None of this is true, and it's bordering on harrassment. I don't know why it's not working in your case and I don't care enough to spend several days debugging it remotely over email, but it works fine for other people and I've given you a workaround, so kindly knock it off. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Nov 4 13:42:22 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 4d18n44QXvz6G5s0 for ; Tue, 04 Nov 2025 13:43:52 +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 4d18n40bwnz42GQ for ; Tue, 04 Nov 2025 13:43:51 +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 5A4DgMBG052663 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 4 Nov 2025 14:43:39 +0100 (CET) (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=1762263819; bh=cSQSEPJnbBHh2azjjh7XPo3JgO+eQ2y4krPjJlOYCRU=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=g5X9DPJT2ZETZcX9TtdZhftZv6az0/2tgG7mU2LH+51l1xsfQrD+MRjA0pPWRHM/B VUgAj6jJ8zcE+BsD9G4BctJjWOCFi8iBt5q295D9S279q7HfPNyGwRpHbcGRg+EhMO +0QEF1piLObzNiUA9vkRAczaZN3m7z207RbZiZkLeeCfryWndUjmGaF7xf58Fds+yT pdI3bIj8LIa2ZS47XZEVSFQ5TAgNsJ5R5Gs5BBbtb7s7NU72I192OHYRD18SDEcWK9 XU42cu9FCTDkVWI1Bqz+HeKCmT2vg3b4yiLFYVfeoAy05QTDVoWEZkA1T2PXicOix1 tVvV/TZAr4kbw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------K0lbNcpYHQStCHge030FdFth" Message-ID: <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> Date: Tue, 4 Nov 2025 14:42:22 +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: "etcupdate extract" -- Failed to build new tree. To: Thomas Schweikle Cc: freebsd-current@freebsd.org References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> 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: 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: 4d18n40bwnz42GQ This is a multi-part message in MIME format. --------------K0lbNcpYHQStCHge030FdFth Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 3.11.2025 o 23:43, Thomas Schweikle pisze: > Followed your idea: > > # make buildworld > # make buildkernel > # mergemaster > # etcupdate extract > Failed to build new tree. > > It is broken. It only works if you unpack installation from CD, DVD or > file. In all other cases it breaks. etcupdate has a "henn and egg" > problem. If you build from sources it wont work. Regardless at which > position you'll try to "etcupdate extract". It only works if you > unpacked "/etc" from CD, DVD, or file. If it was cloned by "git clone > https://github.com/freebsd/freebsd-src.git /usr/src" followed by "git > checkout" or not it will break. It will even break if you first build > world and or not kernel. It goes haywire if you just wipe sources, and > start from scratch. > etcupdate needs something not there, if you build "/usr/src" by "git > clone https://github.com/freebsd/freebsd-src.git /usr/src", then > building world, and kernel but it is there if you unpack sources from > tarball. > Hello Thomas, the user experience is crucial for the FreeBSD community. We should not abandon users who are continuously upgrading from FreeBSD 5.0-RELEASE to FreeBSD 15.0-STABLE, but debugging in such environments can be difficult. My guess is that something nonstandard in your make.conf or src.conf is preventing etcupdate from working correctly on that system. Please examine and audit these files carefully. To clarify, during the transition from mergemaster to etcupdate, it's better to run etcupdate multiple times, even more than required, since it can sometimes behave unpredictably, generating conflicts - especially if there are old files left in /var/db/etcupdate but you attempt to restart the migration from mergemaster to etcupdate. If /var/db/etcupdate/ does not exist before the step "etcupdate extract", the transition process should be much smoother and more straightforward. Cheers Marek --------------K0lbNcpYHQStCHge030FdFth Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
W dniu 3.11.2025 o 23:43, Thomas Schweikle pisze:
Followed your idea:

# make buildworld
# make buildkernel
# mergemaster
# etcupdate extract
Failed to build new tree.

It is broken. It only works if you unpack installation from CD, DVD or file. In all other cases it breaks. etcupdate has a "henn and egg" problem. If you build from sources it wont work. Regardless at which position you'll try to "etcupdate extract". It only works if you unpacked "/etc" from CD, DVD, or file. If it was cloned by "git clone https://github.com/freebsd/freebsd-src.git /usr/src" followed by "git checkout" or not it will break. It will even break if you first build world and or not kernel. It goes haywire if you just wipe sources, and start from scratch.
etcupdate needs something not there, if you build "/usr/src" by "git clone https://github.com/freebsd/freebsd-src.git /usr/src", then building world, and kernel but it is there if you unpack sources from tarball.

Hello Thomas,

the user experience is crucial for the FreeBSD community. We should not abandon users who are continuously upgrading from FreeBSD 5.0-RELEASE to FreeBSD 15.0-STABLE, but debugging in such environments can be difficult. My guess is that something nonstandard in your make.conf or src.conf is preventing etcupdate from working correctly on that system. Please examine and audit these files carefully.

To clarify, during the transition from mergemaster to etcupdate,  it's better to run etcupdate multiple times, even more than required, since it can sometimes behave unpredictably, generating conflicts - especially if there are old files left in /var/db/etcupdate but you attempt to restart the migration from mergemaster to etcupdate. If /var/db/etcupdate/ does not exist before the step "etcupdate extract", the transition process should be much smoother and more straightforward.

Cheers
Marek


--------------K0lbNcpYHQStCHge030FdFth-- From nobody Tue Nov 4 14:59:41 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 4d1BSq2Bndz6GCYP for ; Tue, 04 Nov 2025 14:59:55 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4d1BSn2J5Gz3K2v for ; Tue, 04 Nov 2025 14:59:52 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=a1Mm9jVn; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762268383; bh=VwM8r4nluqF6cfZjD/4PLel7PUUEv/mCcR61VDhSFgA=; h=Date:From:To:Subject:In-Reply-To:References; b=a1Mm9jVnu3MKXiCCMOx7Klxt3a6mQdm33ClhE+xKKpH53JLnBkiA8RxAQasCN38Gn 7gcSnyF4oGNprbaLkASwL2956wsmq9fEu7KYOov0EQ6ih8+VwYVO72P6xbKMXa5750 tq6SqMBdTkkDcLxHPwexTr0MZBVLMHzDD7HbYJPO+vglSpCCSYm+KQeJCYypCvCi80 /Fa40HgHoJ3pQA0LVkMthWyToJ9bZEs1n0Vkw1rDMBgkKhBz8lR3rZ08j9/al8NgSW mVlwIH2IZpetps1wvvS7A7bZWV/vmaS/KULuFz64v31ot3GM28IF81dPyIeLaM/RIt ZeSaNq0HBtxfj69bTdof9IWXVF5FL9tfbVVvFC8fI1wgAmk2H56i6K7Mmm6eUGGgml m0nTWCLs9KzqengJHU3UXScKGso7cc14AhWAyf0nQ6UscMwPFdJpHiI1RZ9iGXdyj1 RTh/72fFjh/rJEOF+r8Tp+JOY7hdr5psQ1hDPOegJtOoAS0QZ+oq+lLuJ5/ny6fTys Q0QEUyHKaIDtYnC+K+/+vK2eVeVVZlqzCsX/29yKVINmfmXqw6oQ8vdRIA975drxr8 zDE/0g9CwUgGM6lyRhEtKAXHj5tA6j6wu2qz8gedD3Do77RvRatsQY4W0GA/Bc7PHz dOGUZyMjHYcJ2TqszdgZQHTQ= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id D7FD45D39FF for ; Tue, 04 Nov 2025 16:59:42 +0200 (EET) Date: Tue, 04 Nov 2025 16:59:41 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: "etcupdate extract" -- Failed to build new tree. User-Agent: K-9 Mail for Android In-Reply-To: <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> Message-ID: <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> 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 [-0.79 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4d1BSn2J5Gz3K2v something bad clearly happened in that machine if it's able to selfhost bui= ld itself and work, except etcupdate=2E and that for a long time i don't see any reason getting pissed about his machine mysteriously not w= orking, despite i haven't broken any machine myself since i installed first= fbsd, 4=2E6 unsure how to go from here=2E unsure if src=2Econf or make=2Econf matters = here if this happens in currently actively supported fbsd release, maybe etcupd= ate needs a bugfix to cleanup for edge cases if it's in unsupported, that should not cause any "pissages" either=2E fix= is somewhere so, the admin updated files manually because he was not able to get it wor= king? i bet you can recreate it and fix it for future cases since i haven't ever broken etcupdate, i don't know which data it uses as = input=2E but seems like it reads wrong data out of somewhere=2E and entire = machine works, except this? i mean if this was bad upgrade leftover, how to fix? i mean doesn't etcupd= ate get rework now, for pkgbase=2E while we do that, maybe it could be made= to handle this=2E or maybe even given non-destructive nuke mode so people = can start clean i don't think it's really entirely user error, considering he didn't break= the machine i'm curious too=2E at worst you could do other install in another machine = and compare dirs as something must differ there=2E then, according to findi= ngs, fix the old machine=2E maybe while doing this, some new bugfix idea ap= pears but hell with getting mad over machine=2E he's pissed too, everyone's piss= ed, server is not working and no productive work have been done here maybe something got lost in translation too From nobody Tue Nov 4 15:41:06 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 4d1CNQ1289z6GGk1 for ; Tue, 04 Nov 2025 15:41:10 +0000 (UTC) (envelope-from mhorne@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 4d1CNQ0YQSz3Sh5; Tue, 04 Nov 2025 15:41:10 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762270870; 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=26bTjGVM5RU+VopwRfKBHW4hyLj7czWHGfB4ly3jNrA=; b=DOIW8gIJ4urgfeab7hyQS3CpZq3MP0TA/KfstywH6hDMeyXGtkWE1WbfiZNYdkiM4Oc/fG 7G36Hg3sTvecCYnOigiP6S4jFlb7UlDU0C6wdUDw/1mavoQgFPs6tOboxykx7PSxqSnxMa pvk3prqqQ+sTeWkkvCxsvGAjFciktO8L9LoQ2XFfnF5RE/gTMfwswnrDzBT4MxDbgzbmRy 5/8xbRsQ4bWFYabx8TW3gN+jXAr8L13isrlNLjing1ncC67GLY87DFEOtLCOwBjEidTaQH jYw+XBwove7JqnYJLQ03riwbhkOotJ71TPouAqyYVPqkZjVNjqGZqC9c/QuTqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762270870; 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=26bTjGVM5RU+VopwRfKBHW4hyLj7czWHGfB4ly3jNrA=; b=VHrnB1mghr8u/mEBhstQ3NEkqFBOOy8ZvkQxRPFu6UhdM/Ihqxd5zDJmvAO4JW21wYMXEH Nb1Pmj2/rIFEA4gbLlqAcX/68VKJyXDf0C3tvIX17CdpkNT6eOuWisSyn2CU+zqyNrbiX4 BE/+AI9g/7Ens0n7FJt9B/OIdY3nEERUFT0ETp4vfq6LUzvNKemHZ4gvBDDtVn5TIrIIpK YI6yP0y52YkG/TZa1sR806SBOxcV7nT3sWdkxPEKkDHWprT0o2sscNhN5QvlX4edgcelBy NB//KsHOy1z4puhEipmIM7T2Ex9QrH6JFEVvdchl6aqyUzBqoVvAVFGIpkjZcw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762270870; a=rsa-sha256; cv=none; b=pKnB9Vo/A5WGqrhi9sc0i+uVSgeiiDfDI2ziRzlhiEINiwSF+tH58Wo+nAMxkTBNI8a8zk Uv/krwE13a4XWHN/iZL4pQswuFFu9bvec/I0aG548uquQ8+DNPjGjJ8p3tkve4Ek4gqXbN lGbuGfLcc7KAsXRYct2pyIrBf8W1du4/iivhQvzgFYGapzo92QENefUi5fB3vkty87hoqr VgyfZZI6y4rfVHFark5kaj+wrM+ttfEDb8H0QI8hpCKqNOqKbpOB2H9Di1iFkAvO9/2gxN 7FNfdMQbejCBybY+uFcXOhAbZSuuJvsquuvXI4kABqzxcrtU/o/BC6qMin/y6A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.2.224] (unknown [142.68.228.197]) (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: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d1CNP65bdzQZP; Tue, 04 Nov 2025 15:41:09 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: <2184dc51-3ab9-479c-be24-3bbd7f2c8809@freebsd.org> Date: Tue, 4 Nov 2025 11:41:06 -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: db> reset -> panic: lock (sleep mutex) eventhandler not locked @ /usr/src/sys/kern/subr_eventhandler.c:272 To: Ryan Libby , "Bjoern A. Zeeb" Cc: current@freebsd.org References: Content-Language: en-CA From: Mitchell Horne In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi both, On 10/28/25 06:59, Ryan Libby wrote: > On Tue, Oct 28, 2025 at 2:46 AM Ryan Libby wrote: >> >> On Mon, Oct 27, 2025 at 7:31 AM Bjoern A. Zeeb >> wrote: >>> >>> Hi, >>> >>> on main-ish I get the following. I am a bit concerned as over the last >>> year or two our reset paths had issues like this more and more. >>> >>> >>> db> reset >>> panic: lock (sleep mutex) eventhandler not locked @ /usr/src/sys/kern/subr_eventhandler.c:272 >>> cpuid = 1 >>> time = 1025 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >>> vpanic() at vpanic+0x1a0 >>> panic() at panic+0x48 >>> witness_unlock() at witness_unlock+0x140 >>> __mtx_unlock_flags() at __mtx_unlock_flags+0x54 >>> eventhandler_find_list() at eventhandler_find_list+0xbc >>> kern_reboot() at kern_reboot+0x244 >>> db_reset() at db_reset+0xec >>> db_command() at db_command+0x2f4 >>> db_command_loop() at db_command_loop+0x58 >>> db_trap() at db_trap+0x100 >>> kdb_trap() at kdb_trap+0x350 >>> handle_el1h_sync() at handle_el1h_sync+0x18 >>> --- exception, esr 0xf2000000 >>> kdb_alt_break_internal() at kdb_alt_break_internal+0x1a8 >>> kdb_alt_break() at kdb_alt_break+0x10 >>> uart_intr_rxready() at uart_intr_rxready+0x88 >>> uart_intr() at uart_intr+0x124 >>> intr_event_handle() at intr_event_handle+0xf4 >>> intr_isrc_dispatch() at intr_isrc_dispatch+0x60 >>> arm_gic_intr() at arm_gic_intr+0x118 >>> intr_irq_handler() at intr_irq_handler+0x98 >>> handle_el1h_irq() at handle_el1h_irq+0x18 >>> --- interrupt >>> cpu_idle() at cpu_idle+0x78 >>> sched_idletd() at sched_idletd+0x494 >>> fork_exit() at fork_exit+0x78 >>> fork_trampoline() at fork_trampoline+0x18 >>> Uptime: 17m5s >>> Automatic reboot in 15 seconds - press a key on the console to abort >>> >>> -- >>> Bjoern A. Zeeb r15:7 >>> Bjoern, I apologize that this change once again is hindering the reset path. I share your concern, as do others, please see the renewed discussion for a possible path forward: https://reviews.freebsd.org/D37981 >> >> Would your kernel config match this condition in sys/sys/mutex.h? >> #if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >> >> It looks like we might be missing some SCHEDULER_STOPPED() checks in >> those code paths. It's a twisty maze of macros that I haven't totally >> followed though. td_locks might be getting broken too. >> >> Ryan > > Reading sys/sys/_lock.h, LOCK_DEBUG will be on with WITNESS, which this > kernel clearly has (and also with INVARIANTS, both of which are defaults > for GENERIC). > Ryan, thanks for your analysis. This one in particular was known to me, and I've just put the change up in phabricator. As best I can tell this is all that is missing... https://reviews.freebsd.org/D53582 Best, Mitchell From nobody Tue Nov 4 16:21:15 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 4d1DGr2Qppz6GKrM for ; Tue, 04 Nov 2025 16:21:24 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 4d1DGq5YKnz3byn for ; Tue, 04 Nov 2025 16:21:23 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jhD2dBdy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of drsnx60@gmail.com designates 2a00:1450:4864:20::131 as permitted sender) smtp.mailfrom=drsnx60@gmail.com Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-57bd482dfd2so5687899e87.2 for ; Tue, 04 Nov 2025 08:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762273277; x=1762878077; darn=freebsd.org; h=organization:subject:from:to:content-language:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=wrvNutPnEvbS7MZix4sAa87WidSsSFGDktzO+dD6Bes=; b=jhD2dBdyZE+IiAKs7/8Dz18NlVul8Iu8sK06ukYiv+B28kq3ZrdoQb9TpjMUdCsKeO fW14EPg4OzcXxxVQbMLDrtZSoUV/tMgVqcA41BeZtuqsOzFlabAFdegTL2PSv1/j4I9K ayr6Am+ZZt85L5RVoJ010KO37+Kjo7K6J299LGWABG9jFjEfUVBaOoRqcW+oZjuBZkSA bY2uKsSCeOn2A+6mnntHNVW5e78HuM095OqLtp1DSoduEcafFIt04j1KiMRioOPFwdV4 xDk/OqYc74IZ3my4TaQ+MBjksb1TAvLWCCEGXQe6Wwu5lC5J/gYMa9vRjgJT7JyMgjm9 CB4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762273277; x=1762878077; h=organization:subject:from:to:content-language:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=wrvNutPnEvbS7MZix4sAa87WidSsSFGDktzO+dD6Bes=; b=Tk9HDTpbParaQKWV01PZKNQSNihBct/Pn9MsC6b/t6oai9tI4MwZBAQU624e5GalOz 2HQef9P+Dw79p+un3a/mAIenK29DTcduDCceSp+g4/TeNBjFJcg4ZXETWlgOCQid0gbX ew57ruRH70HXwSjouB4HjOG1QiYYjiZzICZfK5ufXiiEZjOpUMvmzqxeNo6kjITdQWRZ SnYmjIdHjq6SxSAzf97368HiojFEr6nY44KWTn7TGrjgmm2yG/UKC/vHxCIi6AHljgWv m2su7BFRJjRnVBIWZOJ2IDXbxOfnyZ1t3i8ybFKJH9yeFlDbERzxHzmwr4QkkNdIPfje ViDA== X-Forwarded-Encrypted: i=1; AJvYcCVPZYLZ9dySuH44q0dpBl0uGXfw1cdcPYeEUmmc/OfuCEdEpCBGTiUekVjs9XyhI7HJnnRMv1g4A3BmDjaNpgk=@freebsd.org X-Gm-Message-State: AOJu0YzQ2ZQ8arPbgtYPsHdJ1gEHEWcjrXElVrpc+SC3L/JRhYB2aI24 BYwIiQJTT0SH1DFjIkeVwdjTkch6CBB2/EHJWB54cRk3Tn2W4BRKnn6k9b3b4A== X-Gm-Gg: ASbGncuslOd5WlAgZassjt8L27iWKdSxRT4qrZGnVLdy9KGDE9Kcuh720zw2Gp6xH1L yS2ZsjjEFR1ay+HRh4tmIBUIg5fBUe3R2YS+cpwo+LhPSQuAdWlT1s/mNjBngKd5x8j70bbjIRJ tSfCSf/k1oW0be43rLavLT6lipo2wP7yamap0ZiSvbRcFTASkS7yj8x0NpbBKz/YZYc89+5CijE aJsc0f9Y+iiP8gvgELeeRnugfsmpqmS9gGSSA5pOF2IIGppfgDeo4eGESQ8X3aO3ZIUjDOiPhyn faBD3Ls/wQ4hn7i8B5W/Ffthu1oHC+o9tyQ8J45/KORKHYQ/EhZQKjMgbBQOipvQ420GYf+NM6K 8qO9G9wQqjtSp8d0pSl3h84OyEyCRky54UAkx3WcOa3HLnGCqgUOrDAEoJI4QBMXrvW1YUQ0dU3 2m/TAv+RO1xfwi9V0Ho7c= X-Google-Smtp-Source: AGHT+IGydQ28lSlCq2qLEXdwODZt4KW0mjkdtFbQBLKDW3Ul7JajbQi54+xIBx14/SCTo4DumY38ow== X-Received: by 2002:a05:6512:33c7:b0:591:c898:e82b with SMTP id 2adb3069b0e04-5941d4f5319mr4911044e87.8.1762273276679; Tue, 04 Nov 2025 08:21:16 -0800 (PST) Received: from [192.168.2.131] (host.62.13.8.86.bitcom.se. [62.13.8.86]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-594344398f4sm835010e87.64.2025.11.04.08.21.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Nov 2025 08:21:16 -0800 (PST) Content-Type: multipart/alternative; boundary="------------wgDsfPc5xhsVHb0QGkfJpt6n" Message-ID: <0151da5a-82df-4d2b-bf03-7e1e0e0f5de9@gmail.com> Date: Tue, 4 Nov 2025 17:21:15 +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 Content-Language: sv-SE To: freebsd-desktop@freebsd.org, FreeBSD Current , Colin Percival From: Lars Tunkrans Subject: [LDWG] additional requiremetns to be able to install KDE DESKTOP on FBSD15 from install media. Organization: Retiered X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.985]; 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)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::131:from] X-Rspamd-Queue-Id: 4d1DGq5YKnz3byn This is a multi-part message in MIME format. --------------wgDsfPc5xhsVHb0QGkfJpt6n Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi,    I  have  been  playing  around  with  15-Beta4  these last days.    As  discussed  in  the  current mailinglist  the  OLD  DVD-R format  of  4.7 GB    is no longer   large enough  to  include all  thats  needed.    I  propose  that the  recommendation  for   15.0 release  will be  to  use  the  8.5 GB  DVD-DL   media ( Dual Layer )   if you need to use OPTICAL dvd.   I have  used  DVD+R-DL   with  no  issues  for  the  15-ALPHA and  15-BETA  snapshots.   Im happy  to  report  that  installing  Packages  from Installmedia  now  is  working.  Its  possible    to  do  :  #  mkdir /dist  # mount_cd9660  /dev/cd0  /dist  # export REPOS_DIR=/dist/packages/repos  # pkg bootstrap # pkg install  xorg gnome kde firefox sddm *However   there are  no   Graphics  drivers  on  the install-DVD.iso.  these  should be  added * so  that  the  novice  user  can install  a  working  Desktop  from the  installmedia. Me being an  Nvidia guy,   had  to do  the  following  via  the internet connection  to  get  the  KDE-6 desktop working . someone  used  to  build  AMD-GPU  /  INTEL-GPU      setups should list  whats  needed   for  these  GPUs .   Obviously  establishing  the  network  connection.   ( by answering  the questions  in  the  installer )  then; # pkg install  nvidia-drm-kmod  nvidia-xconfig nvidia-settings nvidia-texture-tools #  sysrc linux_enable="YES" #  sysrc sddm_enable="YES" #  sysrc kld_list="nvidia-modeset nvidia-drm" #  echo "hw.nvidiadrm.modeset=1" >> /boot/loader.conf #  kldload linux linux64 # pkg install  linux_base-rl9-9 # echo "proc            /proc   procfs          rw     0     0" >> /etc/fstab # echo "linprocfs   /compat/linux/proc  linprocfs       rw      0      0"  >> /etc/fstab # echo "linsysfs   /compat/linux/sys   linsysfs        rw      0      0"  >> /etc/fstab *Reboot  !*      (  and  you  need  to select  Plasma/X11   in  the  SDDM menu , after  reboot  )    SO in all  these  15  commands  results in  a  working graphical  desktop  .    To  achive  FreeBSD  adoption  on  laptops,   this  needs  to be  made availbel,     Put in  a  menu   or  put in a script   so  a  novice   user can  run it.     Regards -- ------------------------- Lars Tunkrans Oracle SPARC/Solaris System Administrator Fujitsu M12 SPARC Specilaist --------------wgDsfPc5xhsVHb0QGkfJpt6n Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


Hi,  

   I  have  been  playing  around  with  15-Beta4  these last  days. 

   As  discussed  in  the  current mailinglist  the  OLD  DVD-R  format  of  4.7 GB    is no longer 
  large enough  to  include all  thats  needed.    I  propose  that  the  recommendation  for   15.0 release 
 will be  to  use  the  8.5 GB  DVD-DL   media ( Dual Layer )   if you need to use OPTICAL dvd. 
  I have  used  DVD+R-DL   with  no  issues  for  the  15-ALPHA  and  15-BETA  snapshots. 
  Im happy  to  report  that  installing  Packages  from  Installmedia  now  is  working. 

 Its  possible    to  do  :  

 #  mkdir /dist 
 # mount_cd9660  /dev/cd0  /dist 
 # export REPOS_DIR=/dist/packages/repos 
 # pkg bootstrap 
# pkg install  xorg gnome kde firefox sddm 

 However   there are  no   Graphics  drivers  on  the  install-DVD.iso.  these  should be  added  

so  that  the  novice  user  can install  a  working  Desktop  from  the  installmedia. 
Me being an  Nvidia guy,   had  to do  the  following  via  the  internet connection  to  get  the  KDE-6 desktop working . 
someone  used  to  build  AMD-GPU  /  INTEL-GPU      setups should  list  whats  needed   for  these  GPUs .
  Obviously  establishing  the  network  connection.   ( by answering  the questions  in  the  installer )  
 then;  

  

# pkg install  nvidia-drm-kmod  nvidia-xconfig nvidia-settings nvidia-texture-tools  
#  sysrc linux_enable="YES"
#  sysrc sddm_enable="YES"  
#  sysrc kld_list="nvidia-modeset nvidia-drm"
#  echo "hw.nvidiadrm.modeset=1" >> /boot/loader.conf 
#  kldload linux linux64 
# pkg install  linux_base-rl9-9 
# echo "proc            /proc   procfs          rw     0     0"  >> /etc/fstab 
# echo "linprocfs   /compat/linux/proc  linprocfs       rw      0       0"  >> /etc/fstab
# echo "linsysfs   /compat/linux/sys   linsysfs        rw      0       0"  >> /etc/fstab 

Reboot  !

     (  and  you  need  to select  Plasma/X11   in  the  SDDM  menu , after  reboot  )    

  

   SO in all  these  15  commands  results in  a  working  graphical  desktop  .   

   To  achive  FreeBSD  adoption  on  laptops,   this  needs  to be  made availbel,  

    Put in  a  menu   or  put in a script   so  a  novice   user  can  run it.  


    Regards   




-- 
-------------------------
Lars Tunkrans
Oracle SPARC/Solaris System Administrator
Fujitsu M12 SPARC Specilaist
--------------wgDsfPc5xhsVHb0QGkfJpt6n-- From nobody Tue Nov 4 19:59:17 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 4d1K6Q3TjLz6FBkX for ; Tue, 04 Nov 2025 19:59:26 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 4d1K6P0p43z46Rt for ; Tue, 04 Nov 2025 19:59:25 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=BAOn0tQ6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-4283be7df63so3283757f8f.1 for ; Tue, 04 Nov 2025 11:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762286359; x=1762891159; darn=freebsd.org; h=content-transfer-encoding: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=S6yJpvB7NB0xp96Y1UCXLvDQoAJkrRywrXO0DBxbi/s=; b=BAOn0tQ6SJvHjEnrVeXKRDmYKdLarrSf30BeFsmD5/vnDFyvWZATmHzl9O82QrrMbV TUBYT9rq6ZRLIdS/PuWLA7ppsDRuXXVjDLzYapgZLEmeY3mbE7Tb4d3sfOcfbp0r5Qdd vMYty9UD9XuWYMOXZmCT63tXDYVtWfcvSUE+q6tIOixiFsrmlK9chVS7npERKKQ5+l82 MonNsUtZK3xvj3UN2YlnB0ImJ0+werpAhKoZ4rCeGpgH80niO9AJWOhmqcHrd4qkQ083 EDAeFhdITKkxJ+AHyOmFn5YSqAcUutvk5uXLRWNuJBz5+RkKuO65jJjr8oDBv7vWvALF kCxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762286359; x=1762891159; h=content-transfer-encoding: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=S6yJpvB7NB0xp96Y1UCXLvDQoAJkrRywrXO0DBxbi/s=; b=si6wiMxnUQDT7YSfb9jO9NVr++QClhfjLpxAIBXkjErGY/3uZJOZqdrfpZKi5IJuBL 92pzdvLmC/SlmGUSrc7hRIaeRadZ1grlf7E+YqNC8Jbb2DlKJQUaxnDfJdHqIiNOE8Jo fVfweUj9oTWb8fWKXziuuNoRzonz8Ak+DjrkOc42ckuPangRGS/uD1lDfFzvHMug7DJi bN+6XTOyV9+HhJw+zxxm09rePpj2O2FNBMgTRKw2MhdV/Tf4INK0URHVun363QqoH2yV idOys6DkBSNySloJJi7QrBbWClAVo00SWkrP5mieLyncgaDpboteajxjoZa5SqloTl/T 9hWg== X-Forwarded-Encrypted: i=1; AJvYcCVIRDOBpmRxae8KYisuQcszUFLfKPR1UtmdRyorLPIbAVj3poASpgjZPGdOycwUUkLPPsd0Ixew1A4usytluoQ=@freebsd.org X-Gm-Message-State: AOJu0YxsrHnAVSjSooFnyRfMN0cqb0+5+Ci/6o1jqGl2q3OZ4FemOrUY 9sfrrzDfZCwgT6vLnERbfcFYVWC6//d+eGIJZCq+WLLCIbv+lYqqT7Z5YdYXWg== X-Gm-Gg: ASbGncvJy4WfcHXbE52hnLMLlvX1m9li6yKI0lPx49dRbjnx/Ofeld7ler8ncwlafmv 2FrwyMvBZtOv5QD8TgtXtgcvg5q95F/gFNWHbsbPe2QgFeoquTdZCuGZHxy/7UiUTysvy5TVnPj Tk7/yquZjB2eFaMAJt41T/jdVgu1/6Ce+0tqIM9VNeYX/XNP6cOldVhISbiWJevFXw8Kt3o3cjz lxy++R4PzbpeRzNUIe0GiEvuCQJQ3g5lH59Jv3m2M54QTiD9zAnKgNr/i5lcDXpzw4cSvk02HYl cCMoLjEwg9zkaXWpltys50Tx8239MlRGygFdMauF/ZVlW1No9k4yAu4Z8a0LOLo738aziDSqsOe SmEhlWI9tmUoKh4FxQbDstHuMeNqS7uWfDUffovQTaw0zHNRU8R4NQvvqRL6WJXscCfaMyFAdxc p9fjx+o6mDuzk07e4mUu5jR1q9NxtiJw/5R6k= X-Google-Smtp-Source: AGHT+IGFrunVTC4L+zQ5KeZ13REUo5UeaBKkOkkXz/UbTe9Mk+64eG4GO6MxynYAaK2bHvm1jHEmiQ== X-Received: by 2002:a05:6000:2387:b0:429:bc4c:283d with SMTP id ffacd0b85a97d-429e3305754mr466515f8f.33.1762286358549; Tue, 04 Nov 2025 11:59:18 -0800 (PST) Received: from [192.168.1.4] (host-80-42-67-140.as13285.net. [80.42.67.140]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4775cdc386csm7182705e9.4.2025.11.04.11.59.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Nov 2025 11:59:17 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2025 19:59:17 +0000 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: [LDWG] additional requirements to be able to install KDE DESKTOP on FBSD15 from install media. To: freebsd-desktop@freebsd.org, freebsd-current@freebsd.org References: <0151da5a-82df-4d2b-bf03-7e1e0e0f5de9@gmail.com> 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: <0151da5a-82df-4d2b-bf03-7e1e0e0f5de9@gmail.com> 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]; 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)[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]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from] X-Rspamd-Queue-Id: 4d1K6P0p43z46Rt On 04/11/2025 16:21, Lars Tunkrans wrote: > … no Graphics drivers on the install-DVD.iso.  these should be added … > At a glance: 234 MiB for nvidia-drm-kmod, 32 MiB for drm-kmod, 1 MiB for virtualbox-ose-additions. Additional context, for readers who do not also subscribe to freebsd-stable: > We don't have the final packages built yet.  Once those are available > I'll be looking at what the best set is to pack into 4.7 GB. > > -- > Colin Percival > FreeBSD Release Engineering Lead & EC2 platform maintainer > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid > From nobody Wed Nov 5 15:47: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 4d1qV40YjFz6GWKD for ; Wed, 05 Nov 2025 15:48:12 +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 4d1qV23tBJz3MM0 for ; Wed, 05 Nov 2025 15:48:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=BWLuSkuS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-63b9da57cecso11715835a12.0 for ; Wed, 05 Nov 2025 07:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762357684; x=1762962484; 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=Tv5WgVA4qVrrxMG0NtOlyb9ZdIf6i2QsZ9EI+HVgUy4=; b=BWLuSkuSx/TOHb4uEwofx1W+iL+K22345XYubGNzYkuma3yueeBAD2/z4YBmAy3Ek3 2ZD4jyiuzA/LWmnL6Ow4BDqKxeMJKFsSibn3aBJ+o1aUcS+kDdW/7usPqkj1uZkPNlP5 HadkkVYnXrh7ZoANWd0Zf6C65b7U+8JoIDh3U611hQQIlwyPvwn1hWW9ifuERxLKzafy mSjiwrk5YlPs/fskZF5Zb4ECkfFgCWtCfL2mQMhWCunncwkrYGXgb2o/oY9bHFQIC/+7 XhruTumyRj1VO81sViu17Nta2YEs56rIW3mjjVNmx1PqCGh5bFbektoTsr7ekNdcXusr 6IrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762357684; x=1762962484; 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=Tv5WgVA4qVrrxMG0NtOlyb9ZdIf6i2QsZ9EI+HVgUy4=; b=Q8IMjlEmfiHHWUga3sten2UECoVkxgF5pgcjUvhWOzo3wg8cbmycjknhdXc/T6d/xz Nu3S4t+2BvEhru5m4tkf4FPBQUNfYSoZfkElr6IUlpkuZQ2Na+UJOAZGULzJm4bglvMW U5N24irIUbU4zXtco3GsY9mOVBlJp6bBTR4hWezz++G1nwIG5SSa/VX60vDf6VTtdl8W mBsIjSxLeO6DotiZKbvyA19BQ1Is6/TEwqeINa0EV2VJFZPWqsSRyx2DLOZf6cIHV7tB KkyCB2LXRfIOY8YFVkuC39v1KMivGwKyT1qV1jFVakBfa1xilh8PgJX4r/J917WBV0qI dN1g== X-Forwarded-Encrypted: i=1; AJvYcCUjbU40xr5XsTc3j6VZ5qJ8ENSwfT32X5aElIo/H2wu12dB2yQQf19+fRX6gFyIU6ZoCcZqNLZTSIQZ7KHK/7Q=@freebsd.org X-Gm-Message-State: AOJu0YwNI/c+L+bQgL+eWd9G1ErMj4LMc/O7ii51kIFRUbW+RYYU3K17 EX5RImLEz5xbUYGCEAixby0DPgDEIMcmJ+KHOB9GOzC2GcP4cr9Au5b3w7XI41W494PH3IBdTRj 2vXvULxN6MrruMNfFSKvK4DsJNxJbYw== X-Gm-Gg: ASbGncvjgivGHDT2fjmDQPzVVs5JUYx/E6aTPWmiaJWpasEjGhLHXQWY0hLYwEC7WZb qAFIFZos7dV53Ku1Oed9H8ZklUYEPNkVyfbLW+Ak/7Vk7OK+VhWroztDFl9bXpVNtciusu8u5AM kzOhNn0+WIcQxLMuk8GntpyXGheY5ug+ccMss6A64Oun59T2c+SLmpeEnv+ZBFlkDpPlso1L2PW GY9sWv3Fb1sfJ2Q8XCFa7sOh1ecPnGokAd740vXf0cYOR3fVliPtbs+uf0rysPPmFgeWscrCW83 VP0reIbIkW+ATOzB X-Google-Smtp-Source: AGHT+IFh+JgAbfnqcC2L4qK370zOsrKSQy0G8q/mLI5uIOcysV4IopaTnJa+YmyVaZucSktYqvFAfqkeThi3Xhgmfhk= X-Received: by 2002:a05:6402:13cd:b0:640:952d:f602 with SMTP id 4fb4d7f45d1cf-6410589939emr3695307a12.6.1762357683850; Wed, 05 Nov 2025 07:48:03 -0800 (PST) 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: Rick Macklem Date: Wed, 5 Nov 2025 07:47:48 -0800 X-Gm-Features: AWmQ_bnz1eq75XsVaXsxrP-oTJIWo5lFEo17U-0Mnw-7Zki9WP_Gk7-7mdlXcYw Message-ID: Subject: Re: RFC: NFS over RDMA To: John Baldwin Cc: Konstantin Belousov , FreeBSD CURRENT , Navdeep Parhar , "erj@freebsd.org" , "aehrenberg@nvidia.com" , slavash@nvidia.com, "sreekanth.reddy@broadcom.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.95)[-0.951]; 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]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; 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::52d:from] X-Rspamd-Queue-Id: 4d1qV23tBJz3MM0 On Mon, Nov 3, 2025 at 10:10=E2=80=AFPM Rick Macklem wrote: > > On Mon, Nov 3, 2025 at 6:35=E2=80=AFAM John Baldwin wro= te: > > > > On 11/1/25 17:26, Rick Macklem wrote: > > > On Sat, Nov 1, 2025 at 2:10=E2=80=AFPM Konstantin Belousov wrote: > > >> > > >> On Sat, Nov 01, 2025 at 02:03:59PM -0700, Rick Macklem wrote: > > >>> On Sat, Nov 1, 2025 at 1:50=E2=80=AFPM Konstantin Belousov wrote: > > >>>> > > >>>> Added Slava Schwartsman. > > >>>> > > >>>> On Sat, Nov 01, 2025 at 01:11:02PM -0700, Rick Macklem wrote: > > >>>>> Hi, > > >>>>> > > >>>>> I've had NFS over RDMA on my todo list for a very loonnnggg > > >>>>> time. I've avoided it because I haven't had a way to test it, > > >>>>> but I'm now going to start working on it. (A bunch of this work > > >>>>> is already done for NFS-over-TLS which added code for handling > > >>>>> M_EXTPG mbufs.) > > >>>>> > > >>>>> >From RFC-8166, there appears to be 4 operations the krpc > > >>>>> needs to do: > > >>>>> send-rdma - Send on the payload stream (sending messages that > > >>>>> are kept in order). > > >>>>> recv-rdma - Receive the above. > > >>>>> ddp-write - Do a write of DDP data. > > >>>>> ddp-read - Do a read of DDP data. > > >>>>> > > >>>>> So, here is how I see the krpc doing this. > > >>>>> An NFS write RPC for example: > > >>>>> - The NFS client code packages the Write RPC XDR as follows: > > >>>>> - 1 or more mbufs/mbuf_clusters of XDR for the NFS arguments > > >>>>> that precede the write data. > > >>>>> - an mbuf that indicates "start of ddp-read". (Maybe use M_PRO= TO1?) > > >>>>> - 1 or more M_EXTPG mbugs with page(s) loaded with the data to= be > > >>>>> written. > > >>>>> - 0 or more mbufs/mbuf_clusters with additional RPC request XD= R. > > >>>>> > > >>>>> This would be passed to the krpc which would... > > >>>>> - the mbufs up to "start of ddp" in the payload stream. > > >>>>> - Would specify a ddp-read for the pages from the M_EXTPG mbufs > > >>>>> and send that in the payload stream. > > >>>>> - send the remaining mbufs/mbuf_clusters in the payload stream > > >>>>> > > >>>>> The NFS server end would process the received payload stream, > > >>>>> putting the non-ddp stuff in mbufs/mbuf_clusters. > > >>>>> It would do the ddp-read of the data into anonymous pages it allo= cates > > >>>>> and would associate these with M_EXTPG mbufs. > > >>>>> It would put any remaining payload stream stuff for the RPC messa= ge in > > >>>>> additional mbufs/mbuf_clusters. > > >>>>> --> Call the NFS server with the mbuf list for processing. > > >>>>> - When the NFS server gets to the write data (in M_EXTPG mb= ufs) > > >>>>> it would set up a uio/iovec for the pages and call VOP_WR= ITE(). > > >>>>> > > >>>>> Now, the above is straightforward for me, since I know the NFS an= d > > >>>>> krpc code fairly well. > > >>>>> But that is where my expertise ends. > > >>>>> > > >>>>> So, what kind of calls do the drivers provide to send and receive > > >>>>> what RFC-8166 calls the payload stream? > > >>>>> > > >>>>> And what kind of calls do the drivers provide to write and read D= DP > > >>>>> chunks? > > >>>>> > > >>>>> Also, if the above sounds way off the mark, please let me know. > > >>>> > > >>>> What you need is, most likely, the infiniband API or KPI to handle > > >>>> RDMA. It is driver-independent, same as for ip NFS you use system= IP > > >>>> stack and not call to ethernet drivers. In fact, most likely the > > >>>> transport used would be not native IB, but IB over UDP (RoCE v2). > > >>>> > > >>>> IB verbs, which is the official interface for both kernel and user= mode, > > >>>> are not well documented. An overview is provided by the document > > >>>> titled "RDMA Aware Networks Programming User Manual", which should > > >>>> be google-able. Otherwise, the Infiniband specication is the refe= rence. This manual is good at explaining how things work, but the detailed example isn't very useful (the verbs it uses aren't in the kernel, etc). It might be more useful for userspace library use? The good news is I found a file in the Linux kernel sources which I find quite readable (it does rdma for their krpc). The really good news is that it is dual licensed, so I think it can be pulled into FreeBSD without problems. I haven't yet decided if I want to try and keep it mostly intact (so that bugfixes can be pulled from Linux for it) or just hack it up to get what I want from it. (The Linux krpc, etc. is quite different, so it would need a lot of #ifdef FreeBSD in it.) Anyhow, here is the copyright, to double check this is ok in FreeBSD? // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause /* * Copyright (c) 2014-2017 Oracle. All rights reserved. * Copyright (c) 2003-2007 Network Appliance, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU * General Public License (GPL) Version 2, available from the file * COPYING in the main directory of this source tree, or the BSD-type * license below: * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above * copyright notice, this list of conditions and the following * disclaimer in the documentation and/or other materials provided * with the distribution. * * Neither the name of the Network Appliance, Inc. nor the names of * its contributors may be used to endorse or promote products * derived from this software without specific prior written * permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ rick > > >>> Thanks. I'll look at that. (I notice that the Intel code references= something > > >>> they call Linux-OpenIB. Hopefully that looks about the same and the > > >>> glue needed to support non-Mellanox drivers isn't too difficult?) > > >> OpenIB is perhaps the reference to the IB code in Linux kernel prope= r > > >> plus userspace libraries from rdma-core. This is what was forked/gr= own > > >> from OFED. > > >> > > >> Intel put efforts into the iWARP, which is sort of alternative for R= oCEv2. > > >> It has RFCs and works over TCP AFAIR, which causes problems for it. > > > Heh, heh. I'm trying to avoid the iWARP vs RoCE wars.;-) > > > (I did see a Mellanox white paper with graphs showing how RoCE outper= forms > > > iWARP.) > > > Intel currently claims to support RoCE on its 810 and 820 NICs. > > > Broadcom also claims to support RoCE, but doesn't mention FreeBSD > > > drivers and Chelsio does iWARP, afaik. > > > > > > For some reason, at the last NFSv4 Bakeathon, Chuck was testing with > > > iWARP and not RoCE? (I haven't asked Chuck why he chose that. It > > > might just be more convenient to set up the siw driver in Linux vs th= e > > > rxe one? He is the main author of RFC-8166, so he's the NFS-over-RDMA= guy.) > > > > > > But it does look like a fun project for the next year. (I recall jhb@= mentioning > > > that NFS-over-TLS wouldn't be easy and it turned out to be a fun > > > little project.) > > > > Konstantin is right though that sys/ofed is Linux OpenIB and has an int= erface > > that should let you do RDMA (both ROCEv2 and iWARP). I'm hoping to use= the APIs > > in sys/ofed to support NVMe over RDMA (both ROCEv2 and iWARP) at some p= oint as > > well. > > > rick > > > > > >> > > >>> > > >>> Btw, if anyone is interested in taking a more active involvement in= this, > > >>> they are more than welcome to do so. (I'm going to be starting wher= e I > > >>> understand things in the krpc/nfs. I'm not looking forward to porti= ng rxe, > > >>> but will probably end up there. I have already had one offer w.r.t.= access > > >>> to a lab that includes Mellanox hardware, but I don't know if remot= e > > >>> debugging will be practical yet.) > > >>> > > >>> rick > > >>> > > >>>> > > >>>> The IB implementation for us is still called OFED for historical r= easons, > > >>>> and it is located in sys/ofed. > > >>>> > > >>>>> > > >>>>> As for testing, I am planning on hacking away at one of the RDMA > > >>>>> in software drivers in Linux to get it working well enough to use= for > > >>>>> testing. Whatever seems to be easiest to get kinda working. > > >>>> Yes rxe driver is the sw RoCE v2 implementation. We looked at the > > >>>> amount of work to port it. Its size is ~12 kLoC, which is compati= ble > > >>>> with libibverbs (userspace core infiniband interface). > > > > Interesting. I'm currently working on merging back several OFED commit= s from > > Linux to sys/ofed (currently I have about 30 commits merged, some older= than > > Hans' last merge, and some newer, some of the newer ones should permit = removing > > compat stubs for some of the newer APIs that are duplicated in bnxt, ir= dma, and > > mlx*). When I get a bit further along I'll post the branch I have for = more > > testing (it is a bunch of individual cherry-picks rather than a giant m= erge). > > > > Porting over rxe could be useful for me as well for some work I am doin= g. > I have https://github.com/rmacklem/freebsd-rdma. For now, I'll only be do= ing > commits to it for the NFS and krpc files. It will be a while before anyt= hing in > it is useful for others. > > I'll email when I get into the rxe port. (If you hurry, you can beat me t= o it;-) > > Others are welcome to push/pull on the above. (Email if you need permissi= ons > changes. I know diddly about github.) > > rick > > > > > -- > > John Baldwin > > From nobody Wed Nov 5 15:52:37 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 4d1qbT01vfz6GWrx for ; Wed, 05 Nov 2025 15:52:53 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4d1qbS43PVz3Q2j for ; Wed, 05 Nov 2025 15:52:52 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=gY782m+v; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-640b0639dabso6942138a12.3 for ; Wed, 05 Nov 2025 07:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762357971; x=1762962771; 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=tbwWMlYYo075jJ3uvG3M5OWVBGm9ydZJMi+x5EAw+Fg=; b=gY782m+vVsIffaAd5uG7S4rQUILyROW9oKiarZLP1rLQJ1jd2TLHX1NH0dO9cN+/IB 7wRz05oGykAylXEYLtc8IYYGG8BW5t81rIov5u/Qd1ERqWXtdYR6Cbd/G61HnGYJUcac dRsFhKQgWp0EiiR2AA4Hn2dyM79dsSv6EHQQQZBSMzia1EJdqAGK+bpzTyw26ggWZzv4 TNnQ2Ns3akeOIw/FawqxN5oKNQtiCS0ghpCPgv59VBMvn+iGUzgjyskt5bTi435PF7Y4 6Lw+VG8ue5TIGpBFRnRgRxVEoz4dVXKNwgCuFooCdw2aOC9bRmGU1mb+06tWgnI047AC umpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762357971; x=1762962771; 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=tbwWMlYYo075jJ3uvG3M5OWVBGm9ydZJMi+x5EAw+Fg=; b=eSsAjS7Llvx42LiqdleKIfOXjcGJ8P9Bc1woP1j9f60PaGqCx0ldDYVcU5wXHxUfPR xAY4QiXomNGPDxhhl7Kak1NnRoO/IMhX0Qb+NGxlVbovrn22BrYpO1s5VKXmzi0rfhmp ihkbvGlqLvJlyZHrwPRN/dSief8vmjchw7NFAmapT3btae4By+xlyf4lCXadkf+FO9As 2q8motLDLUX/mHK9rPoN1Dc4aTliSlhTUW2DVlQ/IjOs8A4s0M+WKnfRCqeQD056w4u8 hwu3VyjO/IpKFfsD1fUWhhXNE0QtzzgTCuhnxM8K0tD6qTMXPNAuqFV3YnzVstVxZxxp 3wpw== X-Forwarded-Encrypted: i=1; AJvYcCXuaOO5sHkx2hXCNgrhXkYcv5jJbSkIDPhHx83q0s0RA2gfcJ7oAqSiFKtTFrSvZbr+a8PbEMmcmbuZSBtZqIw=@freebsd.org X-Gm-Message-State: AOJu0Yw2SnStEXaY5nZC/q0bGGLldLEH1DwGBwibAD2UyeetGLED/4f0 M+PnDkKP4RBU+NC6yoqLf2o9x/y1YkkCksjFEQxKmm3W7WF4NbueeOJckHckxjrRY+2k55bt1pG h+108OxG9gs6cTHwneUtfN2mRhWWGkA== X-Gm-Gg: ASbGncu08o8DUgd7CDxFPsyZa4j5YfdG7Lu2KdbvzQJ1B/fWwSYcGLFlUyIewsysJzP bn++Ldx4JZgkpRfipC902b8gs0FCD2EUZ2GUgCcT7owxzwcX/SMIgRA4VYix8mG5pCpMWLJb/T8 ioOiqtCr2VNmjGzabWgVBhdoQamGx4Wo6Mp/triyXvRIAOE9rxrHebf4hlgEFT8jXXJwXDOGlPg Hu7ozzdYvdi36CHRB0LbujTpMq3Jv0CMF1Zr5I7k36HgkiQxn1q/c3PueQL9fCbNfrC1s6O4hKw Nhu83eP56AsfU5fb X-Google-Smtp-Source: AGHT+IEE7+e6DqRb37/4nfYb5jIn2mZERxR6l47UmG4qBxkEPYJDY4YR/PpkWASnw8ktvqG/5wq3GqyXoJKXYrY/vTI= X-Received: by 2002:a05:6402:42ca:b0:640:eea7:c950 with SMTP id 4fb4d7f45d1cf-641058b3018mr3533287a12.13.1762357971069; Wed, 05 Nov 2025 07:52:51 -0800 (PST) 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: Rick Macklem Date: Wed, 5 Nov 2025 07:52:37 -0800 X-Gm-Features: AWmQ_bndp5kdvkmAvC9xPqx21xRIfAjmohwl3ZmuVWyddUTI0Nlw5llTOoTY7K0 Message-ID: Subject: Re: RFC: NFS over RDMA To: John Baldwin Cc: Konstantin Belousov , FreeBSD CURRENT , Navdeep Parhar , "erj@freebsd.org" , "aehrenberg@nvidia.com" , slavash@nvidia.com, "sreekanth.reddy@broadcom.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.95)[-0.950]; 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]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; 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::52e:from] X-Rspamd-Queue-Id: 4d1qbS43PVz3Q2j On Wed, Nov 5, 2025 at 7:47=E2=80=AFAM Rick Macklem wrote: > > On Mon, Nov 3, 2025 at 10:10=E2=80=AFPM Rick Macklem wrote: > > > > On Mon, Nov 3, 2025 at 6:35=E2=80=AFAM John Baldwin w= rote: > > > > > > On 11/1/25 17:26, Rick Macklem wrote: > > > > On Sat, Nov 1, 2025 at 2:10=E2=80=AFPM Konstantin Belousov wrote: > > > >> > > > >> On Sat, Nov 01, 2025 at 02:03:59PM -0700, Rick Macklem wrote: > > > >>> On Sat, Nov 1, 2025 at 1:50=E2=80=AFPM Konstantin Belousov wrote: > > > >>>> > > > >>>> Added Slava Schwartsman. > > > >>>> > > > >>>> On Sat, Nov 01, 2025 at 01:11:02PM -0700, Rick Macklem wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> I've had NFS over RDMA on my todo list for a very loonnnggg > > > >>>>> time. I've avoided it because I haven't had a way to test it, > > > >>>>> but I'm now going to start working on it. (A bunch of this work > > > >>>>> is already done for NFS-over-TLS which added code for handling > > > >>>>> M_EXTPG mbufs.) > > > >>>>> > > > >>>>> >From RFC-8166, there appears to be 4 operations the krpc > > > >>>>> needs to do: > > > >>>>> send-rdma - Send on the payload stream (sending messages that > > > >>>>> are kept in order). > > > >>>>> recv-rdma - Receive the above. > > > >>>>> ddp-write - Do a write of DDP data. > > > >>>>> ddp-read - Do a read of DDP data. > > > >>>>> > > > >>>>> So, here is how I see the krpc doing this. > > > >>>>> An NFS write RPC for example: > > > >>>>> - The NFS client code packages the Write RPC XDR as follows: > > > >>>>> - 1 or more mbufs/mbuf_clusters of XDR for the NFS arguments > > > >>>>> that precede the write data. > > > >>>>> - an mbuf that indicates "start of ddp-read". (Maybe use M_P= ROTO1?) > > > >>>>> - 1 or more M_EXTPG mbugs with page(s) loaded with the data = to be > > > >>>>> written. > > > >>>>> - 0 or more mbufs/mbuf_clusters with additional RPC request = XDR. > > > >>>>> > > > >>>>> This would be passed to the krpc which would... > > > >>>>> - the mbufs up to "start of ddp" in the payload stream. > > > >>>>> - Would specify a ddp-read for the pages from the M_EXTPG mbu= fs > > > >>>>> and send that in the payload stream. > > > >>>>> - send the remaining mbufs/mbuf_clusters in the payload strea= m > > > >>>>> > > > >>>>> The NFS server end would process the received payload stream, > > > >>>>> putting the non-ddp stuff in mbufs/mbuf_clusters. > > > >>>>> It would do the ddp-read of the data into anonymous pages it al= locates > > > >>>>> and would associate these with M_EXTPG mbufs. > > > >>>>> It would put any remaining payload stream stuff for the RPC mes= sage in > > > >>>>> additional mbufs/mbuf_clusters. > > > >>>>> --> Call the NFS server with the mbuf list for processing. > > > >>>>> - When the NFS server gets to the write data (in M_EXTPG = mbufs) > > > >>>>> it would set up a uio/iovec for the pages and call VOP_= WRITE(). > > > >>>>> > > > >>>>> Now, the above is straightforward for me, since I know the NFS = and > > > >>>>> krpc code fairly well. > > > >>>>> But that is where my expertise ends. > > > >>>>> > > > >>>>> So, what kind of calls do the drivers provide to send and recei= ve > > > >>>>> what RFC-8166 calls the payload stream? > > > >>>>> > > > >>>>> And what kind of calls do the drivers provide to write and read= DDP > > > >>>>> chunks? > > > >>>>> > > > >>>>> Also, if the above sounds way off the mark, please let me know. > > > >>>> > > > >>>> What you need is, most likely, the infiniband API or KPI to hand= le > > > >>>> RDMA. It is driver-independent, same as for ip NFS you use syst= em IP > > > >>>> stack and not call to ethernet drivers. In fact, most likely th= e > > > >>>> transport used would be not native IB, but IB over UDP (RoCE v2)= . > > > >>>> > > > >>>> IB verbs, which is the official interface for both kernel and us= er mode, > > > >>>> are not well documented. An overview is provided by the documen= t > > > >>>> titled "RDMA Aware Networks Programming User Manual", which shou= ld > > > >>>> be google-able. Otherwise, the Infiniband specication is the re= ference. > This manual is good at explaining how things work, but the detailed examp= le > isn't very useful (the verbs it uses aren't in the kernel, etc). It > might be more useful > for userspace library use? Just fyi, the functions named rdma_XXX() seem to be the ones used to get things set up and then the ones named ib_XXX() are used for the actual I/O. (The manual has ones named ibv_XXX(), which don't exist in the kernel code, afaik.) rick > > The good news is I found a file in the Linux kernel sources which I > find quite readable (it does rdma for their krpc). > The really good news is that it is dual licensed, so I think it can > be pulled into FreeBSD without problems. > I haven't yet decided if I want to try and keep it mostly intact (so that > bugfixes can be pulled from Linux for it) or just hack it up to get > what I want from it. (The Linux krpc, etc. is quite different, so it > would need a lot of #ifdef FreeBSD in it.) > > Anyhow, here is the copyright, to double check this is ok in FreeBSD? > > // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause > /* > * Copyright (c) 2014-2017 Oracle. All rights reserved. > * Copyright (c) 2003-2007 Network Appliance, Inc. All rights reserved. > * > * This software is available to you under a choice of one of two > * licenses. You may choose to be licensed under the terms of the GNU > * General Public License (GPL) Version 2, available from the file > * COPYING in the main directory of this source tree, or the BSD-type > * license below: > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * > * Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * > * Redistributions in binary form must reproduce the above > * copyright notice, this list of conditions and the following > * disclaimer in the documentation and/or other materials provided > * with the distribution. > * > * Neither the name of the Network Appliance, Inc. nor the names of > * its contributors may be used to endorse or promote products > * derived from this software without specific prior written > * permission. > * > * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > > rick > > > > >>> Thanks. I'll look at that. (I notice that the Intel code referenc= es something > > > >>> they call Linux-OpenIB. Hopefully that looks about the same and t= he > > > >>> glue needed to support non-Mellanox drivers isn't too difficult?) > > > >> OpenIB is perhaps the reference to the IB code in Linux kernel pro= per > > > >> plus userspace libraries from rdma-core. This is what was forked/= grown > > > >> from OFED. > > > >> > > > >> Intel put efforts into the iWARP, which is sort of alternative for= RoCEv2. > > > >> It has RFCs and works over TCP AFAIR, which causes problems for it= . > > > > Heh, heh. I'm trying to avoid the iWARP vs RoCE wars.;-) > > > > (I did see a Mellanox white paper with graphs showing how RoCE outp= erforms > > > > iWARP.) > > > > Intel currently claims to support RoCE on its 810 and 820 NICs. > > > > Broadcom also claims to support RoCE, but doesn't mention FreeBSD > > > > drivers and Chelsio does iWARP, afaik. > > > > > > > > For some reason, at the last NFSv4 Bakeathon, Chuck was testing wit= h > > > > iWARP and not RoCE? (I haven't asked Chuck why he chose that. It > > > > might just be more convenient to set up the siw driver in Linux vs = the > > > > rxe one? He is the main author of RFC-8166, so he's the NFS-over-RD= MA guy.) > > > > > > > > But it does look like a fun project for the next year. (I recall jh= b@ mentioning > > > > that NFS-over-TLS wouldn't be easy and it turned out to be a fun > > > > little project.) > > > > > > Konstantin is right though that sys/ofed is Linux OpenIB and has an i= nterface > > > that should let you do RDMA (both ROCEv2 and iWARP). I'm hoping to u= se the APIs > > > in sys/ofed to support NVMe over RDMA (both ROCEv2 and iWARP) at some= point as > > > well. > > > > rick > > > > > > > >> > > > >>> > > > >>> Btw, if anyone is interested in taking a more active involvement = in this, > > > >>> they are more than welcome to do so. (I'm going to be starting wh= ere I > > > >>> understand things in the krpc/nfs. I'm not looking forward to por= ting rxe, > > > >>> but will probably end up there. I have already had one offer w.r.= t. access > > > >>> to a lab that includes Mellanox hardware, but I don't know if rem= ote > > > >>> debugging will be practical yet.) > > > >>> > > > >>> rick > > > >>> > > > >>>> > > > >>>> The IB implementation for us is still called OFED for historical= reasons, > > > >>>> and it is located in sys/ofed. > > > >>>> > > > >>>>> > > > >>>>> As for testing, I am planning on hacking away at one of the RDM= A > > > >>>>> in software drivers in Linux to get it working well enough to u= se for > > > >>>>> testing. Whatever seems to be easiest to get kinda working. > > > >>>> Yes rxe driver is the sw RoCE v2 implementation. We looked at t= he > > > >>>> amount of work to port it. Its size is ~12 kLoC, which is compa= tible > > > >>>> with libibverbs (userspace core infiniband interface). > > > > > > Interesting. I'm currently working on merging back several OFED comm= its from > > > Linux to sys/ofed (currently I have about 30 commits merged, some old= er than > > > Hans' last merge, and some newer, some of the newer ones should permi= t removing > > > compat stubs for some of the newer APIs that are duplicated in bnxt, = irdma, and > > > mlx*). When I get a bit further along I'll post the branch I have fo= r more > > > testing (it is a bunch of individual cherry-picks rather than a giant= merge). > > > > > > Porting over rxe could be useful for me as well for some work I am do= ing. > > I have https://github.com/rmacklem/freebsd-rdma. For now, I'll only be = doing > > commits to it for the NFS and krpc files. It will be a while before an= ything in > > it is useful for others. > > > > I'll email when I get into the rxe port. (If you hurry, you can beat me= to it;-) > > > > Others are welcome to push/pull on the above. (Email if you need permis= sions > > changes. I know diddly about github.) > > > > rick > > > > > > > > -- > > > John Baldwin > > > From nobody Wed Nov 5 16:15:04 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 4d1r5G0rX6z6GY6y for ; Wed, 05 Nov 2025 16:15:14 +0000 (UTC) (envelope-from ross@bisd.ro) Received: from ada.kiz.li (ada.kiz.li [38.45.72.165]) (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 4d1r5F2KdMz3TYt for ; Wed, 05 Nov 2025 16:15:13 +0000 (UTC) (envelope-from ross@bisd.ro) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=bisd.ro; spf=pass (mx1.freebsd.org: domain of ross@bisd.ro designates 38.45.72.165 as permitted sender) smtp.mailfrom=ross@bisd.ro Received: from [192.168.1.225] (syn-072-182-130-191.res.spectrum.com [72.182.130.191]) by ada.kiz.li (OpenSMTPD) with ESMTPSA id 7edcd207 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Wed, 5 Nov 2025 11:15:06 -0500 (EST) Message-ID: Date: Wed, 5 Nov 2025 10:15:04 -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: [LDWG] additional requirements to be able to install KDE DESKTOP on FBSD15 from install media. To: freebsd-current@freebsd.org References: <0151da5a-82df-4d2b-bf03-7e1e0e0f5de9@gmail.com> Content-Language: en-US From: "S. Ross Gohlke" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: + X-Spamd-Result: default: False [1.37 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_SHORT(0.96)[0.960]; DMARC_POLICY_ALLOW(-0.50)[bisd.ro,reject]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.01)[0.012]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:174, ipnet:38.45.72.0/24, country:US]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4d1r5F2KdMz3TYt On 11/4/25 13:59, Graham Perrin wrote: > On 04/11/2025 16:21, Lars Tunkrans wrote: > >> … no Graphics drivers on the install-DVD.iso.  these should be added … >> > > At a glance: 234 MiB for nvidia-drm-kmod, 32 MiB for drm-kmod, 1 MiB > for virtualbox-ose-additions. > > Additional context, for readers who do not also subscribe to > freebsd-stable: > > > > >> We don't have the final packages built yet.  Once those are available >> I'll be looking at what the best set is to pack into 4.7 GB. >> >> -- >> Colin Percival >> FreeBSD Release Engineering Lead & EC2 platform maintainer >> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly >> paranoid >> > You could compress the assets in a read-while-compressed format that is automounted. Both uzip and zip can save up to 60% of storage space. For uzip you would need a ton of memory to generate the image, but that is a one-time cost. Consuming the image is pretty efficient. Unless there are a lot of hard links or special files, fuse-zip from ports might work. Otherwise there is mount-zip, which is not in ports. I am not sold on zip, though. I have been trying to build a kernel from source stored in a zip archive and it does not work. Doing the same thing with source stored in a uzip image works as expected. From nobody Wed Nov 5 17:50: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 4d1tCc1C5yz4k8fl for ; Wed, 05 Nov 2025 17:50:52 +0000 (UTC) (envelope-from red_M95@proton.me) Received: from mail-24425.protonmail.ch (mail-24425.protonmail.ch [109.224.244.25]) (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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d1tCZ5Mtmz3gFZ for ; Wed, 05 Nov 2025 17:50:50 +0000 (UTC) (envelope-from red_M95@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=SgkdPfFw; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of red_M95@proton.me designates 109.224.244.25 as permitted sender) smtp.mailfrom=red_M95@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1762365047; x=1762624247; bh=NGvymemodhk9YBVPXnnAtcKlz07nrpJMYYjnoqnkWfU=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=SgkdPfFw2zyadFgfkD/rVoRWNS1pxar8w4AXAAy13J0yK/Lzq3IJq73ie45ycLd6p gFge315961JfD2WAkkubgPmRpP2z7Mpl/a0MsytRQx47GbNpnyRy9J5fxaPZNO3Y0j 0HlhpsSPXV2NhUkFB1FnlqYqEWZa/GVvy0NadxQ6zOvYA2kLP/cqpmSDWBCUy0qh0s ZiiBGSRA6q5cTAaqxw5I3UwQpWERnsT76QAwzm3H21cFwKYRAEv007csTcDZRhfxAL NAcNKMcKLNTT0fch/edNsELfROnILlnCJHb82fODrG1HLKfMSgwYwPyPpNe7MU0JOA FV9XX2KdxEiVw== Date: Wed, 05 Nov 2025 17:50:43 +0000 To: "freebsd-current@FreeBSD.org" From: ruby R53 Subject: make buildworld: "[...] fatal error: 'llvm/Demangle/Demangle.h' file not found", among other errors Message-ID: Feedback-ID: 66100208:user:proton X-Pm-Message-ID: d08a109f3e82fe52c27b5c29d163d7e71cf375e1 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.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; RWL_MAILSPIKE_EXCELLENT(-0.40)[109.224.244.25:from]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; R_SPF_ALLOW(-0.20)[+ip4:109.224.244.0/24]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:62371, ipnet:109.224.244.0/24, country:CH]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[109.224.244.25:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[proton.me:+] X-Rspamd-Queue-Id: 4d1tCZ5Mtmz3gFZ I've tried re-cloning my source tree and am still getting this error when t= rying to build the world, among others. The full error message is --- Demangle/ItaniumDemangle.o --- /usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13:10: = fatal error: 'llvm/Demangle/Demangle.h' file not found Then, I also get these other ones when building with 16 parallel jobs: --- Support/ABIBreak.o --- /usr/src/contrib/llvm-project/llvm/lib/Support/ABIBreak.cpp:9:10: fatal err= or: 'llvm/Config/abi-breaking.h' file not found [...] --- Support/APFloat.o --- /usr/src/contrib/llvm-project/llvm/lib/Support/APFloat.cpp:14:10: fatal err= or: 'llvm/ADT/APFloat.h' file not found [...] --- main.o --- /usr/src/usr.sbin/config/main.cc:49:10: fatal error: 'y.tab.h' file not fou= nd [...] Is my copy broken, or is there something actually missing on the original r= epository? From nobody Wed Nov 5 18:00: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 4d1tQs1PBzz4k9dK for ; Wed, 05 Nov 2025 18:00:37 +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 4d1tQr4J3lz3hQr for ; Wed, 05 Nov 2025 18:00:36 +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 5A5I0YXX058376; Wed, 5 Nov 2025 18:00:34 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 5A5I0YFY058375; Wed, 5 Nov 2025 10:00:34 -0800 (PST) (envelope-from david) Date: Wed, 5 Nov 2025 10:00:34 -0800 From: David Wolfskill To: ruby R53 Cc: "freebsd-current@FreeBSD.org" Subject: Re: make buildworld: "[...] fatal error: 'llvm/Demangle/Demangle.h' file not found", among other errors Message-ID: Mail-Followup-To: David Wolfskill , ruby R53 , "freebsd-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="in8EMzNpLH6467LC" Content-Disposition: inline In-Reply-To: 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: 4d1tQr4J3lz3hQr --in8EMzNpLH6467LC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 05, 2025 at 05:50:43PM +0000, ruby R53 wrote: > I've tried re-cloning my source tree and am still getting this error when= trying to build the world, among others. > The full error message is > --- Demangle/ItaniumDemangle.o --- > /usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13:10= : fatal error: 'llvm/Demangle/Demangle.h' file not found >=20 > ... > Is my copy broken, or is there something actually missing on the original= repository? > .... I don't know the latest commit in your copy of the tree, but I updated =66rom main-n281683-3ccb2d9513e6 to main-n281708-b8697ac70ebf via an in-place source-based update on 4 machines earlier today. One of those machines used -j112; the others used -j14. Peace, david --=20 David H. Wolfskill david@catwhisker.org See https://www.catwhisker.org/~david/publickey.gpg for my public key. --in8EMzNpLH6467LC Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaQuQwl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5a3bAQCa2YI+/PjvC5AePvqZnzPn3/Ni+KPbEfiyXDMt+qn4+QEAtHYhYqR3KT2n Qn+oGstc2zn3wLgt+/qMYCkC521P7Aw= =Pd+1 -----END PGP SIGNATURE----- --in8EMzNpLH6467LC-- From nobody Wed Nov 5 20:37:42 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 4d1xwT4JvPz6572v for ; Wed, 05 Nov 2025 20:38:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4d1xwS4vmvz46N7 for ; Wed, 05 Nov 2025 20:38:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=B8qq6JOW; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762375078; bh=4DqBQmTSqdUCXE2UChFhz5b+G25w1JFDSbZdHsPTI7c=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=B8qq6JOWYTaBYrXhH4qHVCxQznlhwDkg0OcmVr63szyMObQfub6fBSLCwYOZg0loA08aqo2b5Wz2Iq9qVKr0EgCsUvs8x+Pxjqp6lBWHcJ8gmmyJTIKkR45yEIFNMV5S8C8eUMoW6wNa9vEovJxIlx8taSbeXiOWe/y6BFPBkwxEn2DI7xLqsdGeHbjOULfkCuqhfDJG7axvsckRiREmDy6QysoQ5Z+f9IA6JzNKzr8dktGB4Glezv3jN5BGelziwesjI3xaSOMfrj12LkTOfhG+nY/2J212eR4NYhMCXi2p/c53Offz8/tH60ycwM2PzfqV2jpy982jJc3qIQEgqw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762375078; bh=owLoeUjauVtiBPxpkT6ezWB62rqwrgPMPauxSdGUbE+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=h6n4eoKqbu/d8BNg0nkLSLyY1XI1G8P4SujbcpSdrDhtNyMaJclL/soREA0+DWgcVzSavSKA1m8JErhYQypzr7IFsceQGJf8x30lwOw4/B1aBoGI2WlJqyvovcCL1YSbwU4KdEEvCIgjvm1kMv0lZNl+F5RiBsDE2sdQQUPtgoc8hrrhMlTIwOdCZl+65cFicu+WSiLwTkA1vaDvxvvLOaWj4Nu84dowd8vYfEwGnVxSeari88VBv5srICVRmZhMiMLlNdrpusHbk0bYvp1+HotufA4t0MkKiOjjVYs3lMuqZIWBrfhmZsNcakQzAMnunBW2ANJyIsASlK7UZtOKHg== X-YMail-OSG: nDpyAIYVM1mNNgbNera1YYhMGFJvzbC_ByWgpoK5CNgnbRAab1a3sPRZrRC8oEb pxkwIUNr15DU_yGq5YCHVLAvBAEnWLqTCrGPvxJGrVcZcgB5Nk9uFI44EPYZsNRr1kXRVcXAsukE .gWe6jawjRA65HUlL3si7zsdnzaLkM2NHPaQdY4HA2jyR_i_sO8bkFF3LUQydwbMaQ8.EVj_m9t2 Jwl7LwfEMgfF5Zotm0yF3XEiRLWBy59tgIfSLCN4vUFAem6PilecetVRB9mmcm5H5t.wexaJehER TQ19lvyCap0r6z0NAnWvEiRs9sqQC..jtgJXWmuOroAZGL3MaVX9vujSfP8nygq6dFmImYkWvhTL isHV09CKEYW27Bbab_2W5cH5MUTjFvLAteukJVeUjH1bqaIET8u_68z5w6_nI56.e9UlgYaWdYqI dciVMBjsHjdoE7Lr4CfxbGkJSxJoegAG26xxHpXPKU2tKCM6.YUhTdqorn8iXxVagB5OHhseA82x oQT97C1FnPniLuUMl0SWV_S6EGNv.QHiPD6_8IrCLmeECizEEJIOzf36nOQ4ijUm_wwPHbnSsvrf 4DGXpfMT2p_8TG8UkmqnlCRUbv3yjsrLMDrgQisur7YNA_DPCtH5n_tbcNT8WHth1Xtnig2xIroQ DOmPFJPp2iYuTHBbBJcpXOkdNOSrppt6zET5G9qJFxuldci_3cCsu5HUyInBKQVlT.1CXnHKoz5J g_Db9BMwjaRew5quQnQuT0w9BFLQ_mkbPoTf94yglqYk0mLNsiMFlK2mLJITATdUQSrLLcm7JKen 5f0wWWWoPOTl3eqcC.n7VT3293yabFqs17nEkn4IVwveZI38I7HosB3ixt4RzsHWFZGg_t7_HohY HpmeBR0SeytHcpIuhiOu7ExJ7oflGw1AYBGL_Oyzy30rgaas0yQ_.9teZnGelXCHU5SemO9UGZyh zs1mx4Ri2ZUje26fy_MnTJucYnm_Zb38J8e_sXkpkNDLBAzmx.jIxkHl_RTk9JjofkoTjElE_jzU v5J_xjllKVkBy92vWEjHoeQaaxlF9WTTuY18tX9CZlSy0_jZ3cCmUqF2lmt_zXyB4cuXaE94PTPV O.mIChFM7i47yOxH8Ak1InA30hwFRropCGPomIYXVEzWHEGMiGRTg7a7q3IV2nPv3xCg6Zx9qyNJ J6uNKvy2xx.RNk7QtjLi0Kqbxnm3HYen9ADiTURIsvbd6_slmEhANFU2gkAkfJH0qX1ZN8AyhyJw 6Vab9YV8NowQiNKBQewpVJNseJ22dOhu2TV7hykz.SBLWL9tIIjU.K63NcnKicLyA7Dbkh85CeJg dL.ng3izBWjF1rHCX8z9BYLS.XLsr1I3NlEn.YjktBoXIJolPrAgL_ShgqIONihmJ8ElzG8IgPsN Pok7f8j7B08aHpmD9jfYKlZPurBLhNRMM5wRNY9ipJJQ3NWslURXZgr8fOeRjf4t8Noby.CUsrJT NPmwVVe_rBgUaucfg8VkHv6S9aKJPTSIOupXdmyHwJHGzbkf96j2Ja6p7TDxODthHxFdfk_gMx0Q c_DM3Awrd1l6q0eQPZw37FDmB9cSV_F1SoBc85Bix9e50KbfZL_O_e_OfzaEb9..8Vjj8_birakF vVavkdWGNWC6RYg5ZhDVksC4UM0DhdSkAIvpqCptoxItf8G5WisLzIVBxPPzVg8b8MeWr1ouCWyq hyaev02fuXtBVjshjfXlmYNvAWxY0o8BQyT9958afXiW505aQ6z8KCv7m_pnqKm2DKf6ARlm_J.A bmbpXEaQfRExlrJOWZ9ccK6bmNLMpD31qrrwdyO73gHlmrRO_ZjoxdAfmWJz1lJb_NW3nJO24Vnw oyJzMnTA0k29svBn.e50I_EiMOPLtS9mSe7insBEPbj.Q2Y1bbfb5jelnZIoWouqxtt8JwnIpZIp hCfWgAeJoMRPHkPHfUiJBL6lB3.rchQ6U1JGavpiRq6I_fROAwv7zSdz9laJ2tcyjz1YkD09JtYe mvLd9FDE2Dv5W4zpFFkdJaRDUAqv2g_tV7W5HbiJjIBo7Y0NHdT8IzZEj7Lm11vWJW9N6Y7c.DjT PspPxo7QOdLqeFWdKxfyKFoWds7xVcIKDI96c2B_TuxC6X0VWn_jnJnYONNebMTI4KhufZUmbiT6 PMAkmdqfOJtLW6ItnuoG6sdq.MsMCoXUdIY7T2BxWPG.mas6lVLJ8kkYrVEwG624VS6ymnEqXsfZ Axtt5A04JdNwcUwFhEIYvqtcWu2J5OCe_mb3TMQp1Kry4maEqLGqbOlQcxkY5YSX35wyPrOrEXkz 48RO_L2jl X-Sonic-MF: X-Sonic-ID: ae477848-aa1f-4c8e-acc8-01512c95d5e2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Nov 2025 20:37:58 +0000 Received: by hermes--production-gq1-86c5846576-5vm67 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 23035d06e88272d166e96059a2d3d64a; Wed, 05 Nov 2025 20:37:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii 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: make buildworld: "[...] fatal error: 'llvm/Demangle/Demangle.h' file not found", among other errors Message-Id: <1CFD658F-30FC-4F2F-A36B-FE2548E31F4C@yahoo.com> Date: Wed, 5 Nov 2025 12:37:42 -0800 To: red_M95@proton.me, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <1CFD658F-30FC-4F2F-A36B-FE2548E31F4C.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.59)[-0.587]; 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]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; 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.31:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from] X-Rspamd-Queue-Id: 4d1xwS4vmvz46N7 ruby R53 wrote on Date: Wed, 05 Nov 2025 17:50:43 UTC : > I've tried re-cloning my source tree and am still getting this error = when trying to build the world, among others. > The full error message is > --- Demangle/ItaniumDemangle.o --- > = /usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13:10:= fatal error: 'llvm/Demangle/Demangle.h' file not found >=20 > Then, I also get these other ones when building with 16 parallel jobs: > --- Support/ABIBreak.o --- > /usr/src/contrib/llvm-project/llvm/lib/Support/ABIBreak.cpp:9:10: = fatal error: 'llvm/Config/abi-breaking.h' file not found > [...] > --- Support/APFloat.o --- > /usr/src/contrib/llvm-project/llvm/lib/Support/APFloat.cpp:14:10: = fatal error: 'llvm/ADT/APFloat.h' file not found > [...] > --- main.o --- > /usr/src/usr.sbin/config/main.cc:49:10: fatal error: 'y.tab.h' file = not found > [...] >=20 > Is my copy broken, or is there something actually missing on the = original repository? Absent also being able to see the command line that supplied the search = path additions that were in use, I do not see how to know enough from just = the not found messages. Being able to tell the current directory at the time might be involved, depending on what all ends up in the search path. It looks to me like it was expected that: /usr/src/contrib/llvm-project/llvm/include/ would be in the search path and would be the base for finding llvm/Demangle/Demangle.h . (I looked for were all Demangle.h occurred in a local file system of mine.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Nov 6 14:04:52 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 4d2P7P2yfMz6GCFP; Thu, 06 Nov 2025 14:04:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d2P7M6Znvz3xSn; Thu, 06 Nov 2025 14:03:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5A6E4qsX001874 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 6 Nov 2025 06:04:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5A6E4qQM001873; Thu, 6 Nov 2025 06:04:52 -0800 (PST) (envelope-from fbsd) Date: Thu, 6 Nov 2025 06:04:52 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: freebsd-current@freebsd.org Subject: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld 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=us-ascii Content-Disposition: inline X-Spamd-Bar: / X-Spamd-Result: default: False [0.02 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; NEURAL_HAM_LONG(-0.83)[-0.827]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.07)[-0.067]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; DMARC_NA(0.00)[zefox.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4d2P7M6Znvz3xSn For roughly the past year I've been seeing buildworld become unresponsive compiling -current on a Pi2 (armv7). The stoppages seem random, sometimes with no visible memory pressure, other times while swapping. The machine uses a USB mechanican hard drive for root and swap. Numerous attemps to use enter-tilda-control-B to get into the debugger have failed, with absolutely no response. In the most recent case the disk activity light was flashing rapidly, a relatively uncommon event. The frozen top window showed ~312 MB swap in use, less than half of the maximum commonly seen for a -j3 buildworld. Looking at the log file after power-cycling it appeared to have last updated the previous evening, so it seems unlikely it got stuck on a core dump. Reboot was uneventful, with fsck completing successfully. Buildworld has been restarted, it'll pick up where it left off. The last entries in the buildworld log file were: Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateInstantiateDecl.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateVariadic.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaType.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaWasm.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaX86.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/TypeLocBuilder.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTCommon.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReader.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderDecl.pico Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderStmt.pico No warnings or errors of any kind appear on the serial console, ever. Is there some other way to get at debugger services in a case like this? I understand it's possible to run programs under debugger "supervision" at the time of invocation, but would that provide any extra avenues to find out what's going wrong? I think not, but I'd like very much to gather some useful information toward a fix. Thanks for reading, bob prohaska From nobody Thu Nov 6 14:15:49 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 4d2PPL31S0z6GCyJ for ; Thu, 06 Nov 2025 14:16:06 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb12b.google.com (mail-yx1-xb12b.google.com [IPv6:2607:f8b0:4864:20::b12b]) (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 4d2PPK5tRTz40tT for ; Thu, 06 Nov 2025 14:16:05 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=Hen1NVYG; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::b12b) smtp.mailfrom=tomek@cedro.info Received: by mail-yx1-xb12b.google.com with SMTP id 956f58d0204a3-63fc72db706so1042571d50.2 for ; Thu, 06 Nov 2025 06:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1762438563; x=1763043363; 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=i5/qRLvtiYRjdIM9VE1bXFeJJheqHvWFfR+C+pGV8kQ=; b=Hen1NVYGA6m5Uef1flEa8jGNC2dRdLxKFmahv98FiFUvQTlNXyG+ZqPbICZuCKUbYC 8SkeGkEvUDdSL2JIP/Lzr85rurdt+Gqcy/l3sA13n697B0xogxDb/iXGHNGhNHCZ/9rd pBPgq3GdcS82bcO8MiE/U79HC9Rae2nVYNdDx/tK/0hlfwKpno9710ZtEW6oVkWszS2d RipyDqUk9KENtc5iR4OFqdBHgjNaQo51Htr/DgGBpTZkeKK3YR3+tuALJrIFxa+Gacqr FbAiU4As2sO3ezYvrbAaSdiz48WRuBi7Ti90hZYlw6513aCloYHeOnUjNL/KdwYFr1bE 5Z5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762438563; x=1763043363; 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=i5/qRLvtiYRjdIM9VE1bXFeJJheqHvWFfR+C+pGV8kQ=; b=MgBKYWxlHZWLkYDvnRW7W7ygt4n/GwFdPSmS/4uLCf1RFzgQLrd3GNspwmlW8QS7Ge W1bV4odyr92dQ9Q/h1tLhKLq3hoa4ff4KVfOZ7uBHztxeXGv3GAgLWECWJ/F+bFu/Xwi yVxWcYaN0umxmRifDX5mwWyo/JwHYkzDORV8mZ29wSwjy2b1Qoj4M2egOL758OIi7blQ zbr4uuaS3enH5wjT9bClzoetKFXdrI8rGHjXRC6A1oc5EaYkMSdB+e1HnEvBNLVwx4bt 5wDKtK1lwERe8/0yuK7ZxD34XxHzBcBOzRtJMu2n5hEtTDdhaUb2bpoO6Do5H4TM5+Ix ew0A== X-Forwarded-Encrypted: i=1; AJvYcCUN/bKjMcpPIpcjzmEPQ/hReQ4pTQzctD9Jyqt8iWKzYoQs+za7alFzgiqhHTJf7B6FOxFQ5VDxCTeR2UVuSDk=@freebsd.org X-Gm-Message-State: AOJu0YziIw5CXlU+c3cTaB/lSAXNkBPsGQkVspjTYOIAoTPLBjtcaSfS GxzP0655RlpM392qfcyWpQ6xFJqC3hOKGhSVOQhJMxm4Yg0kYDcNsLMcE55c+aiCvNKOmh/KoZ5 aUBI= X-Gm-Gg: ASbGncvLjNsg29EOoY53IXrvGmrV8itall/KeKB5tgzJXlUtwtaWLYaPpgwRHIIhDum jN1HOBJkmNjWfT9ybPEIwoDSPJ03NFXGURcn41JxWnvpUqy4UCrfQrFEFQ7l1AOMTG73/AmeHbG eOD2hKlxMWo6bKmg75yuYQuieaFfLle4P8hDi5A3zLLpqzSwsfCjlR8LuOM7UY9u1Vz6r5QEmwH 2PBnVp1btksCkATXF4WKy/q4JvbIJaqJLIMXyZow0iIh7MTg46M9jX0aHrHmOTsi7VXfdJj3N5u JTL1owI8nw4I90W5PYBp9q/pD3rE+6qxjprxESGZS5vIXT9//1MX6xaLl8Lh1cJN5ZyfxdTzTJn WDQb16m/8Dnww+mDrqymNFKB9IdPRRJnLg5YYTGipucIbU9duHPwGOZK7LLMKtRt0l78MAdTo1I ztSSdGIhq1x5N+V+a257vRp6eYN2pKzsBCYxcR X-Google-Smtp-Source: AGHT+IFneD3KhpXHaAEMo9CTTMBGfRRFKoTmwRYUdyGwNW6D/00WtpFN+cJAbiqLDYCPdb/VKLievA== X-Received: by 2002:a05:690e:1c4:b0:63f:a103:5d2d with SMTP id 956f58d0204a3-63fd355be1emr4570524d50.37.1762438562539; Thu, 06 Nov 2025 06:16:02 -0800 (PST) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com. [209.85.128.178]) by smtp.gmail.com with ESMTPSA id 00721157ae682-787b1402f76sm8396037b3.21.2025.11.06.06.16.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Nov 2025 06:16:01 -0800 (PST) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-787ab220c57so9842637b3.2 for ; Thu, 06 Nov 2025 06:16:01 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXzGTSeKU8uVVDl6DutFieMPLRz5R6qmjAdiIstgDFvRxfo+eaQaqIRlLhn0g+fM0suyyAJ4u0P7nMYpuliXGs=@freebsd.org X-Received: by 2002:a05:690e:23c4:b0:63f:b3aa:d9e with SMTP id 956f58d0204a3-63fd34c574amr4636545d50.23.1762438560862; Thu, 06 Nov 2025 06:16:00 -0800 (PST) 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: <8B8086D4-C68D-4C8A-86F2-C35212823B94@ketas.si.pri.ee> <73b4a16d-30f3-44b6-8477-aaa8e5aff82a@gmail.com> <20251103181232.3d7c8825415f1d2ad3f08c6e@dec.sakura.ne.jp> <20251104032244.f9fbf3cf8d67897a0ea84ac0@dec.sakura.ne.jp> In-Reply-To: From: Tomek CEDRO Date: Thu, 6 Nov 2025 15:15:49 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bl4C2346jfpPkKnMf5kTH-mVB6I7Hl5ZdF_AnL5ZsekfHqiOxTX7dZbKZU Message-ID: Subject: Re: Why is the DVD image so large? To: Tomoaki AOKI Cc: Sulev-Madis Silber , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b12b:from,209.85.128.178:received]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cedro.info]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4d2PPK5tRTz40tT On Mon, Nov 3, 2025 at 9:57=E2=80=AFPM Tomek CEDRO wrote= : > (..) > Also I just found and ordered to play around: BD-RE XL (100GB > rewritable Sony disk ~17EUR no enclosure) and DVD-RAM (4.7GB Panasonic > disk ~5EUR no enclosure).. lets see if my recorder firmware supports > them and would it be possible to just mount DVD-RAM and read-write as > standard disk but slow :-P Okay just a quick test summary: 1. BD-RE XL 100GB: Not all drives can handle them at all (not even read). Looks like these are called UHD disks and so needs to be the burner. This not only depends on firmware but also hardware optics (even though electronics is the same for different burner models). I have Pioneer BDR-208D that cannot handle them at all, even though it works with BD-RE DL (50GB), XL does not even read. I contacted vendor, they confirmed this disk is and will not be supported because of laser and optics limitations. I found out that "crossflashing" is possible for these burners as unofficial hacky way of flashing one burner firmware to another burner that enables some features like BD-RE XL, but it seems this will be out of spec configuration for the optics anyway. Another burner ASUS BW-16D1HT (fw 3.10) can handle BD-RE XL read/write out of the box. 2. DVD-RAM: Not all drives handle them at all (not even read), even less popular than DVD-RW, hard to find, more expensive, slower, not 8GB. Pioneer BDR-208D does not handle write only read. ASUS BW-16D1HT handles it ~3x write speed. Some older HP DVD burner kind of recognizes disk, writes ~0.1x and always fails with error on formatting, but it may read them. Not sure about this RAM capability yet and how it works on FreeBSD will check in a free moment later. If your drive supports writing to BD-RE XL and DVD-RAM it will also read them, but most drives cannot even read them, so it seems only local backup use cases can be considered, not really portable solution. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu Nov 6 14:45:01 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 4d2Q2w2fvVz6GG7h; Thu, 06 Nov 2025 14:45:12 +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 4d2Q2v4Cdbz44kR; Thu, 06 Nov 2025 14:45:11 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview7.colo2.realworks.nl [10.2.52.37]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4d2Q2k3P7bz1j2; Thu, 6 Nov 2025 15:45:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1762440302; 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=6CAA5KT1mRxHjvgbXe1hANzHDIbPZ/4JMOZY1dZSxpA=; b=Mu3d+jYw7jn/cNtLaOoTrmLVd3krPny8qSUy2E40YuvLekp49IKz75sxDkIuebwNgfCkAu gCX9Um4Nn9EF6Kxg3AkkWOUF3c72cdU7pB8MJ+lkBtCNisnzHyyVSFT76DRihkChRdhhKF a9u3OwIaTllw7Vyi3D1ah5Sc4vLvVXbW/a1q2+VnJbs7skJr/DthqhaJjJpvO/A15scBF0 Z9tX8b6yePjbsDPdPnUVwVumRhBwAcH5AprzN5lkNF6Ovn+xbF2nXuz776dc673VACOSMe 2Rs473BMM0j46RTkcKP3AbF6k1mFqTFKkq+Xcnur9Mv4zOmHJjnQGXqsVB1YaA== Received: from crmpreview7.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview7.colo2.realworks.nl (Postfix) with ESMTP id EF22F18024D; Thu, 6 Nov 2025 15:45:01 +0100 (CET) Date: Thu, 6 Nov 2025 15:45:01 +0100 (CET) From: Ronald Klop To: bob prohaska Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Message-ID: <475995705.6919.1762440301455@localhost> In-Reply-To: References: Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld 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_6918_2102122641.1762440301376" X-Mailer: Realworks (772.17) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview7.colo2.realworks.nl [10.2.52.37] with HTTP; Thu, 06 Nov 2025 15:45:01 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:144.0) Gecko/20100101 Firefox/144.0 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: 4d2Q2v4Cdbz44kR ------=_Part_6918_2102122641.1762440301376 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, To me it sounds like your machine is overwhelmed by swapping. Try -j1 buildworld. Regards, Ronald. Van: bob prohaska Datum: donderdag, 6 november 2025 15:04 Aan: freebsd-arm@freebsd.org CC: freebsd-current@freebsd.org Onderwerp: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld > > For roughly the past year I've been seeing buildworld become unresponsive > compiling -current on a Pi2 (armv7). The stoppages seem random, sometimes > with no visible memory pressure, other times while swapping. The machine > uses a USB mechanican hard drive for root and swap. > > Numerous attemps to use enter-tilda-control-B to get into the debugger > have failed, with absolutely no response. In the most recent case the > disk activity light was flashing rapidly, a relatively uncommon event. > The frozen top window showed ~312 MB swap in use, less than half of > the maximum commonly seen for a -j3 buildworld. > > Looking at the log file after power-cycling it appeared to have last > updated the previous evening, so it seems unlikely it got stuck on > a core dump. Reboot was uneventful, with fsck completing successfully. > Buildworld has been restarted, it'll pick up where it left off. > > The last entries in the buildworld log file were: > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateInstantiateDecl.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateVariadic.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaType.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaWasm.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaX86.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/TypeLocBuilder.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTCommon.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReader.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderDecl.pico > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderStmt.pico > > No warnings or errors of any kind appear on the serial console, ever. > > Is there some other way to get at debugger services in a case like this? > I understand it's possible to run programs under debugger "supervision" > at the time of invocation, but would that provide any extra avenues to > find out what's going wrong? I think not, but I'd like very much to gather > some useful information toward a fix. > > Thanks for reading, > > bob prohaska > > > > > > > > > > > ------=_Part_6918_2102122641.1762440301376 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

To me it sounds like your machine is overwhelmed by swapping.

Try -j1 buildworld.

Regards,
Ronald.

 

Van: bob prohaska <fbsd@www.zefox.net>
Datum: donderdag, 6 november 2025 15:04
Aan: freebsd-arm@freebsd.org
CC: freebsd-current@freebsd.org
Onderwerp: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

For roughly the past year I've been seeing buildworld become unresponsive
compiling -current on a Pi2 (armv7). The stoppages seem random, sometimes
with no visible memory pressure, other times while swapping. The machine
uses a USB mechanican hard drive for root and swap.

Numerous attemps to use enter-tilda-control-B to get into the debugger
have failed, with absolutely no response. In the most recent case the
disk activity light was flashing rapidly, a relatively uncommon event.
The frozen top window showed ~312 MB swap in use, less than half of
the maximum commonly seen for a -j3 buildworld.

Looking at the log file after power-cycling it appeared to have last
updated the previous evening, so it seems unlikely it got stuck on
a core dump. Reboot was uneventful, with fsck completing successfully.
Buildworld has been restarted, it'll pick up where it left off.

The last entries in the buildworld log file were:
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateInstantiateDecl.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateVariadic.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaType.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaWasm.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaX86.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/TypeLocBuilder.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTCommon.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReader.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderDecl.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderStmt.pico

No warnings or errors of any kind appear on the serial console, ever.

Is there some other way to get at debugger services in a case like this?
I understand it's possible to run programs under debugger "supervision"
at the time of invocation, but would that provide any extra avenues to
find out what's going wrong? I think not, but I'd like very much to gather
some useful information toward a fix.

Thanks for reading,

bob prohaska






 
 

  ------=_Part_6918_2102122641.1762440301376-- From nobody Thu Nov 6 16:38: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 4d2SXV403zz655tJ; Thu, 06 Nov 2025 16:37:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d2SXV114jz3CFv; Thu, 06 Nov 2025 16:37:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5A6GcSZ2002186 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 6 Nov 2025 08:38:28 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5A6GcSQQ002185; Thu, 6 Nov 2025 08:38:28 -0800 (PST) (envelope-from fbsd) Date: Thu, 6 Nov 2025 08:38:28 -0800 From: bob prohaska To: Ronald Klop Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: References: <475995705.6919.1762440301455@localhost> 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: <475995705.6919.1762440301455@localhost> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d2SXV114jz3CFv On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: > Hi, > > To me it sounds like your machine is overwhelmed by swapping. > > Try -j1 buildworld. In most cases of stoppage the swap use is low, 50 MB or sometimes less. Up to about 6-700MB the machines slow their progress, but keep going and there are no complaints on the console about swap taking too long or insufficient. If there's a connection to swap use, it isn't obvious. It seems to be related more to hours of runtime than swap use. More to the point of my question, if the machine is swap-bound, shouldn't the debugger escape still work? Thanks for writing, bob prohaska From nobody Thu Nov 6 18:00: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 4d2VNV5mxWz65DW9 for ; Thu, 06 Nov 2025 18:00:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4d2VNV4cFBz3bDK for ; Thu, 06 Nov 2025 18:00:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762452036; bh=EbkyDgVmKgDCoPLIHvDdsGOI1Ksy1frMwxImvieyd6A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rg3PkkZpl0xRsQDuYvNGXCNhikVwmwdoMgk87E+y2+CBFf/LnWe/Bh8Bf0/T6HUCcduXgnVKsLMpUAoJlZZ6JKGVJibeORiNS2AyaJ77E3R5PtmnsaZHiFt5ASzyynK80rT1jkY+tGR1VznTb8hc5xc6BkZHegvgewx/Ji6g1cMx5poeLCRdn6iYHTpSdeVGO24hUygWuLEwaccXQF/Eo9iNpaOx4bPkbftdVzRvtUem7QxoWMa1M4z+iH/29N2H7TIVs2wjDGIbZjo6b4wTwRx8K4DuyCUSql6f96ICSftN48JlNkJtnZ6aenuR9fMzcI+aNxmS0oYqLGQ9BRCa7g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762452036; bh=UKzB6kUBq45Mn2G5wgoSDh/IiA4UqXAsixhC/jGnfEg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VOgML2Miy/+sG+PS+shjFqp77k5pK3LJuL8Un1QX385370Hyaa5j4JQmlN5udjdN74Z+ds6rqByLUAW8pwBL5fUbmMaLgv27Pc5yu4MlioJ74MukAS5KjfEnRs84iMvdHO+0LuZkt/baFg2M2wfCwcIZVj42s5UaN0wq5fxTVTVr3CIKYKLj3wLcd5uEi3INiirYly0H3znPTTTT1iytoc0esINlKzRpWsN0U1lPS5JRBk7IrFT8nwYsn1RDSybGHnO9N6j35DNmggW2dzktWhj/jrf58JdHzLDd64D4JPUQADs37MwtQIjCGRU7RGyvX+F/0FAM8QMFJq1/5+r3fQ== X-YMail-OSG: N3kqNxMVM1kwG9Bkpl42J_1LiDIA8wTh2BKxLBdqvHu_EmSD6j8bJrRmeNisM7i 6YP_0oLuMfH_7zGf_fIaoddu4O7Iww2mqsXKkFbq_FKofiYcRLFcgDQlV3PBJnVGROCLHfJ60bjj 9uSLpgLsZ0Obs6WPrSVpNLNkiFl0mi53izybfSl6RYmm6Ck1C8yjGrPm_yPNFAZvfnQh1ypPuKkP xdVfyCWtGQTHjYfzdQZoNDTNFf0my58GK3BjD3rnF19HSu5E9PR.sfzc_KBYknMs7ImfjnZe8RMC MLjgXgOqUPCr1qFNLefqb6IgvExw4HtCQdc6d2aD5nRFDsPGSbFnZTDaRt1.6kKYINiLXPFT02T5 PT6_VLpMdlmwIwjK_OqfTAa1zPpamG1D7rHCzPPBoqXVlaRuZXW7k3fcgTIsbSesWHZrACfWowPY NAlAPaOqGwMNnXwB7xXi37_AxE_KAFPSeHDjCwAxRqQZ5bU72341MxvDZc90LVdaigZexyvDMCkI VM0hROxKybormWRpGf61.qHys3hFegqVzif8IHL26OTRbPSeMcrXUDRx8MTsifZQAm_cilixoq8p Ue.KXkq2XtT1Ldy53kQn4A8omeon4E4KP2ANvv074dfLm.dgH42a4tUJY7D4ZWkKz_FNIQCwfTes 42pkrmAptKv9vqWIOZjkO4qbwV8FK.WQiU4E4afFggUFSd5H0kwFUYzMqv3A3zt.SiAVSRjz.DBB WZ0gpXnKPyjMWSzothtwHeUnKS2pTlybAWg5KawjGNghMdDiUMe07Xyakbn_opknoM3qXdo5Mhvy Ol._6CxfsSgUitq52UpQB2Fks3FY17eszyVXrd5aDLSxgYqM7U5iCU43R.hnKsdyruveOoeXcF4u 42YSUuJeKyj02DAMM02s5h02EFL7T56iqZX0hk2r3eK8NZ1lO1FP7QtG2DJuF3mKLn2106SKeNLW kp8N9KqSrQZObL0lF7qyrGIKh0wTDbEt2MZpl1sR5DmoRN3eeqcveeKuTnN2lXNhq9T3zNlnBqzu BRqM0diZNWSlkGGOYfXal4xh21W3AlA1SIwtgL2YsUNmwvZse8uK0r4w00dWtx98q3Dt5E4JxBVY LYnlENzWw8cmy1tZk_xzlS7wRau_hbFTBP9YksSJ4nrkacnI662fjE2mhcvESIsaTgDZITT6s3ht 6Pd4G82RLzN659LUVwV.w4JQbBVvtPhTf6mWbwRdWMD0CLySTxKbb9.M2Y58EUDgrPVWNT23nFYH SmGnA6IY4wt9uuabCSypGu55uaUSdGNuYrP7Zj7qBlSzB1MTN7oL1UgdpOqbLtlf8JtWCHH_zj61 T22uVIOjvGLDyWa3DGqA7ywbz6zTTmhPXlBdT4VyDYBc9YPxUpM4gxM0RwHMKbaxzYAC9f.5C2q2 0ILdTy4qvBDeY.kuK7f4dNZzMZCFgICZlN8p3rYGOPxIrF_0oWJ.7GnGD30pbHAn0tv5sPjeXcIp _xkeDz01tG1ypjVsndI1GDU5hpwthp_nH6pQepkT763R24eo6H0jTR37a_b7e8lEjD6lxYcOVE.n msO4apYAUDlqcMYHOH1Iaj5GyrO_0FFOtiz_9i32f4.B06P3vHPoH..pXHvKLJW_u3B7.7mwLhfW 2vLujrwMXE064eCBYaVcszK2kPX8QXc8p115joHYn1PEXo1oJCEJclOsGKdP1ZsI8hz0BrsRruww InHmb6HCm1EEJW2GUT8fhSjISah23Q96MVq8PV00uIp2H4ju9Y.CxrEHJ3qzmi6gYaKda_YqNIl8 YAWI1_MEppheSeWd8pUzEtVdz9kW0keoxFgmBJtG84o_VOAOHBq5yBNaralQItjV2p5jzz74Kinr TacEWv_r_EbjemJTIYRDHwFN2OITDHXxpnqOryHeDR5poInyhpCytBN9GSax2D7vcqbBlST9dfXp AALBaQeP8eo1Bdfed3U74iBV3jub.qzBb.45kRbYotHXeyC3D87HX_A9wsNoOcx29qM5PsCEabWL mUa8Y8._5CfR5ejvuB_AX7tyqWrVg8WY2Oo_f5VwrMgUMe4mbOe8oSyBTyhELEIEKcZiG1ijIgg_ PNVh0qLY16jgA1BqTW0mqADoAF5WoAFnkWCWQvpxzmcAa5hlUqBozetaXtRjxz57GG5sdQ6oRXA1 C_SznuJ25g1O8HKn_QPU79M2pekrZUMjmKcYb1mKkJIvwg9E.JD4T9HCrWRtEJgdHY0QRFa2f..p VvQ9XnXlcPSTWpOuh3rilq.q5Rd7PSGSKD6rQ0Do2DVxwaElACEEn23npXn9Rmc1gfe.Da49cnJZ sI_riHA-- X-Sonic-MF: X-Sonic-ID: daa68a2e-b29c-4424-97c8-2e338f1febdc Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Nov 2025 18:00:36 +0000 Received: by hermes--production-gq1-86c5846576-ngzfg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b0b32acb5119c0440b86697074cafc62; Thu, 06 Nov 2025 18:00:30 +0000 (UTC) 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: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Mark Millard In-Reply-To: Date: Thu, 6 Nov 2025 10:00:19 -0800 Cc: Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> References: <475995705.6919.1762440301455@localhost> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d2VNV4cFBz3bDK On Nov 6, 2025, at 08:38, bob prohaska wrote: > On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: >> Hi, >> >> To me it sounds like your machine is overwhelmed by swapping. >> >> Try -j1 buildworld. > > In most cases of stoppage the swap use is low, 50 MB or sometimes less. > Up to about 6-700MB the machines slow their progress, but keep going and > there are no complaints on the console about swap taking too long or > insufficient. If there's a connection to swap use, it isn't obvious. > > It seems to be related more to hours of runtime than swap use. > > More to the point of my question, if the machine is swap-bound, > shouldn't the debugger escape still work? Are your descriptions of the lack of gaining control for use of the serial console? Do you also have ssh or such? Do all such see hangs as hung-up/crashed? Do you get notices about loss of network connections to the RPi2 v1.1 in question? Do any of those happen automatically? If so, the time of such a message could put a bound on when the RPi2 v1.1 hang-up/deadlocked/crashed, the message about failing communication having occurred after the problem starts on the RPi2 v1.1. I'll note that your prior reporting of the end-of-log content gives evidence of things that completed, including being flushed to the disk. But there likely was more that was not flushed to the disk, some of which may have otherwise completed. Also, what was actually active at the time of the potential deadlock (or other form of crash) is unlikely to show in the logs with such a known status. The I/O tries to keep the file system media content from being corrupted, but not necessarily that it is up to date. (Fully attempting both leads to either a contradiction or horrible performance. UFS has different tradeoffs than ZFS for such issues but the same general goal applies to both. At least that is how I'd summarize it.) Knowing where the logs stop can give some idea what might follow or have been active, but it involves other analysis. I do not know if tail -f reports buffered information vs. only data that makes it to media. It might be that tail -f in an ssh session on the/a log file might report closer to the failure time, showing information that does not make it to the media. That need not be the same as showing the actual failure time: just possibly closer. As for debugger use, there are thousands of processes. If you mean gdb or lldb, there is no uniquely relevant process to attach to and monitor that survives across all the activity. Are your kernel builds debug/invariants/witness builds? Is world a debug build? (I do not mean just having symbols and such as a debug build.) I wonder what the behavior would be for avoiding the resource overhead involved in having and using the debug code. (But, if it does fail, extracting information is normally a problem.) === Mark Millard marklmi at yahoo.com From nobody Thu Nov 6 23:25:26 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 4d2dbZ4YdCz6Ftx9 for ; Thu, 06 Nov 2025 23:25:46 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 4d2dbX3xsRz3pPF for ; Thu, 06 Nov 2025 23:25:44 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=F0pTxaWW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::534 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-b9a6ff216faso131956a12.3 for ; Thu, 06 Nov 2025 15:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762471538; x=1763076338; darn=freebsd.org; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0Hs7eRxEAGj3qC6OAmGSeFrAkFHF2XDNBqLRGDfaUzY=; b=F0pTxaWWHghA+gwBzhlc5ECWQqEPjHgCd8M5FReB4Tuz98JvZYNsYa1DnkmL7pyXiK dBcHq3YAOTulJNt5IvCc9FtC2iC9Ha+1SNdBYvZdnOJOC0g3wTEs9/A48IJt893M84bz 2++rHfBF9xxpmWNQlARFhDO/21ODyBbjHzmy+LXnhNFz9rkHD9LTIuwSHorNOsUKEdMY oFEWS6a9QkFeQymgg12Ncf+H76fxF0fTAFbetqb/13dxSpNdrLnt6lp7dgQeAo0o65E2 bWoN5kFdueN/DFNOqEXqcsuLQ1NZlhu0HmCF4mRXfM9r8rluBfjl0XMYafL0f6q77W/M CMkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762471538; x=1763076338; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0Hs7eRxEAGj3qC6OAmGSeFrAkFHF2XDNBqLRGDfaUzY=; b=K37We/5fy1HnrKjlELOCh1Cjm4aPY4FqLpFllPo3LWLMOd1Awl8BqRAwli2POTlzlz Lcc6IK/uIEZFA0pOWyfDS0Eo1cUzLY+m9Exs5ClbKpepSYroQCTsH0YGEus2L8vfoJlK xhDH8DuhxUzSvVhrE0As+VpsF9B/yrIuCU9QZ8eExfm+y+t47uXAbEpj9ylG1hNnYekK lDJouvGC2PyWyKzLl3tsCUU4gSq4WB9b98sxxzA/fG5QDkzLkFOz4lG4KJW0Qalft1FU dvAS4cb4n0hWncLWMEQxwMJAW0RolP80Pr5UGEoooSDtVjGiQIvE2ig2mz0TIrJXDaWg OfaA== X-Forwarded-Encrypted: i=1; AJvYcCXplvjfB+o/85RIDUsiqc3kUABkyazHM2O80HDcKJVlYdkq2zlPfiAnx+5NhNHKaCkP2jiojD2eFBaU+jC0pd8=@freebsd.org X-Gm-Message-State: AOJu0Yz1VoT70fcSW+6VZj/vY25j17AYMCsjz1bCh4TbBt8nHkkmT3fh ubrh2MJ3QDjI87Alx5SazTU72NhNXWVSSpnC3yM0stElcP7o2bzLdsho X-Gm-Gg: ASbGnct1m8vZRTGlLBu1GM0z+2G2wx3AoZupjcgd876Mp/qjOM2XuqT1Tmndo7v5Hy1 IMnSkCp3TfOazALqfgvi+qyFFtSBLUpwODjWvc1qOHbxDVM/7BAvFUCYAY0ZTMOrx1MuIyXle5t GfgICqlel12vIVHpN3dHbkgi7nvP3diieqqOo3DaC7FNC5nGFViIv0dXdXtOJoJqzCfmndOkyVN osEAe+6m8L1OVGN48GILXejiBpFxt3RRbWr+LNyxn9bQe5uapep5PYZDYDUs/aPoLu+ayQ1elCV TxRLYPsfxtMwZxk+92kx5pFN9fZzsqMjfA6xfA+4IRi1GlPkKWq+nTW6fE2SSGXWqfepFXEM0rt hAjG/jsaggjGeLwWa1LCJwSkV/9Tj+c7ieQHR0i9NCVr4rPwauqq02xHpg3q76jDgUeM3F/sN2p 9m5kx3XZ59YC/RotS1C1tt/EU= X-Google-Smtp-Source: AGHT+IEyYx5TKCz/QugZHC87bL9dBsMdUAMWJBde7yVRxAaWjus42Nv9XyrxjuBFUSIFHVm9SrzG+A== X-Received: by 2002:a17:903:1a2e:b0:295:810d:df46 with SMTP id d9443c01a7336-297c038986fmr16188355ad.3.1762471538136; Thu, 06 Nov 2025 15:25:38 -0800 (PST) Received: from smtpclient.apple ([194.113.66.247]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29651c92cddsm40620735ad.83.2025.11.06.15.25.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2025 15:25:37 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DCD767AB-8118-43AE-B4C6-B46499615A7A"; protocol="application/pgp-signature"; micalg=pgp-sha256 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: Mistakenly started two buildworld instances... From: "Enji Cooper (yaneurabeya)" In-Reply-To: Date: Thu, 6 Nov 2025 15:25:26 -0800 Cc: bob prohaska , FreeBSD Current Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.09 / 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]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ATTACHMENT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; 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)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::534:from] X-Rspamd-Queue-Id: 4d2dbX3xsRz3pPF --Apple-Mail=_DCD767AB-8118-43AE-B4C6-B46499615A7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 27, 2025, at 4:09=E2=80=AFPM, Warner Losh = wrote: >=20 > On Mon, Oct 27, 2025, 4:48=E2=80=AFPM bob prohaska = wrote: > I absent-mindedly started two instances of buildworld in the > same /usr/src directory. By the time I noticed they'd been > running for at least an hour, with no errors and no smoke. >=20 > Should any actions beyond running a single instance of > buildworld in the aftermath be needed to clean up any > problems this might have introduced? >=20 > I'd be tempted to kill both now and start over bur with NO_CLEAN or = metamode. I=E2=80=99d personally start from scratch. Who knows how many = demons are in the build process as far as non-atomic operations are = concerned (there are a lot of non-atomic targets in the tree). It takes me less time to wait for buildworld than it does to = debug some random issues caused by concurrent builds. Cheers, -Enji= --Apple-Mail=_DCD767AB-8118-43AE-B4C6-B46499615A7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkHfexGRJ3gYRdA2gGpE5DjPsNJgFAmkNLmYACgkQGpE5DjPs NJgblg/+KJrGtC9hE4k3aqLvekYFEC00imSmGF+5gDbFf4NqpciXKg8LrMgVfXmL 82ZrGm+G8EvqGiJ5/vO9/wGt+PyRl13oQrkV6ZNjTx0xTK7AvUAv3a6NVolAPx8v pEM4uRBIrFkI0JESarLRBAHj6uEgK1HPmjsPenP2D9qYPkFUkswRPkIaXNjn8HU4 xZSUuRcQbxj6gN7hWhb3PFunZ7k/ND15T6cP6kIIfJ98cGgfqgKJzWPjJF4RpdiK /E+HGg/8KgeNn3wAUkk1jwSVVtj06/9YD7i7DBLfMsD5/WG9/QT8sedDf9qxzCXD 1Nq52wm/fJgcqubBgbAtgYY4qUE6d3rHc5ggL7UEe2Zv8NnbSooRFbRa8Wb86Y+T 0kqxu8E2SmzRIx6NdhtfaxQT8RgQ0WD2marq/egMzCIMIbtH+Kq9fVNl9+f9acol Kp4VGd/fQyySvbkVjYZ+1P6wO+6/fQRNYuiCW1FEM0OdhiXM5u0u6pNIlQVYr8ui 1jsbStIs/y3A8ygBD3KU6aSSQZDY2kSaU853jUsqKk5c5t+1wDn9YwX+G/l6hFyX qvTui54h6+H+Z4aWUMDpb7lh4R3APzkcprOn98z1/k5peuQ6YnNTEvXEMlLuCPbX RJzfhqPLOZ1rgu5MLrG0DSLIHSfEMCXp/2N33Qjx1OftIq7eg/k= =5PQ+ -----END PGP SIGNATURE----- --Apple-Mail=_DCD767AB-8118-43AE-B4C6-B46499615A7A-- From nobody Fri Nov 7 02:22:37 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 4d2jVW6dYcz6G8yq; Fri, 07 Nov 2025 02:21:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d2jVW3KJqz46XD; Fri, 07 Nov 2025 02:21:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5A72MbjR003416 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 6 Nov 2025 18:22:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5A72MbCe003415; Thu, 6 Nov 2025 18:22:37 -0800 (PST) (envelope-from fbsd) Date: Thu, 6 Nov 2025 18:22:37 -0800 From: bob prohaska To: Mark Millard Cc: Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.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: <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d2jVW3KJqz46XD On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: > On Nov 6, 2025, at 08:38, bob prohaska wrote: > > > On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: > >> Hi, > >> > >> To me it sounds like your machine is overwhelmed by swapping. > >> > >> Try -j1 buildworld. Maybe a -j1 buildworld could be at least somewhat informative. Lately none of my Pi2's has made it through buildworld without hanging silently. If -j1 buildworld completes, that would be a significant change. The test will take a week, but the problem has been going on for a year. > > > > In most cases of stoppage the swap use is low, 50 MB or sometimes less. > > Up to about 6-700MB the machines slow their progress, but keep going and > > there are no complaints on the console about swap taking too long or > > insufficient. If there's a connection to swap use, it isn't obvious. > > > > It seems to be related more to hours of runtime than swap use. > > > > More to the point of my question, if the machine is swap-bound, > > shouldn't the debugger escape still work? > > > Are your descriptions of the lack of gaining control for use > of the serial console? Do you also have ssh or such? Do all > such see hangs as hung-up/crashed? All comms become unresponsive, serial console or ssh. > Do you get notices about > loss of network connections to the RPi2 v1.1 in question? Sometimes, but not always. Occasionally an ssh session will become unresponsive and only later report a disconnection. > Do any of those happen automatically? If so, the time > of such a message could put a bound on when the RPi2 v1.1 > hang-up/deadlocked/crashed, the message about failing > communication having occurred after the problem starts on > the RPi2 v1.1. In some cases the stuck ssh sessions are disconnected only after reboot completes. In others, it appears to be a matter of time. Overnight is usually sufficient. > I'll note that your prior reporting of the end-of-log > content gives evidence of things that completed, including > being flushed to the disk. But there likely was more that > was not flushed to the disk, some of which may have > otherwise completed. Also, what was actually active at the > time of the potential deadlock (or other form of crash) is > unlikely to show in the logs with such a known status. > In a lot of cases there's been a top session with a timestamp and swap usage running at the time of the crash. I've not made careful comparisions. That's the only timestamping at hand. > The I/O tries to keep the file system media content from being > corrupted, but not necessarily that it is up to date. (Fully > attempting both leads to either a contradiction or horrible > performance. UFS has different tradeoffs than ZFS for such > issues but the same general goal applies to both. At least > that is how I'd summarize it.) > > Knowing where the logs stop can give some idea what might > follow or have been active, but it involves other analysis. > > I do not know if tail -f reports buffered information vs. > only data that makes it to media. It might be that tail -f > in an ssh session on the/a log file might report closer > to the failure time, showing information that does not > make it to the media. That need not be the same as showing > the actual failure time: just possibly closer. > > > As for debugger use, there are thousands of processes. > If you mean gdb or lldb, there is no uniquely relevant > process to attach to and monitor that survives across all > the activity. Would running the buildworld command under a debugger's control give any better access to the enter-tilda-control-B sequence on the serial console? Usually buildworld runs from an ssh session in the background with top display over it. I could run buildworld under the debugger from the serial console if it makes any difference. > > Are your kernel builds debug/invariants/witness builds? > Is world a debug build? (I do not mean just having symbols > and such as a debug build.) I wonder what the behavior would > be for avoiding the resource overhead involved in having and > using the debug code. (But, if it does fail, extracting > information is normally a problem.) Sources are all unmodified, so it's whatever -current offers. I'd expect that to include all three; there's explicit warning that the witness option is enabled. Thanks for writing! bob prohaska From nobody Fri Nov 7 04:15:49 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 4d2m2d20hTz6GKhd for ; Fri, 07 Nov 2025 04:16:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4d2m2c63C0z3KV0 for ; Fri, 07 Nov 2025 04:16:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762488962; bh=Wn4Q8VzepRBxVtUpQuu6lxI0+k5BBGkNfS14Z178FfA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Vm3HANt3gFNkahWjJA2UJ8ztzwifkl62CwS6OJgXJpD3nu3+K2Ox6fnD69paLGO1MLtrASjCYFmTIfDVvL/sNk337wUCFznheRQLkLyHnk4dSyt0JdZw/QjJXVjFMZmQ84Ihvzm6HDZTB2a8dyKVeteOeu/vZlNP3+2UtPXO7obD2HXbcEhMrZ4XYqaddiL6hqXnG5hvulhnEsMFPe/KaqhuzJl6cjl49wRWfJZqE9AagDAxi8rniPAZ72+uqtP5D96F+6lPso6+Ul4ISo6Fq2suv0mA4MnRmj4nIaXBr+xM4taw9s4aYj4QiZdg7aSYJh9p0FQfAqa8uGGtHbpwAQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762488962; bh=x+HdkL9mkDO8bTRnzsLLbPYYHrklTUEKOPJZEorH4dB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EDga9UZ+4olu21OMFxntE5dkKIpkGVO83QmhhMCpahFkXDK7y1Zd5bUGfmKsaDLUww+fT7FjoB9jhsGBF0Db+IfsXVWU0Yhh++R3sPdBIpWbbebjs1I5iJNFaa43OK02iKP5+wDYWLGxzYF+6ilLnkCt/kOtxbp6DBa8tj3Bu9+Ssg9FrCE1y/Cb8VbxpBTPHHUSr5aQMWWz32FFu+eCYIC2bTdFHkOnSZpFGfgQAJx+TL4No04W5tiiy9OPzLJ//++0kCEqi9mr5vRUlMEjQjCcPuRRj63RegcE+kYQ43c0xBk/mPcOJkIFT3J56Os7eyTNkAkzss46Z4n0kuyP8A== X-YMail-OSG: xmKlmrMVM1kv520QtDz5KDMOvw6JSB4H044RUkVYJ_uFn6FGzWo71YUmareQajc ANupoqku2rg5yQgZPIVfbBVZ5iu7FWQyxpp2yKxOwJNbNlaIhlilcaONW1zR4pCjRziMTbhkKnU9 Myu7TZsf4AKvTAba1524YCsuk8TY2lms1Zn9LIDa_xXb96lSB2gv4W7HYeGgIlT34QyyAYcsMGS. _Hc22IciofggUe_GOrM8qpWrAhPm1kJObqWET7NT_YvbcdZk5Vd2ypaDJsgVleCrls7q5E0pRQlR xTjnd.5jJe.HjcNdBc1NoiDZVdHZlkqzMBIPUjA1qXcJAvuGXxUjXu1TC7VN6H5K1dkpmivzR6UE 3cmgBu7x_XmCXc1zoAiBL6UHhXdA8D0LAzAXoZof1Et9SY43zZu0ZmQ_FC1gE_.QM21FYAMbI6bV Nq8aJYP6ktQizd.y_rACS_9.EZmDqLEdvvcCbo_U6861BA.c44bt3oFPUThMD123tdB7eBYa7Kah _hN3Gqk8f5EQD8VABTdYVBWx.184ioqYHo5iTtmXdCLXuGV3BcYdNbH_WrfoukhLOwX5UAWGYSQC sTiGvhyQd7mr1Ke87MJhe95TFRrkDtmzgkVLo8_d5hw8.2gRafP6Czk56MfJ12Eu1mssuOv85QKd fbuQspl1pINubx1ZEpS1xFgL48j4I21gl431TNcY6_yKMc5C9iQIZVqnNkkYTSVEGSYqYbHtsQHn WwQuUz59DQJu6TTYWdnhghMtAaopyQsbtC6hCrQ9vXYf4p59yAIZ7e.N9IrgK3oSXYqpFTpjVT_N wv1mZzlE2UT_k7u2qF35jLsA4xmWf.Xm0ya7EAW_nAT5sp0TCUyO3WR9WcXUq_L3f9PIkbhRZDZe _g6fWclWMvIYxNW72NykQ_AOgjpNily8VjjZtMcaRUwme3rxwEp63fVmriOprpRO46UaPE3Jlhda RnG9DidC7diOJry6C0S5NcrWQwX7p318gnCzMdGd6Kz0tzCHn_waOTOjxyDVYI1ts8678NL0Ce7d zJ.ABndRnBDP5okU0_De.PMWjn5bZrB1OfEBKZeqmtNFVat6C1H4WuyAGFoe0UE6kv5JhRrVnypq 9WizKKkOsuesNnVMge0tOh0Ltez.r2yNGzY2PdywlBXLxMw7LXJEEFmrlZomkSwqeI6E8S2J_LvE CvgAedAb0NNJufURrcOgDZXBNrtj4WSd_YJm4DfQtAZyE4KMcvhW5W1cvIx9WFw_Npmg9aXwhQfg RrOdhNR6EHz9196.9hS5WCZy_N0qdwCO6ny._qV9MgfWq6NHceFoQZnPtvRBc9iryQH.YB0CLMC8 of3HjfiqJlwVrBSUF0JrCqAPy.mJczOb22ev9Gt_8bZ17Aze.RiZ7P9izUIu5YeMgHAWHhfRc6jA GbwvRWBE4.b2Kc2li661i6SEYp6H62SJ8xnTAXabNjczxb2AiGsR_BA8I0LfeaQG.CwsUDko3Q3N pMSXK6_BrhqIRTsCrWOLQeR6CFgQXjiZzyBoKqnJ7lXEPw787N3Rbe709flBQXDg.G_QA3GBXLrz kQqJ2qPTAJWFp1u3a.UPwEp7iDozBqRmBjnJAO8T3fOtj.ZNFx.t7CJ7KWNzwUw.cDvYFX1doBuX hg65Nd1PdMbcG1T021l.f8cTkfbgX3enhaL2AzXI29NwwC5W4zoG49KLrQpKbK2OGIzGmY2Qw.yY w0.ahmNZZCgSsIA1X37gvUljY3K9RgVZjyTXBC6sP_Ud257NoJ7wT.N8qBDGSMFhKhW61qtLMZz4 IkoadSAFxOObIbiPnOvidQL5qNA4kJLmCMi4LzADApgY1lb_Y4gbrCoD2oJHhYraPnV8PfMgj5qh am7U_ssL6OUusKXOd04SESEif9iih6o5IIhTR1fgG6Zt_YLKxDj3w8elYTb1nq_OJccB1HmlWLbN DXqbJDe4hw3NcVk0gtPNDC_8UtDA1nto7siSHU.r6GQZGY.CupV5NV42APcr9.UUtkfpOArrFGxN iEAhdvWUEsiZ32tSrPt_7cXes4QzYrmrrmjIQDyt4uNrbHlHYf7SwBb6_SPrwvPSx7tjiMUd1gR5 xMxWr8YjPj._QFLi9dII4AKUP1NnTdBqrY_Wrke_ziRNV6vpur_Rw9uUt7.Fkpm7a83qEK5v7Vt6 W3A65Mh_WnwVD1ujwIuFc67Fo_PhnhWcsW5kYVs_OelxO16tDvxXtE3ca6HUEifVRtElpmqS9pB2 ZLOCD8SJmOiTn57yy.XtFXdX5AX9xnfp57QnlCL8zbnSMnUSdQE2Sbp6b.xJPIOm4x0xWUiK.OMl XgTeIThYRTg-- X-Sonic-MF: X-Sonic-ID: 14b3a0dd-74f1-439a-8425-bbfddfee899a Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Nov 2025 04:16:02 +0000 Received: by hermes--production-gq1-86c5846576-4bc8b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1c300fcd9bf83b07cf887c93ff2e2f7f; Fri, 07 Nov 2025 04:15:59 +0000 (UTC) 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: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Mark Millard In-Reply-To: Date: Thu, 6 Nov 2025 20:15:49 -0800 Cc: Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <83E924D9-79EA-4116-86EC-3B861BB4873F@yahoo.com> References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d2m2c63C0z3KV0 On Nov 6, 2025, at 18:22, bob prohaska wrote: > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: >> On Nov 6, 2025, at 08:38, bob prohaska wrote: >> >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: >>>> Hi, >>>> >>>> To me it sounds like your machine is overwhelmed by swapping. >>>> >>>> Try -j1 buildworld. > Maybe a -j1 buildworld could be at least somewhat informative. > Lately none of my Pi2's has made it through buildworld > without hanging silently. If -j1 buildworld completes, > that would be a significant change. The test will take a > week, but the problem has been going on for a year. > >>> >>> In most cases of stoppage the swap use is low, 50 MB or sometimes less. >>> Up to about 6-700MB the machines slow their progress, but keep going and >>> there are no complaints on the console about swap taking too long or >>> insufficient. If there's a connection to swap use, it isn't obvious. >>> >>> It seems to be related more to hours of runtime than swap use. >>> >>> More to the point of my question, if the machine is swap-bound, >>> shouldn't the debugger escape still work? >> >> >> Are your descriptions of the lack of gaining control for use >> of the serial console? Do you also have ssh or such? Do all >> such see hangs as hung-up/crashed? > All comms become unresponsive, serial console or ssh. > >> Do you get notices about >> loss of network connections to the RPi2 v1.1 in question? > Sometimes, but not always. Occasionally an ssh session will > become unresponsive and only later report a disconnection. > >> Do any of those happen automatically? If so, the time >> of such a message could put a bound on when the RPi2 v1.1 >> hang-up/deadlocked/crashed, the message about failing >> communication having occurred after the problem starts on >> the RPi2 v1.1. > In some cases the stuck ssh sessions are disconnected only > after reboot completes. In others, it appears to be a matter > of time. Overnight is usually sufficient. > >> I'll note that your prior reporting of the end-of-log >> content gives evidence of things that completed, including >> being flushed to the disk. But there likely was more that >> was not flushed to the disk, some of which may have >> otherwise completed. Also, what was actually active at the >> time of the potential deadlock (or other form of crash) is >> unlikely to show in the logs with such a known status. >> > In a lot of cases there's been a top session with a timestamp > and swap usage running at the time of the crash. I've not > made careful comparisions. That's the only timestamping at hand. > >> The I/O tries to keep the file system media content from being >> corrupted, but not necessarily that it is up to date. (Fully >> attempting both leads to either a contradiction or horrible >> performance. UFS has different tradeoffs than ZFS for such >> issues but the same general goal applies to both. At least >> that is how I'd summarize it.) >> >> Knowing where the logs stop can give some idea what might >> follow or have been active, but it involves other analysis. >> >> I do not know if tail -f reports buffered information vs. >> only data that makes it to media. It might be that tail -f >> in an ssh session on the/a log file might report closer >> to the failure time, showing information that does not >> make it to the media. That need not be the same as showing >> the actual failure time: just possibly closer. >> >> >> As for debugger use, there are thousands of processes. >> If you mean gdb or lldb, there is no uniquely relevant >> process to attach to and monitor that survives across all >> the activity. > > Would running the buildworld command under a debugger's control > give any better access to the enter-tilda-control-B sequence on > the serial console? Usually buildworld runs from an ssh session > in the background with top display over it. The enter-tilda-control-B sequence is via the tty driver and kernel. It is not tied to a specific process. > I could run buildworld > under the debugger from the serial console if it makes any difference. > >> >> Are your kernel builds debug/invariants/witness builds? >> Is world a debug build? (I do not mean just having symbols >> and such as a debug build.) I wonder what the behavior would >> be for avoiding the resource overhead involved in having and >> using the debug code. (But, if it does fail, extracting >> information is normally a problem.) > > Sources are all unmodified, so it's whatever -current offers. > I'd expect that to include all three; there's explicit warning > that the witness option is enabled. === Mark Millard marklmi at yahoo.com From nobody Fri Nov 7 15:42:24 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 4d33Gr36K1z6G5pl; Fri, 07 Nov 2025 15:42:44 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2607:b400:a:8a80:2:5000:5555:5555]) (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 4d33Gr03Fkz3Tm5; Fri, 07 Nov 2025 15:42:43 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2601:5cf:407f:8a51::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 8CDE960E06; Fri, 07 Nov 2025 10:42:35 -0500 (EST) 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 \(3864.200.81.1.6\)) Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Paul Mather In-Reply-To: Date: Fri, 7 Nov 2025 10:42:24 -0500 Cc: Mark Millard , Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3864.200.81.1.6) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2607:b400::/40, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d33Gr03Fkz3Tm5 On Nov 6, 2025, at 9:22=E2=80=AFpm, bob prohaska = wrote: > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: >> On Nov 6, 2025, at 08:38, bob prohaska wrote: >>=20 >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: >>>> Hi, >>>>=20 >>>> To me it sounds like your machine is overwhelmed by swapping. >>>>=20 >>>> Try -j1 buildworld. > Maybe a -j1 buildworld could be at least somewhat informative. > Lately none of my Pi2's has made it through buildworld=20 > without hanging silently. If -j1 buildworld completes, > that would be a significant change. The test will take a > week, but the problem has been going on for a year. This isn't related directly to building on the RPi2, but just a general = comment that on a system with 1 GB RAM like the RPi2, building with -j3 = (or anything more than -j1) is probably wishful thinking at this point = given it seems the RAM requirements of LLVM right now seem to be = creeping ever upwards. LLVM 19.1.7 seems slower and more memory-hungry than ever before. Maybe = it's LTO? I don't know. My current bugbear is the databases/mongodb70 = port which will no longer build for me on the 16 GB RAM FreeBSD/amd64 = 14-STABLE system I use to build ports locally via Poudriere. It will = grind away for hours and ultimately fail due to the compiler being out = of memory at some point. I found a Bugzilla report by someone who = attested it required 24 GB RAM to build, and it will only successfully = build now for me if I add an extra 30 GB swap or so on that build = system. Even then, it takes an age to build: the last successful one = being 12:39:27 (and that potentially benefitting from prior ccache = builds). That mongodb70 port takes about an order of magnitude longer = to build than an entire buildword/buildkernel on the same system. I guess building software yourself just takes more RAM these days, and = recognise that the RPi2 does not have much RAM in the grand scheme of = things by today's standards. I hope a "-j1" build works for you. Cheers, Paul. From nobody Fri Nov 7 15:55: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 4d33ZK2pQwz6G7Ks; Fri, 07 Nov 2025 15:56:09 +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 4d33ZK0cDQz3WTQ; Fri, 07 Nov 2025 15:56:08 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview8.colo2.realworks.nl [10.2.52.38]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4d33Z85hXFzDD; Fri, 7 Nov 2025 16:56:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1762530960; 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=ay1Mjsx2T+jsYX376eZwR+bik9KEAGiA4Tx4wk9T5m4=; b=ufFNmO98k6nEALGMMrv1wathz3vEYQ9gqSwo8MF7fJvoJSrqMQsQihBh9umvbT6ts+5cgl TRSsZKR4c0+sWBIYlIo/AS9V/+xvP+l3VyXP0+3kwq0NHWkYeU9NrIdwgvLoUuk9NrC9wB o5cE2atEoCj/C32QQno0nEFh0BQ/n+DceYR6rXKKMof3WvOPzYyb+CT+z9czLPNxVfw2I6 8C/tPQ4y78vyOQ65VCMWdXiQPuMnz+jS9CppSxEzy3JBNvyiK+2VrHlqvSdsBBWVfDuJfT 5KADp0KwmgbJMVHjzV/vKGcNwh+BSaj0+5dEReVZXAbiGABfUGdKNZJi9nv4dg== Received: from crmpreview8.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview8.colo2.realworks.nl (Postfix) with ESMTP id 46C962C0BDE; Fri, 7 Nov 2025 16:55:59 +0100 (CET) Date: Fri, 7 Nov 2025 16:55:59 +0100 (CET) From: Ronald Klop To: Paul Mather Cc: bob prohaska , freebsd-current@freebsd.org, Mark Millard , freebsd-arm@freebsd.org Message-ID: <1993483939.9508.1762530959936@localhost> In-Reply-To: <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> Subject: mongodb - Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld 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_9507_188116454.1762530959558" X-Mailer: Realworks (772.17) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview8.colo2.realworks.nl [10.2.52.38] with HTTP; Fri, 07 Nov 2025 16:55:59 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:144.0) Gecko/20100101 Firefox/144.0 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: 4d33ZK0cDQz3WTQ ------=_Part_9507_188116454.1762530959558 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, A bit off topic, but as maintainer of mongodb70 I can tell you that I do my test building on a RPI4 with 8GB of memory. It has 16 GB of swap, but that isn't used that much during my build tests. I do add LDFLAGS+= -Wl,--threads=1 to the build. In my experience the linker is using a lot of memory when multi threaded and at the end of the mongo build you end up with 2 or 3 binaries being linked in parallel if you are unlucky. You can also play with MAKE_JOBS_NUMBER=3 to keep it from running to much in parallel. Of course limiting parallelism makes the duration longer, unless it is swapping so much that sequential compiling without swapping is faster than parallel building with trashing the swap space. Find the sweet spot. And yes, MongoDB is a monster to compile. Regards, Ronald. Van: Paul Mather Datum: vrijdag, 7 november 2025 16:42 Aan: bob prohaska CC: Mark Millard , Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Onderwerp: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld > > On Nov 6, 2025, at 9:22pm, bob prohaska wrote: > > > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: > >> On Nov 6, 2025, at 08:38, bob prohaska wrote: > >> > >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: > >>>> Hi, > >>>> > >>>> To me it sounds like your machine is overwhelmed by swapping. > >>>> > >>>> Try -j1 buildworld. > > Maybe a -j1 buildworld could be at least somewhat informative. > > Lately none of my Pi2's has made it through buildworld > > without hanging silently. If -j1 buildworld completes, > > that would be a significant change. The test will take a > > week, but the problem has been going on for a year. > > > This isn't related directly to building on the RPi2, but just a general comment that on a system with 1 GB RAM like the RPi2, building with -j3 (or anything more than -j1) is probably wishful thinking at this point given it seems the RAM requirements of LLVM right now seem to be creeping ever upwards. > > LLVM 19.1.7 seems slower and more memory-hungry than ever before. Maybe it's LTO? I don't know. My current bugbear is the databases/mongodb70 port which will no longer build for me on the 16 GB RAM FreeBSD/amd64 14-STABLE system I use to build ports locally via Poudriere. It will grind away for hours and ultimately fail due to the compiler being out of memory at some point. I found a Bugzilla report by someone who attested it required 24 GB RAM to build, and it will only successfully build now for me if I add an extra 30 GB swap or so on that build system. Even then, it takes an age to build: the last successful one being 12:39:27 (and that potentially benefitting from prior ccache builds). That mongodb70 port takes about an order of magnitude longer to build than an entire buildword/buildkernel on the same system. > > I guess building software yourself just takes more RAM these days, and recognise that the RPi2 does not have much RAM in the grand scheme of things by today's standards. I hope a "-j1" build works for you. > > Cheers, > > Paul. > > > > ------=_Part_9507_188116454.1762530959558 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

A bit off topic, but as maintainer of mongodb70 I can tell you that I do my test building on a RPI4 with 8GB of memory. It has 16 GB of swap, but that isn't used that much during my build tests.

I do add LDFLAGS+= -Wl,--threads=1 to the build. In my experience the linker is using a lot of memory when multi threaded and at the end of the mongo build you end up with 2 or 3 binaries being linked in parallel if you are unlucky.
You can also play with MAKE_JOBS_NUMBER=3 to keep it from running to much in parallel.
Of course limiting parallelism makes the duration longer, unless it is swapping so much that sequential compiling without swapping is faster than parallel building with trashing the swap space. Find the sweet spot.

And yes, MongoDB is a monster to compile.

Regards,
Ronald.

 

Van: Paul Mather <paul@gromit.dlib.vt.edu>
Datum: vrijdag, 7 november 2025 16:42
Aan: bob prohaska <fbsd@www.zefox.net>
CC: Mark Millard <marklmi@yahoo.com>, Ronald Klop <ronald-lists@klop.ws>, freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Onderwerp: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

On Nov 6, 2025, at 9:22pm, bob prohaska <fbsd@www.zefox.net> wrote:

> On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote:
>> On Nov 6, 2025, at 08:38, bob prohaska <fbsd@www.zefox.net> wrote:
>>
>>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote:
>>>> Hi,
>>>>
>>>> To me it sounds like your machine is overwhelmed by swapping.
>>>>
>>>> Try -j1 buildworld.
> Maybe a -j1 buildworld could be at least somewhat informative.
> Lately none of my Pi2's has made it through buildworld
> without hanging silently. If -j1 buildworld completes,
> that would be a significant change. The test will take a
> week, but the problem has been going on for a year.


This isn't related directly to building on the RPi2, but just a general comment that on a system with 1 GB RAM like the RPi2, building with -j3 (or anything more than -j1) is probably wishful thinking at this point given it seems the RAM requirements of LLVM right now seem to be creeping ever upwards.

LLVM 19.1.7 seems slower and more memory-hungry than ever before.  Maybe it's LTO?  I don't know.  My current bugbear is the databases/mongodb70 port which will no longer build for me on the 16 GB RAM FreeBSD/amd64 14-STABLE system I use to build ports locally via Poudriere.  It will grind away for hours and ultimately fail due to the compiler being out of memory at some point.  I found a Bugzilla report by someone who attested it required 24 GB RAM to build, and it will only successfully build now for me if I add an extra 30 GB swap or so on that build system.  Even then, it takes an age to build: the last successful one being 12:39:27 (and that potentially benefitting from prior ccache builds).  That mongodb70 port takes about an order of magnitude longer to build than an entire buildword/buildkernel on the same system.

I guess building software yourself just takes more RAM these days, and recognise that the RPi2 does not have much RAM in the grand scheme of things by today's standards.  I hope a "-j1" build works for you.

Cheers,

Paul.
 

  ------=_Part_9507_188116454.1762530959558-- From nobody Fri Nov 7 16:16: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 4d34165Rrjz6G8Tv; Fri, 07 Nov 2025 16:15:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d3416298vz3ZQL; Fri, 07 Nov 2025 16:15:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5A7GGmPQ006212 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 7 Nov 2025 08:16:48 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5A7GGmul006211; Fri, 7 Nov 2025 08:16:48 -0800 (PST) (envelope-from fbsd) Date: Fri, 7 Nov 2025 08:16:47 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <83E924D9-79EA-4116-86EC-3B861BB4873F@yahoo.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: <83E924D9-79EA-4116-86EC-3B861BB4873F@yahoo.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d3416298vz3ZQL On Thu, Nov 06, 2025 at 08:15:49PM -0800, Mark Millard wrote: > > The enter-tilda-control-B sequence is via the tty driver and > kernel. It is not tied to a specific process. > Would debugging via JTAG offer any better recourse to a silent hang? Thanks for writing! bob prohaska From nobody Fri Nov 7 16:26:07 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 4d34FF552lz6G9Sy; Fri, 07 Nov 2025 16:26:25 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [198.82.170.123]) (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 4d34FF30cgz3fFm; Fri, 07 Nov 2025 16:26:25 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2601:5cf:407f:8a51::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 1824E60AE6; Fri, 07 Nov 2025 11:26:18 -0500 (EST) 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 \(3864.200.81.1.6\)) Subject: Re: mongodb - Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Paul Mather X-Priority: 3 (Normal) In-Reply-To: <1993483939.9508.1762530959936@localhost> Date: Fri, 7 Nov 2025 11:26:07 -0500 Cc: bob prohaska , freebsd-current@freebsd.org, Mark Millard , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <32DD797F-E5B6-4198-93D3-738C83A79AB3@gromit.dlib.vt.edu> References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> <1993483939.9508.1762530959936@localhost> To: Ronald Klop X-Mailer: Apple Mail (2.3864.200.81.1.6) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:198.82.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d34FF30cgz3fFm On Nov 7, 2025, at 10:55=E2=80=AFam, Ronald Klop = wrote: > Hi, >=20 > A bit off topic, but as maintainer of mongodb70 I can tell you that I = do my test building on a RPI4 with 8GB of memory. It has 16 GB of swap, = but that isn't used that much during my build tests. >=20 > I do add LDFLAGS+=3D -Wl,--threads=3D1 to the build. In my experience = the linker is using a lot of memory when multi threaded and at the end = of the mongo build you end up with 2 or 3 binaries being linked in = parallel if you are unlucky. > You can also play with MAKE_JOBS_NUMBER=3D3 to keep it from running to = much in parallel. > Of course limiting parallelism makes the duration longer, unless it is = swapping so much that sequential compiling without swapping is faster = than parallel building with trashing the swap space. Find the sweet = spot. >=20 > And yes, MongoDB is a monster to compile. Many thanks for the MongoDB compilation tips. An extra complicating = factor in my case is I'm building via Poudriere and so the = poudriere.conf settings can confound things when it comes to controlling = resource usage. The mongodb70 port has caused me to change my = poudriere.conf settings. Before I started building mongodb70, I had PARALLEL_JOBS=3D1; = ALLOW_MAKE_JOBS=3Dyes; TMPFS_LIMIT=3D8; MAX_MEMORY=3D5; and = USE_TMPFS=3Dall. Now, I have commented out PARALLEL_JOBS=3D1; = ALLOW_MAKE_JOBS=3Dyes; TMPFS_LIMIT=3D8; and MAX_MEMORY=3D5, and have = USE_TMPFS=3D"wrkdir data". I also added mongodb70 to TMPFS_BLACKLIST: = TMPFS_BLACKLIST=3D"rust mongodb*". So, I went from 1 builder with multiple make jobs to multiple builders = with just 1 make job. (Before needing to build ports like rust and = mongodb70, I used to have multiple builders with multiple make jobs per = builder.) I've also dialled back a little in what TMPFS can be used = for. Usually, the system runs with 16 GB RAM and 8 GB swap on a 6-core = system. Right now, I have to add extra swap to let mongodb70 build = successfully. I suspect prior TMPFS usage is not helping matters. = Also, I don't know whether MongoDB is using a reproducible build, = because ccache doesn't seem to speed things up much for me after a = failed build. That's just a gut feeling, though. I can echo your observation that the swap doesn't appear to be used much = for most of the build. It's just when it comes to a certain point where = everything explodes and LLVM dies from OOM. Adding extra swap has got = me past that point. Cheers, Paul.= From nobody Fri Nov 7 16:41: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 4d34Zc0HNhz6GBhP for ; Fri, 07 Nov 2025 16:41:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4d34Zb2xh2z3k5d for ; Fri, 07 Nov 2025 16:41:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762533685; bh=GDj47Qyky2Q0GCW7pZD5wUFo+GLsLI05ilhvp7GJv/0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T4Xq61Y8YJ4US0jMWGDSCaEbXnWu49ydVkwLiJwzja/6oFu85DuBVIUfKtGkltodwRS9zN2lg4MuiSccwVvuVHNLOKWwiSyfAJl/6bDIEaHC0Pon/AT4d85Qw4E9wxo7Qfzy30lPnEaNlAHpUdGMPk4FDo7AUhdojuupmQ5A3yeM1d0V24AAX5F68OKj+lK+3+KUEzaw7EB68Mt8igWRGQ5S1T5GBUWqeNTksOlQoJCsn0IVXgtz9QSUwftugKqSVgyvRFFyWOxOZ8gZGbzIk3lQr9VKkmtUoPzCYpH2tI9gJs+RI1X4kmIlw5mcMl1BAugiKVeBYNWPEuYfGfeV1g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762533685; bh=Xg+T333S4KU/CahOLANkwDfhA9//P3CHvOsnubhf84q=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ffgyZ+1CMfAEYOLS3dIFAWWbhrdQf+poo4Gi2FiU/BoFPgw1UQ3+GvvV0uUENqZ+gOJr/S/4M6RQftnd6tzKG8xUbTx2xznr7Rnc90aOC3+NZhfamEREriZPVfa9mkT1dDiSM0c8OEBaQ9hOwUSgHo+bQ/Aa5+4mwyRQJ4EtjRZtc8Y5fXLlsVah4xnv4hCgsIwRNqo0narxsGwREGw859hHKmKOeHrpFObKDCXFThkpXLCPGKouBZnNrGuVTmoNMwZ1GzrJAqJ7/Kd+z578kjMm5cj861NbASt5HzgQ4kTKancd2/Tme5OY6T/ywG3joRc1pY8pOIfBJTTi3+QRYQ== X-YMail-OSG: ExCdDpgVM1nMvSY1Dr.NJJoGNPfRx_PyEfsHm00zZXsPkxbDN_nS7duGvqGFYzW 2QHbGFU_ZSK7HEHFu3uGji.QbuQaOc_rcLlvMLOseD0T0vmck_xIx6Id2QIXnCQAbrq60GzkQWYc hKMEWCjyKR61WECrobUgkpzCVC9Z7nMpubja_Vzxuz4R_Gm45xqfnRxVUWPK1LXqRh__MahjZSRl ESmEhIHPZuq9yRV6sPImIHx9TW6dgIqlhVg9A7d0u5D_IZ_Gr6dQNqkOhDcYTlcKb5xUC6vwomUq q7KFcfYIO3S0CJ_pwDbym3m6l0yauWWk2wr8syEERE8obx6uFLxImeG667eSocxFetYIZs16BkyA rV14tt6s49zPEEHrQhBeTtFRi7Wg5nWIqrAsfNIph.b6hMmJzZ2NiH0u1fLLmUQQ9RtjjwoAavV0 Pp5vplGOF.pk_ttY2MEtacpgQBq8qeCrgXYoKQw4HCi1dxV2dYo.MWauuPdaEQ7.fh.hr8fVmrHm wlqhwuKoehXLFJODqs_DsgsDNsqm1Oghx0rchzFtAADtwzyHdPD3KgXuAoLiCFdG8dgv683RdVAB BTxcbBGxDAm1A1Y6FxQRS3It5d3bmW9FMhqhkqxl3mIKivYnihmuP6Zfago3vOJC85LMMqDfe6Cd oV3_z04TukWz8cG7u5kZR0kMhHyx8pys_vUL8V4rtid07YaS2wZRErMPFbylJ4RycPknVF8hI1Nt qJdJGuH2eSTIDlt4uqrib0UcysXPgD.7rgDX9GjhmaYGpWW3e89X7U9VNYchho44VtthvDCrIlOW 30fr5FxLlwnhBu1u5htPt211aKp0dYIleZ8sA0figNfX6PiLRm.7HW6yG_jkqQPeTVBEahwd.FNX RDrvMLUXZgu57sSw5C.NAgBqMvt.8TYWfL.2NxMmZWENeZEHBw3J6z30.Wq3Y.yWyIe0bDPecCeq ubTwzmKupc8hBLBX8URHA0Itq.NbuSp5m2aN.JnVHdAD3ygmDmXyZepWHvsgyQjiOx4N.IEZZDeg ZJZtkYPCd6DVjrYaCWrGM1DEMgOazSa8BLlsC3tzHle_xogxPzCnn_PWR2YamC5AlsSRcLjzA8K_ ZZ8B0PMM3FVKtNvqa8Pg_Y0KnSz8SNPwYJCLzojlLMsVP4XNlazKwAhJfToxNDufCVLAnpiqZNQE blmj1pcurwFEvGodEYcT5bLwqs5yNY_tfQUuihMygvIq31QWjUfH1yN2PArwDXaBkXGZ4WSZE6jK L4u3maPI4ZPmqIDJsTGUPu5knKRQyILMB7b_Q09AZcLPAlMFZFqAJwmcRilKI4u87ISXhuAuQ5SC o.FoJMXfGbIo46uGqrgDz.yCndM0JiZAYBAV0xcK8kj6Y06wDunq2_b4lvhF9c_RLX_NAb.rag6G NFRAVJIoMpSxdreFaYRdU_cvgHR1KtPW_5XzWyzl5_ZOf169RJMMVT76OfkYYE42oq423_pFFhDi JDCqwNlIGukd_koq8EBGCckItVdBJXwd1qcFrqBIEKUkB4i8PCY3E6eyhKoCecZ_gjJqkG2wFjMZ AHmSI5O5_RnIPwbnMQ.Q8lt3c14bIflrsX9BfbozBOteU1rlIFV.7fZV8v.nBA1TWEaS3InMWNjO BcaZq1joJRHhtHnJshbH_Vl8CVs36ByaKpKBntGOj8d0_88HIbATIY8i.OBFQ.C1Ihgnz8RX.6Z5 nTgpGk4Wx7MO1PBC3xJ7oL1_Rf2IIW43o8g4IptWLbC_fZSIW..tmeqp9cIoMssWyJtaL2HOirTl bHpTpQ.v9xOIT.9TU2rGPCgUz22Suqm_PDyn3qOegOmM_DmVBdmGROPJd6EX_T5vMu6K3ShLiQed qDbFJE8znLgdVhtJwgsv63AFW4wfQKesLC7mQXDBV1bK67cTt76i3xzelGSx9j2CsVpdB41Z_izQ SsPytPdHrxvdjU.fgUKs9bueY0ddSDjqiMN_JTcNK.Vi7FpoCI08C4_ZbOQ32AjP_1S6OhYJtbmI ZEydvqrIfFJeXUQ.EEOSY5xDLN71GOTVruYScu8e2ROtU8dzsqfHbkFKkxBsbyjaJZI3sp7rKukA zjqlOWNXwp34V8rb.XLLKblvLwXOhzx54gUCWpgTCr3EsozztXd2Kpvhrvrm9MvDi2LHyLskA0FI FJm3k2hshEjMZZ0SipvZHa94ABmYYf3aYWT8eS98F5bOePb11EHjOMCQFEFa7mqb3DmpG6KQSZHo uPWKgs_DtyqdSpcHUP97fMx8S1zbDvXibaQbHXXEEoirso_O3TWdC1NjI.tq3YFpdoz7hE7nfNwD s X-Sonic-MF: X-Sonic-ID: 90f09f8f-c90e-41c3-86af-726544616dd7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Nov 2025 16:41:25 +0000 Received: by hermes--production-gq1-86c5846576-db8fx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 21faa6fa16be9d7e0c50f4d3ffed2cd6; Fri, 07 Nov 2025 16:41:24 +0000 (UTC) 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: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Mark Millard In-Reply-To: <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> Date: Fri, 7 Nov 2025 08:41:13 -0800 Cc: bob prohaska , Ronald Klop , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d34Zb2xh2z3k5d On Nov 7, 2025, at 07:42, Paul Mather wrote: > On Nov 6, 2025, at 9:22=E2=80=AFpm, bob prohaska = wrote: >=20 >> On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: >>> On Nov 6, 2025, at 08:38, bob prohaska wrote: >>>=20 >>>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: >>>>> Hi, >>>>>=20 >>>>> To me it sounds like your machine is overwhelmed by swapping. >>>>>=20 >>>>> Try -j1 buildworld. >> Maybe a -j1 buildworld could be at least somewhat informative. >> Lately none of my Pi2's has made it through buildworld=20 >> without hanging silently. If -j1 buildworld completes, >> that would be a significant change. The test will take a >> week, but the problem has been going on for a year. >=20 >=20 > This isn't related directly to building on the RPi2, but just a = general comment that on a system with 1 GB RAM like the RPi2, building = with -j3 (or anything more than -j1) is probably wishful thinking at = this point given it seems the RAM requirements of LLVM right now seem to = be creeping ever upwards. Bob has been building FreeBSD on these RPi2 v1.1 and other RPi*'s for = many years. He is familiar with the progression for resource requirements. But his activities have also previously helped with identifying problems = and providing evidence about problems that have lead to FreeBSD fixes --and = to configuration recommendations that have proved handy for me for far = bigger systems doing system and port-package builds (including normally rare "bulk -Ca" built tests). > LLVM 19.1.7 seems slower and more memory-hungry than ever before. = Maybe it's LTO? For the most part it seems LTO is not enabled by default because of its resource requirements (including time and RAM+SWAP). Are you = deliberately choosing to build some stuff with LTO in use? I avoid it. > I don't know. My current bugbear is the databases/mongodb70 port = which will no longer build for me on the 16 GB RAM FreeBSD/amd64 = 14-STABLE system I use to build ports locally via Poudriere. Type of processor? How many FreeBSD CPUs? ZFS? UFS? Other use of the system that competes for resource during the build? poudriere.conf : USE_TMPFS=3D??? TMPFS_BLACKLIST=3D??? PARALLEL_JOBS=3D??? # (or command line control of such) ALLOW_MAKE_JOBS=3D??? # (defined vs. not) ALLOW_MAKE_JOBS_PACKAGES=3D??? MUTUALLY_EXCLUSIVE_BUILD_PACKAGES=3D??? PRIORITY_BOOST=3D??? other relevant possibilities? make.conf (or command line control of such): MAKE_JOBS_NUMBER_LIMIT=3D??? # or MAKE_JOBS_NUMBER=3D??? Do you use anything like: # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 Or: # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: #vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes (showing defaults at the time): #vm.pfault_oom_attempts=3D 3 #vm.pfault_oom_wait=3D 10 > It will grind away for hours and ultimately fail due to the compiler = being out of memory at some point. I found a Bugzilla report by someone = who attested it required 24 GB RAM to build, and it will only = successfully build now for me if I add an extra 30 GB swap or so on that = build system. Even then, it takes an age to build: the last successful = one being 12:39:27 (and that potentially benefitting from prior ccache = builds). That mongodb70 port takes about an order of magnitude longer = to build than an entire buildword/buildkernel on the same system. >=20 > I guess building software yourself just takes more RAM these days, and = recognise that the RPi2 does not have much RAM in the grand scheme of = things by today's standards. I hope a "-j1" build works for you. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 7 16:49:05 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 4d34kG0zB9z6GC3V; Fri, 07 Nov 2025 16:48:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d34kF64hmz3m95; Fri, 07 Nov 2025 16:48:05 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5A7Gn62f006305 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 7 Nov 2025 08:49:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5A7Gn5TX006304; Fri, 7 Nov 2025 08:49:05 -0800 (PST) (envelope-from fbsd) Date: Fri, 7 Nov 2025 08:49:05 -0800 From: bob prohaska To: Paul Mather Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> 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: <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d34kF64hmz3m95 On Fri, Nov 07, 2025 at 10:42:24AM -0500, Paul Mather wrote: > On Nov 6, 2025, at 9:22 pm, bob prohaska wrote: > > > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: > >> On Nov 6, 2025, at 08:38, bob prohaska wrote: > >> > >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: > >>>> Hi, > >>>> > >>>> To me it sounds like your machine is overwhelmed by swapping. > >>>> > >>>> Try -j1 buildworld. > > Maybe a -j1 buildworld could be at least somewhat informative. > > Lately none of my Pi2's has made it through buildworld > > without hanging silently. If -j1 buildworld completes, > > that would be a significant change. The test will take a > > week, but the problem has been going on for a year. > > > This isn't related directly to building on the RPi2, but just a general comment that on a system with 1 GB RAM like the RPi2, building with -j3 (or anything more than -j1) is probably wishful thinking at this point given it seems the RAM requirements of LLVM right now seem to be creeping ever upwards. In the past FreeBSD was quite vocal about running out of memory/swap. It would issue warnings on the console that swap was low, slow to become available, or exhausted. In this case nothing of the sort is happening. The machine does bog down when swap usage exceeds about 500MB, but it doesn't stop or complain. The scheduler seems to figure out which theads are making progress and gives them higher priority. Eventually the backlog is worked through, swap use drops to 50 MB or less and CPU usage rises to 90+% per core. That's when the system is hanging and unresponsive to enter-tilda-control-B. If it's a memory exhaustion issue it's happening invisibly and only later causing a stoppage. It's the invisibility of the problem which hints at a deeper flaw. I don't think it's possible to anticipate how much memory a program will eventually require, but it does seem possible to recognize when a resource limit is crossed, if that's the problem. I think a -j1 buildworld is likely worth a try, but if it succeeds I don't have any idea where it'll point a finger. Thanks for writing! bob prohaska From nobody Fri Nov 7 17:02: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 4d353Y0NKWz6GDD6 for ; Fri, 07 Nov 2025 17:03:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 4d353X6Lpqz3psf for ; Fri, 07 Nov 2025 17:03:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762534978; bh=sinK7gEplWwdK8SdOO9SFT1B1FDegU/LgkCX1RjxLOg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jbGYWP8Q9GRJJzcXUy2arpeBd3/zNenM/64W3VMoNMYUnZ+dZZ/9xuOI2oQtjeROrGBL67Jb4agS0nfQfXIkDXAa7v/vAUJci4UMMe81waVsbIOFK2zJGkpXJ2OPXbHyGg62oeEpApKOqNQnMnyxP3Z90OYL4sAVOuuktEfAWZjIWn46tBE7/wCgU23TwZ8QWNdLu2e+G/h1hNVFzoGvBx0erX+upF/RdGHNDS7O86Ctw7Vqr1QJ5/RnEPht7nhCXMiLGS9ZuSRm06gP9YF2Ea+2fF8kdQ1tPKtXiNzNBNyLJ7zLgz6mzQeZZTjjhagiaVTSn0XX2YoKPMneNrKVEg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762534978; bh=BFfa36gfXqfTym00KPH8vFRGSyu4SxYbq695y58sLZn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=siFo3KDeChG2TLQWMOgm+xYIXtHxmDyRxE+iCeMfK+bGaJlA/wk/VucB8/eycyFuhU0EFa8Ceg8hAT4FMYU0dDojvwwBVggMZ5RrzTaSZe0ZTPi8qY6PTcbuMsSvG5lbCmL1ZWvKBYwC9dM/HcHMMgMQmwJC6VBxBJH98WboVG+9/0m2Emoh7Dw/qRvosecKWdX8mUH0D+K6i/u3iy5by7JXNUcAb4kfqvBGfnDdWAI+S+g494gj+OBe8KcExRgcn3fynfSAUAJdA9lhesf5o+1uXG/PAPP+pUdECj6uvSXanLpLGkt8HYRM+QfiqJ0NrUTSFTnObKygiZQuiOHCdA== X-YMail-OSG: 3bCXF1wVM1kZOhHmShqx9PEVKsx5EOhslFRJemf6YN2o2rmf1ysTKyUTceteAn_ AoWHRHm1.AmFEW7xOyP_Y8FHKnroMzL0pur1KJYFe9osaYjpsg_fPf.W1.8lu2KvMZ4yxawoP1kS 2rJvbtEdA3pJOjGM81lno8VQbHQ52eETslrTfJxEJf880gMYlur2fFf57xBa3q006a_Wp.uuDpdA _ss3eNXWn3OWQuubD3cREV_I2bTj8WIEE.x5unCv77RkHXY6522RZvBcV54O48cYANOqFzDaASzj fylSIEiHA1zSpMwsKJkBNaDLtdHwtg5X_IL8WMiY7ojkITV2UiRNo0_eD9Q_mJao6Fam9B9N_iG1 grGGpa_Kq3qUvJc1x4BiZrwBd_K0tgwODcEL1Iu1jI4Ws63jdoWXIdl3Lkqtmq5kjyBJdllH8Htw dOJwWUa8YhYn3YtOzeNt8LbLHENjASANPfUoP5GGV.BxeI5yEEOqk3K_cdVh0Nccw9RADnGMwnme GrU79.uylciwMIoHGnKwuwWz9OMv2h06QTznG3fyYfWJ2tZjsiBgnAvsGlMiHpM2mztW.Uw8ONEx M4u0lNz2t7N9o6nXry9xUbfvft9lP7Wx.g9z3ZlleKPq5qG190f4EAmoRl6SZUJt5KBwRMbpj_jy bYkzQVd6dUJ4mHWxoDCLqXjpvjaA5J_RrSEctdQX9VMUT6kJFdfaZj6EIOK06fmX5M7M3civNAUK 7QRqXMDXmKIiFD9ONlUT0w.hnJ_sUL6AHBUXmxoKm7DmJrW1TnfPVLLYkgZHEQ3V5zX1tQ2EIJt4 BRrGcaZz2Vx9ZMh.dJWBuyKGVjGCE9gAOLQxLSkxWJuhql_cNwcDzW0Kf8BcsURJvLWjhdBoNVfP sSOpxLevw4cr2wjDBfrnh5am.d9Wc7O_NRBVjnWW5Sg5A_o08cVGajJux2CtzU0ekBxzQJPVFhg3 Jry3MkCHSdAoLLjJUG2Dx0mcKXeJrUbZCIA6MK56bYF6sLACTaE.WoKX3b0TEixqFzhRFj4.7GHd v2CSsGcmfzmJ7cnK9BpUXSg2u0iPIT8VZrgz4cg_gUH0zPHjhm19OzoPiLiO.BQ9k0NHOB4SwRvo i97wPWBeC0SImW0xM2Gszqqx4.PvK9kcOpACM1GXFlPukt000TNPQYkEAuBSZLVINfc.oXDVMoCg zTaw.LLWDjQDchvF1cEc.GvucTahI7t2GoqVVjws8loqvl3gRfYNQ1VVFh3yJFfhZMloqI9leNBW zrBUQHnh9TLWVJ9nZHtL1NdoRMtUlSsjIBFk0W3kkhX3Yjunz1nOEOYGi7IohkIVvgPO_N84U9Ka xuAJhpq9.r3kZsL2PjkbrjXhma_XOvBfVzzwlXmO.Sl.Tvh4JM4Ox3UD0qUx.7pvD0uAulviqkVS y0oGEnGFQCkighrBZwVNglFCIDtvw6buR73NYS.7cYoCYdS577aStW5REJRWaFwDidKVL5Nt3iss LPY90oYwwzTG09rRIayyZq4.flCmMqkRmpZODXajGvkIEXI4f5IXnF0CxShJoSIeeV4QTIqyLGoJ l7llqZyCfeW.Ts7gSMzsDfqsnA76KHRIMt4DrsSWyM4yXDru8HNEdXnYDXBEIgL3_nCarIvciB4o FJUvOuwmWfI_psda4BtbClNrqcXpQM4QMg_aiG0kyV2aZ94ew0okq9dl.4OTgJDNK0yj0hofTOCG EfNm0UQvP5wqzbnDyHUAzTCdrjoOBlmjo.LxmV9I_EBeAYbKU5IsejbYLSV5XaH48.oq_0Ebgi2E LNc8KoD_RGEX96VuqSgLLCeSebXSdewJxem8RS78HypPVnf2kYQZhzlOnToOcCeidrih8h0FpA4Q T8nbMTNT89EqtFwC0llW6PL5zjk8AkGTXiHj3hq5IHuXXbZJIu9Fue8CXbwyXFEi36LM7mV4SeRm jXQoreEMhk4BGGYMxXbvQPfKXyv2fKC4Woj_VuMNdMpGVJqSZp9wHzTkrfVqJv79VDcj6KLPx34b MU1K.agdUc3kr2jcm1nkPJR635oJq2heHeExwfzPYceyJBXIC6vYOLoiHMCxdI5Lsq12_F.9nWcC 4aOvosd2bLFqlYPRCq7kcT8ABqZTBw1w2CmXj_3pDfqWpCj5Kk.XitbPbiJrD4ObJFA9PnSHPyNj 9kARqFqVPVSoo9U1ewIjWRPQvA9_Yp7k3TSKxmcFqrF75LYtqr8luNaYyXTCPkiLxiE2WTPM3way t99YwRgwBhECnVChx9PuM3XQRGbJd2_RDSfSKyRQWZaX6aLAxM3v5I_l0sYIHxzg1YE8Q4T8Fmj6 Q X-Sonic-MF: X-Sonic-ID: 94069952-f8f5-4c5f-b3dc-03bfde110ce1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Nov 2025 17:02:58 +0000 Received: by hermes--production-gq1-86c5846576-brxcs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d7e10a7b005debc51067ed533b904ce5; Fri, 07 Nov 2025 17:02:54 +0000 (UTC) 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: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Mark Millard In-Reply-To: Date: Fri, 7 Nov 2025 09:02:43 -0800 Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <83E924D9-79EA-4116-86EC-3B861BB4873F@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d353X6Lpqz3psf On Nov 7, 2025, at 08:16, bob prohaska wrote: > On Thu, Nov 06, 2025 at 08:15:49PM -0800, Mark Millard wrote: >> >> The enter-tilda-control-B sequence is via the tty driver and >> kernel. It is not tied to a specific process. >> > > Would debugging via JTAG offer any better recourse to a > silent hang? I have no experience with JTAG or analogous. My logic analyzer background does not really apply. Even if I managed to replicate the behavior, I've not come up with any way of being able to gather useful evidence based on what you have reported. One avoid-the-problem technique is to build on a more capable system that supports armv7 chroot use --by mounting the drive and chrooting to it, doing the build and install in the chroot, and then exit, dismount, and move the media back to the RPI2. This does have the advantage that the live kernel is not being changed and the system processes are not being updated, so reboots during the install are not required: There are no runtime conflicts with the live system. But it also assumes that your context supports also having the disk media mounted on the more capable system for a while. === Mark Millard marklmi at yahoo.com From nobody Fri Nov 7 17:06: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 4d359k5Sdnz6GDg8; Fri, 07 Nov 2025 17:08:26 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d359k2gYqz3rpS; Fri, 07 Nov 2025 17:08:26 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Authentication-Results: mx1.freebsd.org; none Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.18.1/8.18.1) with ESMTPS id 5A7H6jEQ063743 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 7 Nov 2025 09:06:45 -0800 (PST) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.18.1/8.18.1/Submit) id 5A7H6j8V063682; Fri, 7 Nov 2025 09:06:45 -0800 (PST) (envelope-from warlock) Date: Fri, 7 Nov 2025 09:06:45 -0800 From: John Kennedy To: Paul Mather Cc: Ronald Klop , bob prohaska , freebsd-current@freebsd.org, Mark Millard , freebsd-arm@freebsd.org Subject: Re: mongodb - Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld Message-ID: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> <1993483939.9508.1762530959936@localhost> <32DD797F-E5B6-4198-93D3-738C83A79AB3@gromit.dlib.vt.edu> 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: <32DD797F-E5B6-4198-93D3-738C83A79AB3@gromit.dlib.vt.edu> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d359k2gYqz3rpS On Fri, Nov 07, 2025 at 11:26:07AM -0500, Paul Mather wrote: > ... So, I went from 1 builder with multiple make jobs to multiple builders with just 1 make job. ... I'm doing some in "reasonable" build VMs (8 CPUs, 24G of RAM) and that'll run into problems. I haven't really wanted to cut down on parallelism for a few "bad" actors, so one thing that I've done that works pretty well is a poudriere build run for just rust, then the real poudriere run. In that scenario, rust ends up being the top of that little tree so the ~45 or so dependencies can happen reasonably fast and then rust just grinds away. The rust and llvm builds (and I think there is a gcc one because of edk2) take a long time to build and are definite bottlenecks. I don't really want to slander gcc because it may just have the misfortune to be crunching alongside llvm. From nobody Fri Nov 7 17:19:02 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 4d35Q10pcqz6GF5W; Fri, 07 Nov 2025 17:19:05 +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 4d35Q05gMnz3ty8; Fri, 07 Nov 2025 17:19:04 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview3.colo2.realworks.nl [10.2.52.33]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4d35Py4w9Bz1RZ; Fri, 7 Nov 2025 18:19:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1762535942; 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=rh5IP52UgddQaaGh88sb7gYqQ3a6f5UVLKuacNPW76Y=; b=b2Uan4vRK71hGxV/1PoS7K13h41Jh8+Nv+q6jPW71VsAOqVZDBWOIHA/+68aDou5YJBvGf bfI7vCWnD+vSiGowvg356GeRL48ybKXmy0h3bTx1y9FwTAPtelOsKH8qNAj4qn3iWry9+7 xonZFTkW9FlWvD+aId8EvrTv2dJsWvC4+mbylRTEYDdFE7teHMY/1W6yZnSP/Cek6nM8/L Vc2QCw+1UwUURU7KoKr32B2IZ9M8SZtFeL0dOSDH6uo4POvNY7AhcdFi91ViGOWcB2I2cw PF0C4f8E5kks18xj1QVBY+RRxaZ0SRvr93QuM44r4HG8TLSpJifH8Gu3OzkP4Q== Received: from crmpreview3.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview3.colo2.realworks.nl (Postfix) with ESMTP id 49CF41400A1; Fri, 7 Nov 2025 18:19:02 +0100 (CET) Date: Fri, 7 Nov 2025 18:19:02 +0100 (CET) From: Ronald Klop To: bob prohaska Cc: freebsd-arm@freebsd.org, Paul Mather , freebsd-current@freebsd.org Message-ID: <1019311516.10662.1762535942098@localhost> In-Reply-To: Subject: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld 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_10661_1959876907.1762535942094" X-Mailer: Realworks (772.17) X-Originating-Host: from (localhost [127.0.0.1]) by crmpreview3.colo2.realworks.nl [10.2.52.33] with HTTP; Fri, 07 Nov 2025 18:19:02 +0100 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: 4d35Q05gMnz3ty8 ------=_Part_10661_1959876907.1762535942094 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: bob prohaska Datum: 7 november 2025 17:48 Aan: Paul Mather CC: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Onderwerp: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld > > > On Fri, Nov 07, 2025 at 10:42:24AM -0500, Paul Mather wrote: > > On Nov 6, 2025, at 9:22pm, bob prohaska www.zefox.net> wrote: > > > > > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote: > > >> On Nov 6, 2025, at 08:38, bob prohaska www.zefox.net> wrote: > > >> > > >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote: > > >>>> Hi, > > >>>> > > >>>> To me it sounds like your machine is overwhelmed by swapping. > > >>>> > > >>>> Try -j1 buildworld. > > > Maybe a -j1 buildworld could be at least somewhat informative. > > > Lately none of my Pi2's has made it through buildworld > > > without hanging silently. If -j1 buildworld completes, > > > that would be a significant change. The test will take a > > > week, but the problem has been going on for a year. > > > > > > This isn't related directly to building on the RPi2, but just a general comment that on a system with 1 GB RAM like the RPi2, building with -j3 (or anything more than -j1) is probably wishful thinking at this point given it seems the RAM requirements of LLVM right now seem to be creeping ever upwards. > > In the past FreeBSD was quite vocal about running out of memory/swap. It would issue warnings > on the console that swap was low, slow to become available, or exhausted. In this case nothing > of the sort is happening. The machine does bog down when swap usage exceeds about 500MB, but > it doesn't stop or complain. The scheduler seems to figure out which theads are making progress > and gives them higher priority. Eventually the backlog is worked through, swap use drops to > 50 MB or less and CPU usage rises to 90+% per core. > > That's when the system is hanging and unresponsive to enter-tilda-control-B. If it's a > memory exhaustion issue it's happening invisibly and only later causing a stoppage. > It's the invisibility of the problem which hints at a deeper flaw. I don't think it's > possible to anticipate how much memory a program will eventually require, but it does > seem possible to recognize when a resource limit is crossed, if that's the problem. > > I think a -j1 buildworld is likely worth a try, but if it succeeds I don't have > any idea where it'll point a finger. > > Thanks for writing! > > bob prohaska > > > > > > > If it fails without swapping you know you need to look somewhere else. Regards, Ronald ------=_Part_10661_1959876907.1762535942094 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: bob prohaska <fbsd@www.zefox.net>
Datum: 7 november 2025 17:48
Aan: Paul Mather <paul@gromit.dlib.vt.edu>
CC: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Onderwerp: Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

On Fri, Nov 07, 2025 at 10:42:24AM -0500, Paul Mather wrote:
> On Nov 6, 2025, at 9:22pm, bob prohaska www.zefox.net> wrote:
>
> > On Thu, Nov 06, 2025 at 10:00:19AM -0800, Mark Millard wrote:
> >> On Nov 6, 2025, at 08:38, bob prohaska www.zefox.net> wrote:
> >>
> >>> On Thu, Nov 06, 2025 at 03:45:01PM +0100, Ronald Klop wrote:
> >>>> Hi,
> >>>>
> >>>> To me it sounds like your machine is overwhelmed by swapping.
> >>>>
> >>>> Try -j1 buildworld.
> > Maybe a -j1 buildworld could be at least somewhat informative.
> > Lately none of my Pi2's has made it through buildworld
> > without hanging silently. If -j1 buildworld completes,
> > that would be a significant change. The test will take a
> > week, but the problem has been going on for a year.
>
>
> This isn't related directly to building on the RPi2, but just a general comment that on a system with 1 GB RAM like the RPi2, building with -j3 (or anything more than -j1) is probably wishful thinking at this point given it seems the RAM requirements of LLVM right now seem to be creeping ever upwards.

In the past FreeBSD was quite vocal about running out of memory/swap. It would issue warnings
on the console that swap was low, slow to become available, or exhausted. In this case nothing
of the sort is happening. The machine does bog down when swap usage exceeds about 500MB, but
it doesn't stop or complain. The scheduler seems to figure out which theads are making progress
and gives them higher priority. Eventually the backlog is worked through, swap use drops to
50 MB or less and CPU usage rises to 90+% per core.

That's when the system is hanging and unresponsive to enter-tilda-control-B. If it's a
memory exhaustion issue it's happening invisibly and only later causing a stoppage.
It's the invisibility of the problem which hints at a deeper flaw. I don't think it's
possible to anticipate how much memory a program will eventually require, but it does
seem possible to recognize when a resource limit is crossed, if that's the problem.

I think a -j1 buildworld is likely worth a try, but if it succeeds I don't have
any idea where it'll point a finger.

Thanks for writing!

bob prohaska
 




If it fails without swapping you know you need to look somewhere else. 

Regards,
Ronald

------=_Part_10661_1959876907.1762535942094-- From nobody Fri Nov 7 18:14: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 4d36f86cxYz6GKTF for ; Fri, 07 Nov 2025 18:14:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4d36f84PQhz494G for ; Fri, 07 Nov 2025 18:14:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762539274; bh=ZN4UMJ5DF8eOAeIknHdnYmLBwv5aWckmfBGXyEzLrNE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UzsJZJCkEPGmIyggtwSn4C8+DNaP6agIgLs6fYav4SiZvKEMOLOSuVsDZiyktrXe71wMrQFwmeXWxG8YjVWnQsbuH+fIVFBCXB1QLTPm7KyKGwhz+DIswJoh0U2jVX3N0tTMhHn9x2GTnr6tl3+IGSBa9VHiOpZAvCYnDJEA4H8ua87az0+JH3Yt9rSwBLsUKol8spgHvuqihr3rpY2/FMbLL7OSsMB63KmewK4/LYUKfWLBfAFNA5+JiEek0EOVuKp9K08UJ2Y92JBL5A8iBv7n/8XN6sbteTFqMif+bCeJlZddaaqgj7OBRzF5lTOeNNgwgDd0xiYJuZW3RBdAag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762539274; bh=VpRV2fnvZJvubzHlasJPhVIhTtRl05dymMOh1n+t5iC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W73ROmjydG38HbS8/gEo3D5WA7KyP151DlVVSDaN7Iy7S9gxSMxvcx6ZJ9WnrmtQTmLequK63upYtLKBGdtkIhXPMgMYsHeLq/HK/Kwvz+mnl6m2yMTMq/BvlRsyyjmxkEngQBt+vaL5wpYtdjIEj38kgjTR3lKXWpNIxJljN09i8r+eCQCanaevSg00NofrIwckIW+Dm1uS98e99TGt1RPR3uwLxyMcAW6WLgcKrlLiEHdQFDckBRKL2WTdjmNYasEuy66yg+TW5o1mUiXUWmylIGzPoUQ5FSnKnP8Z3nUQ3GvbyoPqRXMFyxWHSyCbXpRte+s+UOr5nbjXlqL6LQ== X-YMail-OSG: NNEVU6QVM1muhuoo1EODwz9kD3nM3CGUsvCNoXUeMtVYWOjFW2o1neutdnJXFDp faW7z0gRzskwpy5Tf_oj9_RpO0_.W8LRMGvCv_frXGuq254u6W19L7JoSdecNVefyufrdD_JO52H xz1eF.Sl7lWZnDNbKdZEJVpGVga_ruXhQf0twUqo3vAFoLlF0suDVNpjZ_ghGD5RTDOBfBeoRGSx NBdWlmmpzLIIk03p_VUeeV5HhafSJ9jX70C3nw0zPtMpTlzi6vrobiSFYYI5kdq.FZPF13R0SPxD nXS9LiRmhATEl3ot7Rkvuc.H7duZvFiUIZW2tJS_EhVlBr0SOeJDbQ_tEIPFSqcbQ5LASC00FNYV ufiVZG9hICUWNP3wqL2iP3.1VYgZDU38y7eq_26DqTkmYmWV9O.ehwOfDsPTAJqP3OfBqB4llMrN 12InCkm61IA4zdYGeFIEBhKad_ETz4cJll5voyGDaSifB4qeH9govOFzKLvVtcpKwzU7lYgltdbN aAvgen9qYX0csv3RVLAK6u20WdAVj3sWuFUU.6sy0.2AEvOETlVKjwC7EhnGfgvQvKEZmdQ6SQWT j0o1W2fWkTUvthQZQMuh3Y800Vt_f48HTwLR2mHpD0cFDYx9QcHgsv2kBTeNGTZNDzbbvsh38UTb E_68JEHs.1QIxUMne9rbZ4rvtk4MO53mbuKESa9AV.p2Jqbxz8z5Qty3fG6O2LfkaCXAepS7DbDy 1fwAG7wm5EKM75jjJJkU8bytGQfrEBeyttZFdu1pb6LLRj_JdSR_mrKjQSozdjPULqc0zUFLq98N pmVjIpy_RKS8QHeD_7HoXQX4HkWHUCAMRW45jozz9C1FdZfoIeYJx.kyMZ6wwcGr.DEa8vJ84PFQ fHHO4kppPDMKKNsOGzbZhm1mLA4r0ut6eHcoOBF5N_Y86U9apilXP2fwvbiD06mbMzY4EwYF6w3U XnV.1X8dNMqoBAeIBB7JANcobbS.NkqP_ratKLvzd_JPkpx5Ll0UFUpWFSGT256w31s3WPXA9HZk IPJnWCXimlRnTZhzyMajv8q9odj7meYIwVldFM4Gx9bsA09anVJjHVZtAeF4DEzfLmdc_r6CCH__ _4Q_Ge1p1ICzADhgtuC0ZzXWxizHXxE7STia2NxrHQShsKKFIOMs4qaU2WWtGQXRyAH3VTgcDMZe AETs.HEZOQJ_CuR7TmjQkE.48ZkeDcONSbuI3y2VQ8FyyS0ZC.mRuf9TrQfA3v.Wvkj5aHL1_17r BzFvsNj.c4xEgD8z7ZF2yu_NIV7kh_VDO.yPdd_gYgInUvHZoJeLGPswtQ5sYlbhtVZSPHiTwHMJ fi9f7KORRWuEjbZ9Xql3ss7F8rNAFh0Z5JzqTwCJlBLXHbG3gglY.EXZzOrdnN3YjFWZ_hvsbjyO LXw28Tq2v0sHaVCnPQBrWUnQ1OtqeRAzCvvp4tuewUZencma.GY.041Fn.yEV1ovc4u4R6FBPnWS 0t1I2DgGd7CUcVgTBlblRIA51eDxgfeWXgHv1kW.R0IbIuEFwPGqhYJIWzpdwmps2AmQFgh7Fjt2 kE24FCFB35ZhtkNMza6w1fCTHUbx4Bun.wBM_.axZlNO0NTB99yQPkrGf.LvzZWXyTbqYj6PpNHA KRvU5j2E6QNXTHcwO24mE8Zj4w.VXDonOj2LmqF7XPuMZL3ey5hqVsa1wY.FAjJj4HAROQgBDtW3 TopSgOze8C7kK9aplpOBhuQ5USRzr.vwyMw9SiCaqvn.CofbWw1hCr3BW9Sd7l254BNek1NTOun_ yaPtzl_YlI9SuduLFajmK_yjRmSoNIneXyktyBs13ZIwz.jOXttzBgklf8BmYN3Tz8tw_G.yLege msMAh5iYsMDlOBD8djdsJGJOxXW8WgHpFAEeoRFcB_ZcK3yt0OKbWX6godp7tF0wjy189cXLuz05 y8Rakc.SL7jXe3i24FSrImV9M64lXe.IV5QCcNsS1hXSsigR_GFhPzcIRfMOKpfse_ClCIppbJ2P 4X215jgQMzyVCaWG6VzOEELU2kKJDSotoPuYZbgqfr0HnVJdKppQpeCPLoxzPmYkiJ0jFHY2OZFB o8IL1E8q4.hIqtMfUJHhSHX.CXR9e5kKLLBmRowdeZxa1NGh7MhMUZzPb5ausvzUg1uLlCWri8J9 Fa0078WbhO1BB54bTvMbrTWOWnyH37LvMbFnlzq5UQ8lBN.JqWVRZ7p1BBNrn5QG5hv7ehpqdj3g dxq8LPM3crIRszLl4MWfi_AwhXhP.S4c1t.a82M3IHg9guhXdb.obrURriTuuirXfA3ra5P0dvpa jk2CS1g-- X-Sonic-MF: X-Sonic-ID: d0aaa5c8-ac33-4234-93a0-467eab0f9315 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Nov 2025 18:14:34 +0000 Received: by hermes--production-gq1-86c5846576-ngzfg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b59663b4e007d16e816470d1780f8c66; Fri, 07 Nov 2025 18:14:32 +0000 (UTC) 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: mongodb - Re: Arm v7 RPi2 -current unresponsive to debugger escape during buildworld From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <32DD797F-E5B6-4198-93D3-738C83A79AB3@gromit.dlib.vt.edu> Date: Fri, 7 Nov 2025 10:14:20 -0800 Cc: Ronald Klop , bob prohaska , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> <1993483939.9508.1762530959936@localhost> <32DD797F-E5B6-4198-93D3-738C83A79AB3@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d36f84PQhz494G On Nov 7, 2025, at 08:26, Paul Mather wrote: > On Nov 7, 2025, at 10:55=E2=80=AFam, Ronald Klop = wrote: >=20 >> Hi, >>=20 >> A bit off topic, but as maintainer of mongodb70 I can tell you that I = do my test building on a RPI4 with 8GB of memory. It has 16 GB of swap, = but that isn't used that much during my build tests. >>=20 >> I do add LDFLAGS+=3D -Wl,--threads=3D1 to the build. In my experience = the linker is using a lot of memory when multi threaded and at the end = of the mongo build you end up with 2 or 3 binaries being linked in = parallel if you are unlucky. >> You can also play with MAKE_JOBS_NUMBER=3D3 to keep it from running = to much in parallel. >> Of course limiting parallelism makes the duration longer, unless it = is swapping so much that sequential compiling without swapping is faster = than parallel building with trashing the swap space. Find the sweet = spot. >>=20 >> And yes, MongoDB is a monster to compile. >=20 >=20 > Many thanks for the MongoDB compilation tips. An extra complicating = factor in my case is I'm building via Poudriere and so the = poudriere.conf settings can confound things when it comes to controlling = resource usage. The mongodb70 port has caused me to change my = poudriere.conf settings. >=20 > Before I started building mongodb70, I had PARALLEL_JOBS=3D1; = ALLOW_MAKE_JOBS=3Dyes; TMPFS_LIMIT=3D8; MAX_MEMORY=3D5; and = USE_TMPFS=3Dall. Now, I have commented out PARALLEL_JOBS=3D1; = ALLOW_MAKE_JOBS=3Dyes; TMPFS_LIMIT=3D8; and MAX_MEMORY=3D5, and have = USE_TMPFS=3D"wrkdir data". I also added mongodb70 to TMPFS_BLACKLIST: = TMPFS_BLACKLIST=3D"rust mongodb*". >=20 > So, I went from 1 builder with multiple make jobs to multiple builders = with just 1 make job. (Before needing to build ports like rust and = mongodb70, I used to have multiple builders with multiple make jobs per = builder.) I've also dialled back a little in what TMPFS can be used = for. Usually, the system runs with 16 GB RAM and 8 GB swap on a 6-core = system. Right now, I have to add extra swap to let mongodb70 build = successfully. I suspect prior TMPFS usage is not helping matters. = Also, I don't know whether MongoDB is using a reproducible build, = because ccache doesn't seem to speed things up much for me after a = failed build. That's just a gut feeling, though. >=20 > I can echo your observation that the swap doesn't appear to be used = much for most of the build. It's just when it comes to a certain point = where everything explodes and LLVM dies from OOM. Adding extra swap has = got me past that point. The last time I did a "bulk -ca" test monitoring builder TMPFS usage for USE_TMPFS=3Dall (no blacklist), the larger usage builder runs were for: TMPFS: 39.11 GiB usr/local/ SIZE: 1.85 GiB = powerpc64le-rust-bootstrap-1.87.0 TMPFS: 38.77 GiB usr/local/ SIZE: 1.81 GiB powerpc-rust-bootstrap-1.87.0 TMPFS: 38.74 GiB usr/local/ SIZE: 1.84 GiB = powerpc64-rust-bootstrap-1.87.0 TMPFS: 38.61 GiB usr/local/ SIZE: 1.89 GiB aarch64-rust-bootstrap-1.87.0 TMPFS: 37.13 GiB usr/local/ SIZE: 1.74 GiB armv7-rust-bootstrap-1.87.0 TMPFS: 36.61 GiB usr/local/ SIZE: 1.75 GiB i386-rust-bootstrap-1.87.0 TMPFS: 35.93 GiB usr/local/ SIZE: 4.18 GiB electron35-35.6.0 TMPFS: 35.29 GiB usr/local/ SIZE: 0.32 GiB rust-nightly-1.90.0.20250624 TMPFS: 34.01 GiB usr/local/ SIZE: 0.32 GiB rust-1.87.0 TMPFS: 31.48 GiB usr/local/ SIZE: 4.43 GiB iridium-browser-2025.06.137.3 TMPFS: 31.05 GiB usr/local/ SIZE: 1.34 GiB clickhouse-22.1.3.7 TMPFS: 30.84 GiB usr/local/ SIZE: 0.35 GiB gcc-arm-embedded-14.2r1_1 TMPFS: 27.01 GiB usr/local/ SIZE: 1.51 GiB mongodb70-7.0.21_1 TMPFS: 26.35 GiB usr/local/ SIZE: 4.43 GiB = ungoogled-chromium-137.0.7151.103 TMPFS: 23.98 GiB usr/local/ SIZE: 1.89 GiB amd64-rust-bootstrap-1.87.0 TMPFS: 22.55 GiB usr/local/ SIZE: 2.53 GiB linux-ai-ml-env-1.0.0 TMPFS: 16.66 GiB usr/local/ SIZE: 2.75 GiB 0ad-0.27.0_9 TMPFS: 15.31 GiB usr/local/ SIZE: 3.48 GiB deno-2.2.9_1 TMPFS: 15.28 GiB usr/local/ SIZE: 4.08 GiB thunderbird-140.0_1 TMPFS: 14.69 GiB usr/local/ SIZE: 4.08 GiB librewolf-139.0.4 TMPFS: 14.65 GiB usr/local/ SIZE: 0.28 GiB grafana-12.0.2 TMPFS: 14.64 GiB usr/local/ SIZE: 4.14 GiB tor-browser-14.5.4 TMPFS: 14.44 GiB usr/local/ SIZE: 4.08 GiB thunderbird-esr-128.11.1 TMPFS: 13.93 GiB usr/local/ SIZE: 4.08 GiB firefox-140.0.2,2 TMPFS: 13.81 GiB usr/local/ SIZE: 4.18 GiB = gstreamer1-plugins-rust-0.13.6 TMPFS: 13.71 GiB usr/local/ SIZE: 0.67 GiB llvm-devel-21.0.d20250403 TMPFS: 13.68 GiB usr/local/ SIZE: 2.04 GiB = xtensa-esp-elf-13.2.0.20240530_8 TMPFS: 13.63 GiB usr/local/ SIZE: 3.24 GiB qt6-webengine-6.9.1 TMPFS: 13.46 GiB usr/local/ SIZE: 4.08 GiB waterfox-6.5.9_1,1 TMPFS: 13.09 GiB usr/local/ SIZE: 0.62 GiB alloy-1.6.1_3 TMPFS: 13.04 GiB usr/local/ SIZE: 4.08 GiB firefox-esr-128.12.0,1 TMPFS: 12.78 GiB usr/local/ SIZE: 0.28 GiB awslim-0.4.0 TMPFS: 12.52 GiB usr/local/ SIZE: 0.28 GiB telegraf-1.35.1 TMPFS: 12.50 GiB usr/local/ SIZE: 0.11 GiB texlive-docs-20250308 TMPFS: 12.47 GiB usr/local/ SIZE: 0.33 GiB ghc96-9.6.7 TMPFS: 12.17 GiB usr/local/ SIZE: 0.06 GiB nerd-fonts-3.3.0 TMPFS: 12.12 GiB usr/local/ SIZE: 0.33 GiB ghc94-9.4.8_1 TMPFS: 11.92 GiB usr/local/ SIZE: 0.28 GiB vault-1.19.5 TMPFS: 11.78 GiB usr/local/ SIZE: 0.33 GiB ghc92-9.2.8_1 TMPFS: 11.35 GiB usr/local/ SIZE: 0.28 GiB grafana-loki-2.9.2_13 TMPFS: 11.01 GiB usr/local/ SIZE: 3.31 GiB virtualbox-ose-71-7.1.10_1 TMPFS: 10.92 GiB usr/local/ SIZE: 0.28 GiB trivy-0.63.0_1 TMPFS: 10.38 GiB usr/local/ SIZE: 0.28 GiB vuls-0.33.1 TMPFS: 10.29 GiB usr/local/ SIZE: 0.67 GiB llvm20-20.1.6 TMPFS: 10.27 GiB usr/local/ SIZE: 0.67 GiB llvm19-19.1.7_1 TMPFS: 10.24 GiB usr/local/ SIZE: 0.67 GiB llvm18-18.1.8_2 TMPFS: 10.15 GiB usr/local/ SIZE: 1.75 GiB ringrtc-2.53.0 . . . Below 10 GiBytes omitted here . . . It was an AMD64 context. So mongod70 was a little over 27 GiBytes for TMPFS and rust was a little over 34 GiBytes. So for a bad relative timing: a little over 61 GiBytes possible contribution to TMPFS use with both building at the same time. Of course, without TMPFS use it is normal storage media use instead of RAM+SWAP. Such things have lead me use MUTUALLY_EXCLUSIVE_BUILD_PACKAGES as part of managing RAM+SWAP use/competition and/or file system space, even if TMPFS_BLACKLIST is in use for some things. (I also build some port-packages on system configurations that have no chance of being able to handle USE_TMPFS=3Dall or the like without TMPFS_BLACKLIST and such.) Also, there are some port-packages that TMPFS_BLACKLIST does not help nearly as much and so still use significant file system space when listed in TMPFS_BLACKLIST . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 7 18:44: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 4d37Jt73xrz6GMDl for ; Fri, 07 Nov 2025 18:44:46 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4d37Js4kTbz4Gq4 for ; Fri, 07 Nov 2025 18:44:45 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=fxgtyfsm; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762541071; bh=Ub+n2SfNoiDrd3y7MBMtkduL74qD4z0lalzlz75HRlM=; h=Date:From:To:Subject:In-Reply-To:References; b=fxgtyfsmjG3LLy+YSiBAWsSpN/ooVs5Z2xOKL8TesOmgb4ZsEMsFqM0PoaN26xydv HfrNN6t7QZZCiUmX7BSnYAV4An+Wh479yC4LAkdK5FvyCPHOnHX+WzV1oZitfCQZj0 VqAa2L3nUYT8Ryg+RwSZxVnB03FaWDjUZZy/NBYLSjgjClk9VIDmIlMIVCCsp+JwLg JjgT/O3AqNyexkyGdQvoCZLsZMs5TuezSyasIW/VWZ2E7QXfJsHTdTpR6jFAT/ZwVq nouy68MMJzXlI3hEC5ThXv5mjeTT60kNvO3YXn2bHccIUfgR67KJ+gsiJs09is3XsF bTcVEUI+fz4xZPfy+cyixBetSlHIh7ULsB2QZOUTFJGgKUlUwwPTkwFgel74lCBeyq VSbiIQPwJQ8b/egekCvbai+Qo7W2GTAgFkXJBKMSYdw8hdy4c1fZHCkpApfJf/gkaV EagV9FtgiMpalMiUktxU/49SVRAr+i3ZmKClkoj6xE0cBhDkZoKU8q6C0zAS78JVSk UKztflsIwnt7TU8EkVM193lNTgJQWCDLy54EWYJ9gyYmBTrB8tgqwlARg3Jud/ORD2 y1wmsXvMMXsxbY6X8vcCzrErlCgaLp0ob5fY98v5gk28P6ATM/Y3uyNsIEffiKi7ds HZuBltYTVjz4CsxgZwRIoxIM= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 3A5385B0BD4 for ; Fri, 07 Nov 2025 20:44:30 +0200 (EET) Date: Fri, 07 Nov 2025 20:44:28 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: =?US-ASCII?Q?Re=3A_Arm_v7_RPi2_-current_unresponsive?= =?US-ASCII?Q?_to_debugger_escape_during_buildworld?= User-Agent: K-9 Mail for Android In-Reply-To: References: <475995705.6919.1762440301455@localhost> <05ADBC62-E111-42F9-ACF2-3A92F2781870@yahoo.com> <8939ABFB-B315-4DFE-8CD9-296B8A117053@gromit.dlib.vt.edu> Message-ID: <84DEC7D8-395F-4813-B04B-41B35FE0681C@ketas.si.pri.ee> 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 [0.41 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4d37Js4kTbz4Gq4 i like to report that i also have a low mem machine, 4g and i recently just gave up on jobs=2E so i set ports, poudriere and build= worlds and whatevers just to 1 i have more i want to run in that machine and this is just exhausting all = the ram=2E there's also zfs which seems to mysteriously fail here if multip= le jobs happen tmpfs is also never used so idea to run 2* cores/threads doesn't always help=2E sure, if it's pure = cpu bound it helps=2E but if things start to allocate memory, in parallel, = it sucks=2E at worst it fails, at best it just keeps moving pages to disk a= nd back=2E resulting activity causes every benefit to become lost, it could= even get worse also, if you overload the cpus, where do the other tasks go? machine still= has to perform supporting tasks, read and write files, etc=2E it isn't jus= t compiling so in low power machines, not all those options make sense=2E in 3 figure = gigabyte ram machines, yes=2E machines can do >1t now too=2E there it matte= rs unfortunately i also made smaller builds slower as there is no way to dyna= mically adjust jobs depending how much it speeds up or slows down=2E eg ram= use maybe there could be dynamic option here=2E if system detects that build j= obs are likely to completely crap out the machine, it could just tune them = down=2E this also matters in some of those superservers=2E if thing is smal= l, it buils hyperfast, if big, it builds fast or normal i have no idea how to implement that=2E i just have idea From nobody Sat Nov 8 16:09: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 4d3gr514nCz6GCJN for ; Sat, 08 Nov 2025 16:10:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4d3gr30vLqz3Tg1 for ; Sat, 08 Nov 2025 16:10:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SwpkKRIx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762618209; bh=pm1LMYCxYWEEDMd8uPhuws5jV6qtJvvo0c4VITJroag=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=SwpkKRIx5S4EXGYsmNslqosQUtJG2T9wGNYWKK/ZHtYJzdeNf7KM3kDvI07xpq86HkMLc4NjmICYIt0Qs3L92NSWyawoYAUlUnS/ZtPE05r+qaNIxvylEWWvkOmjYLdyaq9pvUvgaH51WLwGdPA8HJRa9o4SaHrsjge1+QmMfUk4qQK0B/v1CkYss2N0bu5UKRf5NDxwt3ObK5VtBX71JDebG8T/rLqkdO5thJLIeq51WSyJoTZdm/GskSkN53PweI/rF78Kn2v+tijxQBvbTB2xkiNXuJSFBfMuDH/0la1q8GoYUou1mfX4BxnZBcYTnFV2dtuy+QWlRAHnMr2C9g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762618209; bh=Sl4FRBhzgDfXBGgtpbDIgZg4VX/nebtpezZH6/M9NJx=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OmPiTS0EeI90oJMzwwG7e1ZPAijFhsBeNtrYsaXwVpkpsDs1xSZbbUTLhQdWrbSYT2qaZliTVBEuiZP0GblraYiEu5VspfmP/K1DZWVO6zzGnguv46OT57OxYCYcciFmXbRNMTecDFI1xnzx+YJY4LCySataSpqroXV/pfbQ7A2cj8Ma3IyR2gUkqcdGvWqMgws9fn/s9GEEi3Rc52NRWGBXRShaTzqj63HD9G3m5AJPe8d5824dcrZDKoDttAH87nDbI29pP2FuAImJQtUrXZqBhb9Ep8CIdEo5eZmrUH4k1ZstKTsFVzfbke/ZhbaANNAAuEiCR9qDrih2pR3hAw== X-YMail-OSG: YT_pHmkVM1lXvMhyzKG5TTuy2mqgzvecmDGiRmU__BKWYBcjk3zkVy7K8rJ2yLw hIWgpZsJRhuZ_P2NHDr8ot9pkctfDn4DuZYB36_VTl745Wna3HMaUr3HIqKPCdTmJDh.WhaztDH5 HR7FMABQ9jrtCETsfrEKgktsN1V2Boh9Vh71nMF_hagSc62ZPxV.VaUESYhiz5_wo7ivYs3U612S wMbEpJ1Kzy7FryT9FNkHQNizt7e.._Cp.Ik2d6QueJpOALwFSpUC0QKmvS_daPMhbIrPeOP09dwl KoTP2dibXE906o415ePUdSfOIVH3JgDrDMW_57r1TvS2F4VCZl..aeWs6Fxx9Uh62g6PUdviMoJx Eqr9PNO8IEaqdDNtE5mrQ.dl4H8jDabP6MeGpGM.S.MsRNGSKGZJbZ0bOIJsRqqjuju34lghqPLb Jn9nmk1Dwj5O9WOT8cojYj.dryt7xymtbv43Aw3DciOZm1bNbYJCgDEOXvt7w_dnWNoiUwsRc0ws mrABs_f0a183H7_wa9gg_BNdmzLBUVGgZcp_EAr0zxn5m.dCzHWhaWkc_68pbNcXTPMLIng2efXe rl_j8E5hzc0g.YTTI2JsQusQLNyI7WP7Wluvp8q90ivzxdau18Bbf3YjK5Z68VmGZMmy5ptIeckx aD19rXa6udPCCamxevDwX.pMlxU7mWveES1yG1P7pn.rRm7yw96Xzyi5AZbuPvdTHlx2OqFgTRlE Mw4F8i2uPiAkasvBV9q8xmc9xcW9nM7rFm6M4JZ3IyUst1qfrPTGVQNLq3p9ig4p8RxodrzDFZCb RMToXkY40_jUMbVfWiCFtNnOhdSPT4n3PxcTlmnh77MkDtw62R.h.fq0Ptr1xSsXN5EWFJZ5LnjP DdnIIaVJybmDSbzhPfKsyi4_r6L0EvM3_oNRr64iEyxMw3gIz.KX07.xhBerptpMklpp0Z7lR2IW u0dLwQO3601boKuJZZ6tJeZe6VW9113813T9tJJXnRda.mMKHcRsDPI8q422Kgyk8CodvsKZgbZk 9b_ScwW9J5n7p9fvRn.YAfKutlAu4Nro.KQS2cZ7Tf2YWyLTkv07IBtkUY5FmnMearez3YFif2Aj Dg3AJeFC5tH_HjTlM8sSxxVgJzkYuK7MFA7YvXwARSiuyanfUWQqjrTAUiPDO6o6pt2zwdFEEcOn E9EjgRuQwKz3aMq7Grr.zBM62_FeeMGK4gPAEy_2gtqCuPBSMaoiuWiz.lYRN6ZytwzkZNc8Wzf_ YOaS4eEeviBTmTEi1n5zTfFZWpddaM.TXawEl.e_lzixz8zCbOcrOo0oBKQYX5BzAzVoNnGsy4hg 0ropVsrTWZwl.ZElLqfVZKayoO8ZluATumXJKYTxKMPZYm7S6QpVsr1lBR4G57lRrGFSea1UN0WH IoQl7ROF.rNZQ2A12iBrOT4X8FVeUGDt612aKg5LYnMn6tJRpAvWrcBWZmwhwou33qRAmm1vgml2 Uc3kxjhGdeFVcPVNlEpAHBtj_ObiN.ji5ykCcyCjKotGO0tzfjsyqiQem__l7It6yUR6pH4_Rg1T 1cpdG6WVi8j0GNWJFaGUp3G2CcV6rAQMXPvfWi5aOsFpYJpTqp40tVdSU4W7.Kk_2PbpszasKKJO FN.RTaVyr8_WYpKK5dbVleKO1bQ2gCa7r7b6Ue4isaCMmEjm8YzKWflXb1TpYVMFgp0IGKdqm3EH E3wAnj.H4WkjrRcNNueJppXmjNIhKBTRrIYz1eH.upBFMuGjwaoYI97fTknj2dtwcUiAxHfbWRsx 63MqjMB98UGKlx3qkkKzFiSvOwZgZMiD4M28bQlBZd9Szr3NhFpmFAnzuSYEqc5MWMBj38kBdegt DuKptDZseAf6x8nCehPgYZ1eOPX9zOvB.M9cZvu7n7MpxJQOAJo9QkKJSYWAypkeRK22vAWiPz29 ZQYihdJfeV8acaNgwPhC2kNK9Oe5JC.FqtyrulqpqIj.fVGXohoU8i8mFmwlkGoLQ0thEwoOjvVU o696iMA94b01a85.mmr4Mfv41VpNNnmTFv8Y6qpgf6dUFgTJhtSjYUhN9r_LjsYXYDcbTWeXjxyr 2f0MKpepB2ZnTY12IzPVjSTP.Xz8YtCGvgd0PbKm1Jf.PVOBx_7lbFNTy8dNTDqTxqm8.qewzCp6 RkakxfZlGkBkHvegGDtSNHzSzoXRueYNsymSK7F2LTnnAHrRIljwMB_GhQinNromqEAS.r3xe3VP M9xo.aVSmjf2z_huMhQhjYpJ4LLwzAUjRksXJ3axicxzYGukIiG6cX_vvHan6 X-Sonic-MF: X-Sonic-ID: cfa7c006-7f50-4db7-9159-5e6f76050f3f Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 8 Nov 2025 16:10:09 +0000 Received: by hermes--production-gq1-86c5846576-flz7l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID db1b414642fe53dd4b6adc11643e800a; Sat, 08 Nov 2025 16:10:05 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii 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: FYI: getopt in /usr/src/contrib/diff/lib/getopt.h vs. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/unistd.h : reported as incompatible with future C23 use Message-Id: Date: Sat, 8 Nov 2025 08:09:54 -0800 To: FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.72 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.72)[-0.715]; 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]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from] X-Rspamd-Queue-Id: 4d3gr30vLqz3Tg1 In file included from /usr/src/contrib/diff/src/diff3.c:32: /usr/src/contrib/diff/lib/getopt.h:154:12: warning: a function = declaration without a prototype is deprecated in all versions of C and = is treated as a zero-parameter prototype in C23, conflicting with a = previous declaration [-Wdeprecated-non-prototype] 154 | extern int getopt (); | ^ /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/unistd.h:384:6: note: = conflicting prototype is here 384 | int getopt(int, char * const [], const char *); | ^ =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Nov 8 18:21:22 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 4d3klj5Hn2z6GNLH for ; Sat, 08 Nov 2025 18:21:37 +0000 (UTC) (envelope-from tschweikle@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 4d3klj19YTz3pFL for ; Sat, 08 Nov 2025 18:21:37 +0000 (UTC) (envelope-from tschweikle@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=F0glGAa2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of tschweikle@gmail.com designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=tschweikle@gmail.com Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-4eda6c385c0so5779041cf.3 for ; Sat, 08 Nov 2025 10:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762626095; x=1763230895; 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=ny4BUkDN77u8gI1xsqgw4gSTIh9iv2GIdZStpFQ+HTE=; b=F0glGAa286zVV2gRtYBRI4wrlCQuOw6Z8xYVpFSREnZ0W1lPGuDnZ1lqXhr1xhvGrZ KUnPijPrrwaoplENGnlW1Hu8lUPeIOSDC5z6GNc16FPyTsAQqxvjyq+YK3XfFfyj7Fl5 qk60sCc3v6GyPCIeJmUI1deuPR+ViQeTCxfdWIPmMvqfDoPx1YSNYjZZ0IFLlTMJl8P3 V09ezLH5LHqqoOI3UPQYlxsSsvDtRVaP8eZ71bEf/KiH802taeQG4DUoLP8VNjkWE/nh lNDuCD6pVMPPQitJLYcpYgBwn7C9t1lp1hSUmeJL6SCzCZhFFADI9a5X4RH2PmZzlSh7 L1SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762626095; x=1763230895; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ny4BUkDN77u8gI1xsqgw4gSTIh9iv2GIdZStpFQ+HTE=; b=ZPwGJLxXApfmCFzDGmB/bNjqcVGSPIhykjJg3TA98pw7crvIiHuYtDnDMaafyzPzoJ QnbAsh1YnJUE9ac6xjz4Ur/XaD8sWkR54F8LFhRX38W1KC8j9ofEoWtXT5Qlrwk9MtZt Eghl9cBm/F00fxXJdMQx9VPjvIa+AdLoNTeVzqk06YvFvNAlvF1Naifdp5B1ifTCief+ +205QzHxvwc4xdp3W+da0+vGO+b90Z3tY1wLXem0I+4DrhHbkJF1SjBXsMGz3+Xm5UwV iOrx6vGBRicSpLTd9qODi7m89EoSySGiJ7skPIk5GwWet8DWRj6qQlLKw85IWTemHA7t NTMg== X-Gm-Message-State: AOJu0YwnkWvenNq4XbARSx9VDLhvALc+jziqw8DZgIl+40coSw4KNGP+ 7uBKPWWWA+hQoGv8E/6lF2NaeSLbZgNXKw9LXw3t3BUM0UeRl1F8ZmCL/EIbEABc0JezMPxjC6o iHzu41nfN3KzheChuUYvJs929tMLtHuAv3e66 X-Gm-Gg: ASbGncvBmcYeQOKQgSBHBac9GY2+uGlpYky4N2AU01cERLHVayfEVPW6d/v5XfSsViG 8T9eE7tFgBsNbKCCmhfXwm6Jdo6uq5PtuM78IsSfYsyhnOPvnUrKjS1s7+88pPFXa92tDR6m3sK r9401Va3LpG5ckkATWGE5FrmDdXvsIOzSpawneSuSLmFEVpw+SrmTgUBwHmGXup75ggI1qK4if+ OozOI66YqgbqkNGu9DhUUHRfm0VcrO6TVa7yEQ16A0Z94pzGKlHnWWesEBGM3eyWzAgdI87+VPg lL+O2Rb1ZfQjBoxwVaacv2uwT/0JSkc5z+HfQWRzpe6dTUMc4t7o7uowqtwDD7yHdam27+3V0Jw VmTk= X-Google-Smtp-Source: AGHT+IFXxYBqAjjiO2ulqEliX6fnD/Nl72/hrsU5sZMtpkUrtqC+5Qb6RVTsd/LGKnzsIBP6a2kyxcRExlF+16qKrSQ= X-Received: by 2002:ac8:5f91:0:b0:4e8:a171:b5f5 with SMTP id d75a77b69052e-4eda500b3a8mr37268451cf.82.1762626094905; Sat, 08 Nov 2025 10:21:34 -0800 (PST) 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: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> In-Reply-To: <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> From: Thomas Schweikle Date: Sat, 8 Nov 2025 19:21:22 +0100 X-Gm-Features: AWmQ_blpLk0AJk2UGFoWXFXhrJ7qbUCExRGMBHYjlX5sz5QBQpWB4M1imxFNlec Message-ID: Subject: Re: "etcupdate extract" -- Failed to build new tree. To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="0000000000004269370643195eb6" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(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:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from] X-Rspamd-Queue-Id: 4d3klj19YTz3pFL --0000000000004269370643195eb6 Content-Type: multipart/alternative; boundary="0000000000004269360643195eb4" --0000000000004269360643195eb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Looking at the log from etcupdate I found it failing with chmod 755 mk_cmds rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 et-h-ss_err.et + /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk 'outfile=3Det-h-ss_err.h' et-h-ss_err.et + /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk 'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5' 'localedir=3D' et-h-ss_er= r.et mv et-h-ss_err.h ss_err.h rm -f et-h-ss_err.et et-h-ss_err.h ./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct make[4]: exec(./mk_cmds): Permission denied *** Error code 1 Stop. make[4]: stopped making "all" in /usr/src/krb5/util/ss *** Error code 1 Stop. make[3]: stopped making "bootstrap-tools" in /usr/src 10.16 real 8.75 user 1.04 sys *** Error code 1 Stop. make[2]: stopped making "_bootstrap-tools" in /usr/src *** Error code 1 Stop. make[1]: stopped making "buildetc" in /usr/src *** Error code 1 Stop. make: stopped making "buildetc" in /usr/src It fails, because it is not allowed to "exec ./mk_cmds", after setting "chmod 0755" for "mk_cmds"? Within "/usr/src" "mk_cmds" just does not exist =E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -print" would be abl= e to find it: /usr/src # find . -iname '*/mk_cmds/*' /usr/src # "/usr/src" is mounted zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) AND what makes it even more mysterious: # cd /usr/src # make buildetc works without reporting any error. If called from "etcupdate extract" it fails. It works for FreeBSD: - stable/13 - stable/14 but not for: - stable/15 Full log is attached. On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > something bad clearly happened in that machine if it's able to selfhost > build itself and work, except etcupdate. and that for a long time > > i don't see any reason getting pissed about his machine mysteriously not > working, despite i haven't broken any machine myself since i installed > first fbsd, 4.6 > > unsure how to go from here. unsure if src.conf or make.conf matters here > > if this happens in currently actively supported fbsd release, maybe > etcupdate needs a bugfix to cleanup for edge cases > > if it's in unsupported, that should not cause any "pissages" either. fix > is somewhere > > so, the admin updated files manually because he was not able to get it > working? i bet you can recreate it and fix it for future cases > > since i haven't ever broken etcupdate, i don't know which data it uses as > input. but seems like it reads wrong data out of somewhere. and entire > machine works, except this? > > i mean if this was bad upgrade leftover, how to fix? i mean doesn't > etcupdate get rework now, for pkgbase. while we do that, maybe it could b= e > made to handle this. or maybe even given non-destructive nuke mode so > people can start clean > > i don't think it's really entirely user error, considering he didn't brea= k > the machine > > i'm curious too. at worst you could do other install in another machine > and compare dirs as something must differ there. then, according to > findings, fix the old machine. maybe while doing this, some new bugfix id= ea > appears > > but hell with getting mad over machine. he's pissed too, everyone's > pissed, server is not working and no productive work have been done here > > maybe something got lost in translation too > > --=20 Thomas --0000000000004269360643195eb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looking at the log from etcupdate I found it failing with<= div>
chmod 755 mk_cmds
rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h
cp /usr/src/crypto/k= rb5/src/util/ss/ss_err.et et-h-ss_err.et
compile_et -d /usr/src/crypto/krb5/= src/util/et --textdomain mit-krb5 et-h-ss= _err.et
+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk = 'outfile=3Det-h-ss_err.h' et-h-ss= _err.et
+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk = 'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5' 'loca= ledir=3D' et-h-ss_err.et
mv et= -h-ss_err.h ss_err.h
rm -f et-h-ss_err= .et et-h-ss_err.h
./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs= .ct
make[4]: exec(./mk_cmds): Permission denied
*** Error code 1
<= br>Stop.
make[4]: stopped making "all" in /usr/src/krb5/util/s= s
*** Error code 1

Stop.
make[3]: stopped making "bootstr= ap-tools" in /usr/src
=C2=A0 =C2=A0 =C2=A0 =C2=A010.16 real =C2=A0 = =C2=A0 =C2=A0 =C2=A0 8.75 user =C2=A0 =C2=A0 =C2=A0 =C2=A0 1.04 sys
*** = Error code 1

Stop.
make[2]: stopped making "_bootstrap-tools= " in /usr/src
*** Error code 1

Stop.
make[1]: stopped mak= ing "buildetc" in /usr/src
*** Error code 1

Stop.
ma= ke: stopped making "buildetc" in /usr/src

It fails, because it is not allowed to "exec ./mk_cmds", af= ter setting "chmod 0755" for "mk_cmds"? Within "/u= sr/src" "mk_cmds" just does not exist =E2=80=93 as long as &= quot;find /usr/src -iname '*mk_cmds*' -print" would be able to= find it:
/usr/src # find . -iname '*/mk_cmds/*'
/usr/= src #

"/usr/src" is mounted
zr= oot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
<= br>
AND what makes it even more mysterious:
# cd /usr/s= rc
# make buildetc

works without reporti= ng any error. If called from "etcupdate=C2=A0extract" it fails.

It works for FreeBSD:
- stable/13
- stable/14

but not for:
- stable/15<= /div>

Full log is attached.

O= n Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber <freebsd-current-freebsd= -org111@ketas.si.pri.ee> wrote:
something bad clearly happened in that machine if it= 's able to selfhost build itself and work, except etcupdate. and that f= or a long time

i don't see any reason getting pissed about his machine mysteriously no= t working, despite i haven't broken any machine myself since i installe= d first fbsd, 4.6

unsure how to go from here. unsure if src.conf or make.conf matters here
if this happens in currently actively supported fbsd release, maybe etcupda= te needs a bugfix to cleanup for edge cases

if it's in unsupported, that should not cause any "pissages" = either. fix is somewhere

so, the admin updated files manually because he was not able to get it work= ing? i bet you can recreate it and fix it for future cases

since i haven't ever broken etcupdate, i don't know which data it u= ses as input. but seems like it reads wrong data out of somewhere. and enti= re machine works, except this?

i mean if this was bad upgrade leftover, how to fix? i mean doesn't etc= update get rework now, for pkgbase. while we do that, maybe it could be mad= e to handle this. or maybe even given non-destructive nuke mode so people c= an start clean

i don't think it's really entirely user error, considering he didn&= #39;t break the machine

i'm curious too. at worst you could do other install in another machine= and compare dirs as something must differ there. then, according to findin= gs, fix the old machine. maybe while doing this, some new bugfix idea appea= rs

but hell with getting mad over machine. he's pissed too, everyone's= pissed, server is not working and no productive work have been done here
maybe something got lost in translation too



--
Thomas
--0000000000004269360643195eb4-- --0000000000004269370643195eb6 Content-Type: application/gzip; name="log.gz" Content-Disposition: attachment; filename="log.gz" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mhqm1tcb0 H4sICAmKD2kAA2xvZwDtXftv2zi2/t1/BZG9QHZnR1aSaTq9HbiAm6SNd/K6tjvTxWKvQEu0rbVe Q1JJ3MX+73v40MO24jip5BoNAySh+Dp8nO/jIUWR7969Q+SeU+xy5MZhiCPvLeKYjnAQdFrvIPR9 6geeH00Qp4QgzJF9i6ntjWzC3TTxMCeFy/pCLi4/py668/kUhXhGELJOr66dD72Ls8vrq9Y/TijB XOQWj/7l+XSTzOyUURuiy/+MujYOvdev2upvu/3PluuhLOwXJdQao0v4P/YD0vYj9xA5dzENPB4m rZb1VT+ySfpklDfKlCBOwiSmmM6R9JYN9bViSnWyeRwHzJZ5/4JUBU97/Zv+h8+dUpCNTs8GQwjo fGWb2tBMdkAm2J0jP2IcNAF6itXed+V6yX4MZyJXK/n6jPMK2CM/qjO7wB/ZExKHdeYpgkFJg9Qj totZQmpo2erc44REjAVNZZ9Q/1ZklrqNi/jCuFe3DOjbBrKEpNhOZhM3jsb+pAEB5J64rSBCFhtH qGZ1Z5Bfnne7XTeaRHDzEmQlcm7ZqzH3BdVkc7a3BTGKIbYhKR0z8bstUePtiAJJIfNith1poBS2 57PZNmSF2J36EdmGKJq42xBDPJ/bYHR4wZbqNWFsS1UDSTjxtyfJmdHR8ZbFbbGS26qdS+cJj213 CljDRwfbEHn/5vXerkwHpjHjFpuHgMcZa13AXzEdEL5Iiob5Ao9rNt9bNBTzuWYMJ3scpLjlJtCD Y7QS0KzQDWatKm0tc1aYx00IOmwfvkW6MykJCGZETPsTmNeN/MDnc8SmfshqnL3+grgfEkSiW9S7 Ggy7FxedPTZd1mY9z2yz6R5Cw+vri4Fz0z/70Ptch/YidNMdnteIg9ysfFu/MVxnlg2UUKvwW119 +adoDV0HhH6/7l+cDi9v6um+y+6vZx8uuh8HnT0rrCRCO5yJlSZULDWhckw2xRQMpNletia1jLSc LBG6fv+34fVNZ7+OhoMwS5ZyX+bbv74edvb/599KxH9s8P101fvtrD84c4TSn5x3e1eOVFZVaYgo qV0iAaH3kH4w7HdvbnpXHzuHxwcHxwdQ9ve/35x3B2cdjWu14nZy88k5kY2mPW56J9o1OO/2z05B wq9Od9C96kSxdJ8MP+TOi+7VR+fsM8gaLPp9uO5fdodLfp8A1NrnfHiZuy+LvPtnw5vri97VWeYx GNxkziE0fS7l0/tSiX4/6/ev+9lT7+rk4hP0U2dOWJa/82nYu1A+4HFx8dulM+z2P54Nna4qk2bQ +teuyr0rV686nc47VFJJ9GcI/1GP4uxHYLcfNcv9peHirCysreNb0IkTZMWIxjFH1gTdTQkJBHhe vXqFimT5JCOB9O3pakDkjcIqf0JplTfjFKof+IxXheJ2nFYGRA+lGPlcZVkO1NaatEXLkZVduknM mTfaKBp4bBYPe+vipdwPoOdtGJKdpYarjHpLKPjJv1YYeynQ2ROSVDeww+cJYZVdGYyFdzMre3Uo qZhti18/hOy5g5eUKAuWSvRgaKUmZYFOdFuZY6WvW+3tPZSHE+GQsAS7pCocWv+nowcCoHGrAxzx TieOHgqdkIhQ360K/iMlaWU5Qu+4ypuN0nGVv3gZUuU/jqPK5nfjiPlxZQpooSlm0wcqU5kZr/Se jaolFBBqRseFjDr0XLyFgF+1FGgzQm99l0BtceIIkwbTyeJDua5r0kaCedT/5tpAC64L7nqR0vb8 KPZWFK0Ipc3VKBNSZ5XG4pc1W+ZxjWUuVlXtEcRmxF0BdzlKMloT6pGqrixH8CmJOJ2viTLG6+Tr /2GcRg1qeklgnYObWE62R8xrlqaklLqKraQtmRFrIsAEc30MSoLYba4B9Ep6bfWnCSTPrKpmiixE 1FFcGH7B+JFDxMLqe+5orgqL8mqpzMP2v2gvnPIFY2KD6A64n5Fkw9lGOVUa+fdPSOMGi+bUI9Fh iN9sZqPjJyHYBU+UIdMkNH5yGho+JQn8OiHbdN6nUzwhNrt1nSdqCiQpx5bRlqKsTLIeyfLea9CC 0TKagJzcMCMBYJdeCTmPTZhLyfQcJUsJpYnXdt/DSStmO5snJvcNmgpaZMOcp1moySqo935N1kN6 uC4jAdiYThKkEz/aBEcqHaFcsutT0wUJDEzPSChejUHKIHxqwhn2wmPnOSJVymkcz56c0nOTOPDd +XMSPq99AMs4eG5CTp6a6qnRn1ep5O6PFAelVM0grjaoyZWSxRfbtqNcy2b4crQiVkOrBUvy6qru /ZvX21nWFIJargtFuz5CVuIn4jVvFFtqXQ68e0vVUa+zxAqNJWfSnOIEkoilHAv0cezfW2AjdbJU uaMqztdXqZNFEO1pTb50vohdktblKZT88kPbIwmJvLaXhuG8HYPXMHcy7nUmUXr4M7J+h/qOYxpi DmJpbAUkmvAp+ENPcBJaU7D5CWXgAf24EH1+NINn5ZVGKSOelWCKQ8IJFelhquJyS9iYsTSowC/0 GfOjyaJnEvsRJLEw9aVgSnhKI0sEw5OLGbcEZMF9BzGIpRaARUp253NXlnWKvfgOHBXlkBngwJ9E 4mGKqcXSEXOpn3CRR0Sgmp4FFgShkfCIAw9EzKG3POisyOd+HKlKZgVlKi/ZVfL9eVEx6FQfj2Ra N4BCiMQiUz4VcyeL4THhc5UbCRM+BzXy9LOqlgXExCyQs9CuYt2V55nr9JTGtKMjjFJuMcIXKp7H kS0wTiNXlEa2qwXlhS50BSr/T2eB6SQNSQSNIn5A9RvBHLLc6nfESjddQRFaTVv5xw3AIdx3kXqD CjoutvO3MNTRpexUeMiQNs5SIvQYFT3EQ8BRpezqfz1vm330Zh+92Udv9tGbffRmH73ZR2/20Zt9 9GYf/aZSv/d99Ej/HLRfHyGxMIcKn59eI5il0JLP0QEC4tlop3Y+V1db8NTuyP71YOCcXF/e9C7O 5DZGsdsx2+cJz7Vu7D56i4oFA1kIs4t7M6PG7OI2u7h3Zxf3CpOY7dzFdm4H6qsT5sR6+WuHI8cN CI6gp5wxZtxRC5MODC8zSZKnJCBcr/MEBKlgErk+EZu3W5fdk3NRG9nnSD853f7JufZCIN8Ri7Ly WxnW+ekIoVX+08tMMnNLFihNxGJQrUqYC22dCAmiUmny8DkUxWh28GZ5xDtYGfFAEVdGPMP8hvkN 8xvm/7bMv9Q46nMb6Lc26Ks9x66rvrfZ5mc2ZenyOxviTmMkn8ZpELzNPyiVr/OaWewvvUqAYU6/ kFv7wvH0vPubGDyvPvQ+OuflF5ALrWmdXnY/D7vvL846vashdNFn8Pr730G5YVA8Ojh6dXB48L+7 /mLSDWKWUqJeTZYezMtJ83JyB15OZpttRwJxdqaf8gVlrqwGyxrLsi8VknOnwbHB8c7hWGmnRLFW VINhjeEJ2G9TheHcaTBsMLxzGFbaKTGsFdVgWGM4wIEehjOXQbBB8M4hWCqnBLBSU4PfDL/0QMNX OQx6DXp3D72gmwq8QkkNdjV2Q+xHCryZy6DXoHfn0CuVU8JXqanBb4bfGXSrBnDmNAg2CN49BEvt VBBWimownGFYnw6mUFw8GBwbHO8ejrV+KiRnymqwrLEcpzxJuYJy4TZINkjeOSRr9ZRAzlTV4Fjj mEoYKhwXboNjg+Odw7FWT4njTFUNjjWORU3yGXLpwSDZIHnnkJzpp4RyrqwGyxrLbB5yPFJQLtwG yQbJO4dkrZ4SyJmqGhxrHN8SOoqZ3kNdejBINkjeOSRn+imhnCurwbLG8h2moOZBoMBcfjJoNmje OTTnCirhXKirwHM1nL9vNBuQGpAqkFZgtDF8QpmCH60vlARUDhTyoERBCBcNHBxnlT6gLD6Cyj6k yDZj6z2daneY3mSSvaguXnPl6+T5QlsxTc/t/MJKKBGMqJ2+OQ7K7sYJdLYVR8HcmhGSgJaM0kmp nNIlPUvRRSmyqJaFPc8C6KpncX1qp0iElrJ67GRJVnm45PHxMVI5NXC0nL1JuZo4SdCWLZQX47mH bpYau/EylrRhbWmtAIX04a5sqBObyFeO1uqLbHlelbxoTn7Xr79k3/qn2ZXF2OQuRN0bFd2RJarM Wvpa6mxKmVEDrVwSsdzW4lgSsEIcwr9lUxelWGnphy86FNVx1Li+SfRcgmjkPZVAHg5B+B7Kmwrf zYoHGCbRO1QkbbnTMPbQwc/QrSXf5ypGqe2b6PVSCZc6naVJEtNv2uO6CLK7182xhVEDU1BKxKH9 nhWBPZPbkughU7S3Xh2y6q+LWJgwvUX8lgOabZtnVn7HZh5L6wgjzAikkqsIhftZ05P1BvruGNwi mrg7JA7iie/iwJJHQVGyIP8WB6n2EWERnxJGmEXERMjPZhA6biZIlyBKQ1F8sEZZ7qljyksyZHlg aqNCwJykhDErHoMgdwaRQhKOsurkE6zcLfNXHrOICv0LY74041os9DdeB1iDeFtrnFwUyLTP0M9L oh83TDT5aJehHkM9W6EeoW+KeKTmGdp5QbQDlrS8Ulle062vu1n2MkRkiGgbRLSoeOpOm0VdNNT0 gqhJgpeVTscyZGTIaGtkpDWuOPLK0M/Lop8xnhEJAT8ax4qFVrwMGRky2gYZLSqe5KQlXTTU9IKo aRJyJ5wJwtDnDi48G1IypLQNUippnTpUsKSFho5eEB1NMZvmn8WUHgwRGSLaBhFlKidZKNc/Q0Ev iYLIvaYf5TDUY6hnK9QD6qZoR+idoZwXRDliP/7S+tCKl6EhQ0PboKFFxZOEtKSLhppeEDX9i8X6 SN3MZYjIENE2iEjqm+QfpXmGdl4Q7cyOR+lY8U7uNMRjiGcbxKMUTjKP1j1DPS+IehLM9R1cmcsQ jyGebRCP1DfJO0rzDO28JNoJ0okf6T2KpQdDPoZ8tkI+WuUU/2T6ZyjoBVEQkIDErKNPmF18NkRk iGgbRFTSOnXiZEkLDR29IDpSp0tpi6j0YIjIENE2iChTOclCuf4ZCnpBFJTy8RvFP5nLkI8hn22Q j9Q3yTxK8wztvDDacQRQCu7JHw0BGQLaFgEppctZSOugoaIXREVfsD5KSDsM/Rj62Qb9CHWTxCP1 rvVenCUqTmzU5yuLRBnsQG0ppvMWhgq6lJ0Kj1J4G+enoOlTiZaPAsk/yl/+EnbhO7TicxC1Q3t5 W6TeppTtGdDv8Iql9IWFrGI+qe27MsGqOiP03NN8rZPVJmjgWN/lAze/7emq5Nscs0l2d1gi3+eI BN3pAI7UqFR6MCOTGZmaHJnU+cpS2+TAlKue4ZzvnnPUuA3GAsMTUjpGquxl+MfwT8P8s6hzxXlS hRoaLvr+uYg7Yt6iWah4MPxj+Kdp/tHappgnU72Vybm2jCon5pnVhAv7aZnDipy/dgpcCGti+qsL Iip+2usP0NlwcNLv3QwH8PT4XUBQUnnFxurNGXUXNrsA5JHrdk5Q9S0eB7JBN9ENty0vFmmm9LmA xqsxbboa08erIerxoHJvPE+Z1l0LTRYrSz/sm95hxNTVRRQodozcTE3c5LGlRmaLyA5EbvtRkRBI F1kE7dv//yfb298wE0gkMnmnsoGnx+/3EUmfcL8PRA9njht6rLYblKobEwn1Z/JWIC1QXwkk6Crz UY0NY/nUYkwqG5hb5Ud34Wm6UXdU5ySuJCouERLXqD1mkVoWJ/fci8XNdyj0uSViLOf518X7kKA2 m5PDfpxyYQB2Fuq4X48I92ER7j7aL6rWyaoGvtJKIYCyzkopwtvFrkB5nzzaidNWO1O6DXqPew79 g7VdEIln5B+v/vkWkXvi/jnP4y9v0Q2h8lZJMLI8EvmAkx9++AGdCQsALAKwQw5brQGPk3aRB4NH ML4QeAgy2QNy2UPQsYsTCl2K9dn9VJHdCDgWrFqcKCgsZN1C6ufwoH34WlyTGKDs503752MEBhrN fQ7bB68QWNjri3BUUQRnbRnWZndYVSNhjwEbbJ7Npnn8F7QXyOUP9QAA --0000000000004269370643195eb6-- From nobody Sat Nov 8 18:51:37 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 4d3lQP0D2Rz6GQDY for ; Sat, 08 Nov 2025 18:51:41 +0000 (UTC) (envelope-from grembo@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 4d3lQN6lpWz3sPB; Sat, 08 Nov 2025 18:51:40 +0000 (UTC) (envelope-from grembo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762627901; 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=U+yNUKEBJXs8j14i12RXmCV/OMH9iGYVU9mZ5xHgpOs=; b=bt8mGJvsUTUk+gyxGT6eIWHK0wTeJXOtIxh/6BCGNhJmuuGuH3VYoLi4z6Pv1N5yNrOXZt I66dEHR0LTNK/WcasC8monyVsyJ6u0bHrVYNWJDdJcMUjRz5Z75VV4eI90nbM4pQmtKUBi v7Hrne1Ep8NWhzxORg0QSVZmV8Y2HMfcHADUm1spcCm5/WyF1T1QD10zfke+TCqDUMeEde ro6FbkZOXFt7ndMk0Z3I1AjhaZOqGVS6gdau/6anPlmfR4/FihT4ZMyNIQuQhF/LYG0qqJ oCHhUZB3QALAYtVe+5OxrAUYs6DtzbbVBgglsgLpbbBSFrh8zslLpxYUwZRx1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762627901; 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=U+yNUKEBJXs8j14i12RXmCV/OMH9iGYVU9mZ5xHgpOs=; b=YncLi9xEoK1BYdWx1bL8tLOrgpiDqebSimk7O+cV5FXoHo1tVOiHwDGr/g2vogE3I4nzQy nfdrxKzbWl1wQhLx2KvZr7ly8J+2zucZPECK4WQI41diIcqA3iJhwhQkSAieVRyN+v2Sr9 KCTsJUAQjiyZJ+FWNvS7gHj3Xm8gxL9sSBB+b68Pcj/pRA5nJCThocbaIYTyrTAORcnQ/j C3/TrJp5WqB8L+/vqrM5ZBgtk2xZLa7QbTOPCUhWxZaebYr916c4BRVOPtd5yAjeQNLllG 84500AjUUanRcRrxr/q8arObnPAmToKHee3byYD5dP2uqzIeC2nI4SoqN43f2g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762627901; a=rsa-sha256; cv=none; b=EjBcCZEBz7oRo2Jgab9a9W7U6r+k/qF18RS7zHJen7j6msITTX2qADHXTX8Aw0l26Fm1m8 DCJq3rpWH1APT7JfKMndHcjAfdf/zHvI25pMJjOuw6jwyhKEoqS92HfHh2i3BEdhwOTFnE +xGt9vOYCSE858svo1TqAYjO/cacGcQd9mmSZTrl7NFEHr6EIP1j2Z4V4BnY7dIWXxtE5P u3mGWvgas3eFrBaH5fbpJy/30DtOq+yRb8f68tBYheWqj8Zn9zU/TCaNZN/ghfbufmaMZt +LDyXj13nWIAJUFTQf5IUBT/qTm4B0oBwJ4GsJx/Ugux8UrJUhyeEBxOAtQlJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d3lQN3HzjzvXs; Sat, 08 Nov 2025 18:51:40 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 75a1a820 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 8 Nov 2025 18:51:38 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-DABFBEDC-1AA5-436B-BB43-CD6CBBDB734C Content-Transfer-Encoding: 7bit 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: "etcupdate extract" -- Failed to build new tree. From: Michael Gmelin In-Reply-To: Date: Sat, 8 Nov 2025 19:51:37 +0100 Cc: Sulev-Madis Silber , freebsd-current@freebsd.org Message-Id: <5B14C300-5375-4279-9DC6-CE88B7A84788@freebsd.org> References: To: Thomas Schweikle X-Mailer: iPhone Mail (23B85) --Apple-Mail-DABFBEDC-1AA5-436B-BB43-CD6CBBDB734C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On= 8. Nov 2025, at 19:22, Thomas Schweikle <tschweikle@gmail.com> wrote:=

=EF=BB= =BF
Looking at the log from etcupdate I found it failing wit= h

chmod 755 mk_cmds
rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h
cp /usr/src/crypto/k= rb5/src/util/ss/ss_err.et et-h-ss_err.et
compile_et -d /usr/src/crypto/krb5/sr= c/util/et --textdomain mit-krb5 et-h-ss_er= r.et
+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk 'out= file=3Det-h-ss_err.h' et-h-ss_err.et+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk 'outfile=3Det-= h-ss_err.c' 'textdomain=3Dmit-krb5' 'localedir=3D' et-h-ss_err.et
mv et-h-ss_err.h ss_err.h
rm -f et-h-ss_err.et et-h-ss_err.h
./mk_cmds /usr/s= rc/crypto/krb5/src/util/ss/std_rqs.ct
make[4]: exec(./mk_cmds): Permissio= n denied
*** Error code 1

Stop.
make[4]: stopped making "all" i= n /usr/src/krb5/util/ss
*** Error code 1

Stop.
make[3]: stopped= making "bootstrap-tools" in /usr/src
       10.16 re= al         8.75 user         1.04 sy= s
*** Error code 1

Stop.
make[2]: stopped making "_bootstrap-to= ols" in /usr/src
*** Error code 1

Stop.
make[1]: stopped making= "buildetc" in /usr/src
*** Error code 1

Stop.
make: stopped ma= king "buildetc" in /usr/src

It fails, because i= t is not allowed to "exec ./mk_cmds", after setting "chmod 0755" for "mk_cmd= s"? Within "/usr/src" "mk_cmds" just does not exist =E2=80=93 as long as "fi= nd /usr/src -iname '*mk_cmds*' -print" would be able to find it:
/= usr/src # find . -iname '*/mk_cmds/*'
/usr/src #

"/usr/src" is mounted
zroot/usr/src on /usr/src (zfs, local, noex= ec, nosuid, nfsv4acls)

Not sure if the file is in the tree or not, but your /usr/src is= mounted as noexec, so executing anything on that file system is not allowed= .

-m

= --Apple-Mail-DABFBEDC-1AA5-436B-BB43-CD6CBBDB734C-- From nobody Sat Nov 8 18:59:49 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 4d3lcF1Wx1z6GQRF for ; Sat, 08 Nov 2025 19:00:13 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4d3lcD0CmLz3wFl for ; Sat, 08 Nov 2025 19:00:11 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b="Z+zd3/6C"; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762628392; bh=osBLvt7liskv1dqHAKYqxd+QeMXudpX+IZUEC8dJvUY=; h=Date:From:To:Subject:In-Reply-To:References; b=Z+zd3/6C73u0E2LYvP/d03nWbdAx0uUjaAq29d5LGOwjusQUGTf9mqwkar3n+UG2w 0Cg6eMoQu93Jm40O6HHSiY28xHAU4e9Jk6RZieg2CY1u07zd58xP+JwgOsN6eLMPJX 9fPgFRv/c9R3GUOjeeXKwgNM9GkkMwtsb/weJye+hjT4+qAr2ZwTmv+44EZ/7ZVE3p yyXtYinDQtwHlbFxjjOdzyK+j1ZiT3SlGw5MTk6g+PToHjynMXzDoK+DlXDhkIA3YM jZF1xI6XinVovjHYA/xAlV9Krdxarg3j/jtuyTOHU4pu3Vsw1y+GCxd+UziVw+NJaP FA3bV1rgA0G2exmGS7uuNnpv8Ve0X//hFYv3o7D5XE6bvZoGJJnFfvPVAdnVuFeKv6 7EOcD+DbhNVBdthZ+6N6pE21/8QCXhtJtNalaOaIK0dWbIApHs133U2NFz6tgIuYTn xp4GjqWVM6yJMoQYZHRctcnCfa8VTe1vv22VkNEQ+AccpdYGS2zKh6eZ7EQXYEwccq 1CZNA/u2zypPFAU983mDYVkQM2aC6P1RIfMu7yRH3BJ2rZwC1exb2gbGwnwI/uh98+ OrSOLDgDvrxH/4kLnDiUwgKzaWlzN32JRyU7Qaj9EmOOW1N6z5y1NnyqYjkOp+wYuF JXYQikoSzTZppjFbQ7earAt4= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id BD4125BC228 for ; Sat, 08 Nov 2025 20:59:51 +0200 (EET) Date: Sat, 08 Nov 2025 20:59:49 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: "etcupdate extract" -- Failed to build new tree. User-Agent: K-9 Mail for Android In-Reply-To: References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> Message-ID: <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> 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 [-0.80 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; 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)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-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)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4d3lcD0CmLz3wFl first thing that comes to my mind=2E=2E=2E is there any other fs where noexec is used? especially on which the etcupdate actually runs on? i haven't so far studied the whole thing but if you have put noexec everyw= here, including tmp dirs or whatever etcupdate uses, it could be it! just a wild guess=2E noexec is not always used and it often blows up rando= m thing unexpectedly=2E others have it disabled and therefore don't see it On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle wrote: >Looking at the log from etcupdate I found it failing with > >chmod 755 mk_cmds >rm -f et-h-ss_err=2Eet et-h-ss_err=2Ec et-h-ss_err=2Eh >cp /usr/src/crypto/krb5/src/util/ss/ss_err=2Eet et-h-ss_err=2Eet >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 >et-h-ss_err=2Eet >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h=2Eawk >'outfile=3Det-h-ss_err=2Eh' et-h-ss_err=2Eet >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c=2Eawk >'outfile=3Det-h-ss_err=2Ec' 'textdomain=3Dmit-krb5' 'localedir=3D' et-h-s= s_err=2Eet >mv et-h-ss_err=2Eh ss_err=2Eh >rm -f et-h-ss_err=2Eet et-h-ss_err=2Eh >=2E/mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs=2Ect >make[4]: exec(=2E/mk_cmds): Permission denied >*** Error code 1 > >Stop=2E >make[4]: stopped making "all" in /usr/src/krb5/util/ss >*** Error code 1 > >Stop=2E >make[3]: stopped making "bootstrap-tools" in /usr/src > 10=2E16 real 8=2E75 user 1=2E04 sys >*** Error code 1 > >Stop=2E >make[2]: stopped making "_bootstrap-tools" in /usr/src >*** Error code 1 > >Stop=2E >make[1]: stopped making "buildetc" in /usr/src >*** Error code 1 > >Stop=2E >make: stopped making "buildetc" in /usr/src > >It fails, because it is not allowed to "exec =2E/mk_cmds", after setting >"chmod 0755" for "mk_cmds"? Within "/usr/src" "mk_cmds" just does not exi= st >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -print" would be a= ble to >find it: >/usr/src # find =2E -iname '*/mk_cmds/*' >/usr/src # > >"/usr/src" is mounted >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > >AND what makes it even more mysterious: ># cd /usr/src ># make buildetc > >works without reporting any error=2E If called from "etcupdate extract" i= t >fails=2E > >It works for FreeBSD: >- stable/13 >- stable/14 > >but not for: >- stable/15 > >Full log is attached=2E > >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < >freebsd-current-freebsd-org111@ketas=2Esi=2Epri=2Eee> wrote: > >> something bad clearly happened in that machine if it's able to selfhost >> build itself and work, except etcupdate=2E and that for a long time >> >> i don't see any reason getting pissed about his machine mysteriously no= t >> working, despite i haven't broken any machine myself since i installed >> first fbsd, 4=2E6 >> >> unsure how to go from here=2E unsure if src=2Econf or make=2Econf matte= rs here >> >> if this happens in currently actively supported fbsd release, maybe >> etcupdate needs a bugfix to cleanup for edge cases >> >> if it's in unsupported, that should not cause any "pissages" either=2E = fix >> is somewhere >> >> so, the admin updated files manually because he was not able to get it >> working? i bet you can recreate it and fix it for future cases >> >> since i haven't ever broken etcupdate, i don't know which data it uses = as >> input=2E but seems like it reads wrong data out of somewhere=2E and ent= ire >> machine works, except this? >> >> i mean if this was bad upgrade leftover, how to fix? i mean doesn't >> etcupdate get rework now, for pkgbase=2E while we do that, maybe it cou= ld be >> made to handle this=2E or maybe even given non-destructive nuke mode so >> people can start clean >> >> i don't think it's really entirely user error, considering he didn't br= eak >> the machine >> >> i'm curious too=2E at worst you could do other install in another machi= ne >> and compare dirs as something must differ there=2E then, according to >> findings, fix the old machine=2E maybe while doing this, some new bugfi= x idea >> appears >> >> but hell with getting mad over machine=2E he's pissed too, everyone's >> pissed, server is not working and no productive work have been done her= e >> >> maybe something got lost in translation too >> >> > From nobody Sat Nov 8 20:36: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 4d3nly2pCpz6GXy8 for ; Sat, 08 Nov 2025 20:37:02 +0000 (UTC) (envelope-from tschweikle@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 4d3nly146rz4J8x for ; Sat, 08 Nov 2025 20:37:02 +0000 (UTC) (envelope-from tschweikle@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4edb2eef810so1062311cf.0 for ; Sat, 08 Nov 2025 12:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762634216; x=1763239016; 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=I+QUvibj8npzhh/zNetpLMC5q7YGk8A7tGB6rW8zrLE=; b=eaRlXHu9k3X86CUAElfNbXSNGY1+u9Qc4c+6NfwaRSsi/hgq9gPIwz6dizW/g6Ob5r mSs8AE1s9WjR4NIYznGXRv2mitD0tY0S1MNpZNkvD6KRM/GxUCBZKZS9PCXg0H4vX+0D Tgoa95lZplO67077vytiDHYuFdZTdTgERis/ARh0QUpS8WosM57teKTWEZ8UCYYDuksV Z2RkACLXvJDXo8zIAolER8eJAx/857ndfWW/uQ6j1510rdrneZgrd/IiW/cuGHV/AUK2 SFLoNA6ttUtsLOLHqc5usFXcacqdhNnpPE3BKkOfscB5NgtUCCfHsqUftOwdw2lYycop KFHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762634216; x=1763239016; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=I+QUvibj8npzhh/zNetpLMC5q7YGk8A7tGB6rW8zrLE=; b=mCwh19dE6PaBIyM5MBkUyE5q9iNR7VdiaowiKTKo/2O8CwH8VPHjjwYQTW+NghssSg 0cnp6//CYrGPAA5fERcq+FQWi1BfuuHYykb4aUM/0WnPMf0YN2/ZJuwJCJKSWrvMDmXY lwzT2IDzJfXbfROm6zal3ZDJXFGUkeJBv2rRdWzAnpgNpbm99vQLlVR6j7N3fEoR+RN/ 8ejznDg17muHAejIQhNn0btvtP5Nb0Oyp9g5Og7JbTGftDYmyNWkRuflROuqFI+p56FI 35kHOzVEUR5saNuRHnTAJTb0x/0Pedcu/z6v8o1TMh5FKiiRcxg+6mUjLnYdHaIFxe9+ 5v6Q== X-Gm-Message-State: AOJu0Yxo/cJXe3MmzErS9hrcEeL8jsqknph0mViq/NfqzIZSmLF0h1L0 Lh21sid3lLfSNKJwXZnZ5bxe2MjZhGuV0RuHsL+h1Q+rJbt+q3fQfbkxzRqFfkfTLTsAfwheVBv Kwt2mIMnO4MArryNWcbPc0GJocazEzcVrhc+3 X-Gm-Gg: ASbGncsYEBXNQeLyKmo0RsTxM+3DFW+vIhP+iDQxpd24yQRsmORcBLrGxMoaCj4uyBn 9OnUk0gbok0oaBCzFMOZHkFVSRhH97yjZvwyhaA0eWZjxxMWvlLY2VdrExMfVDW66qaetkZZD93 snYE74+wejrt2sDpHXOA/W2NluYnDGKelJHdVx6GNel6D5czPQYIGzBvtSfGMT7t5CZlE87J3/C lv9jjrh0CbEoQFXECM50nynsRrypQFl20fccNXo43T/dCB6XrTuof6AeKw/F8kZ4OfXHSwf69gG RPJ9Lbc8a+jJyOdWRhyJlQRtqPBt/SciJv6rLLcOaMG/ X-Google-Smtp-Source: AGHT+IFYcVhmYD6ykSck0UayROYkXnGha3ADamIHLxLw09/bQeW5/SQm7cEdIl8sQv+OUsPySYoZuUWNvSegHlcPZvQ= X-Received: by 2002:a05:622a:2d5:b0:4ed:69c2:3b13 with SMTP id d75a77b69052e-4eda4e7e348mr45287781cf.9.1762634215803; Sat, 08 Nov 2025 12:36:55 -0800 (PST) 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: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> In-Reply-To: <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> From: Thomas Schweikle Date: Sat, 8 Nov 2025 21:36:43 +0100 X-Gm-Features: AWmQ_blo3oyROmZt-Dzij3mG6WkHOtHLnpk7CnFWbsjj8sPeoxFgkxiEcrwVsHo Message-ID: Subject: Re: "etcupdate extract" -- Failed to build new tree. To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004d4ceb06431b42ea" 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: 4d3nly146rz4J8x --0000000000004d4ceb06431b42ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber < freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > first thing that comes to my mind... > > is there any other fs where noexec is used? > The other systems are set up the same way, mounting /usr/src zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > especially on which the etcupdate actually runs on? > It runs on three other systems: - stable/13 - stable/14 and a pre stable/15 (before ALPHA was out and the branch done). It does not run if executed on a - stable/15 - current in both cases "make buildetc" works as expected if not called from inside "etcupdate". > i haven't so far studied the whole thing but if you have put noexec > everywhere, including tmp dirs or whatever etcupdate uses, it could be it= ! > noexec does not touch "root", but standard users. Does etcupdate switch to some other user while executing? Does it do so before branching stable/15? And just switching into /usr/src, then executing "make etcupdate" does call "./mk_cmds" and it does not fail because it is forbidden to run -- it runs. just a wild guess. noexec is not always used and it often blows up random > thing unexpectedly. others have it disabled and therefore don't see it > > > > On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < > tschweikle@gmail.com> wrote: > >Looking at the log from etcupdate I found it failing with > > > >chmod 755 mk_cmds > >rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h > >cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et > >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 > >et-h-ss_err.et > >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk > >'outfile=3Det-h-ss_err.h' et-h-ss_err.et > >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk > >'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5' 'localedir=3D' et-h-ss= _err.et > >mv et-h-ss_err.h ss_err.h > >rm -f et-h-ss_err.et et-h-ss_err.h > >./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct > >make[4]: exec(./mk_cmds): Permission denied > >*** Error code 1 > > > >Stop. > >make[4]: stopped making "all" in /usr/src/krb5/util/ss > >*** Error code 1 > > > >Stop. > >make[3]: stopped making "bootstrap-tools" in /usr/src > > 10.16 real 8.75 user 1.04 sys > >*** Error code 1 > > > >Stop. > >make[2]: stopped making "_bootstrap-tools" in /usr/src > >*** Error code 1 > > > >Stop. > >make[1]: stopped making "buildetc" in /usr/src > >*** Error code 1 > > > >Stop. > >make: stopped making "buildetc" in /usr/src > > > >It fails, because it is not allowed to "exec ./mk_cmds", after setting > >"chmod 0755" for "mk_cmds"? Within "/usr/src" "mk_cmds" just does not > exist > >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -print" would be = able to > >find it: > >/usr/src # find . -iname '*/mk_cmds/*' > >/usr/src # > > > >"/usr/src" is mounted > >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > > > >AND what makes it even more mysterious: > ># cd /usr/src > ># make buildetc > > > >works without reporting any error. If called from "etcupdate extract" it > >fails. > > > >It works for FreeBSD: > >- stable/13 > >- stable/14 > > > >but not for: > >- stable/15 > > > >Full log is attached. > > > >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < > >freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > > > >> something bad clearly happened in that machine if it's able to selfhos= t > >> build itself and work, except etcupdate. and that for a long time > >> > >> i don't see any reason getting pissed about his machine mysteriously n= ot > >> working, despite i haven't broken any machine myself since i installed > >> first fbsd, 4.6 > >> > >> unsure how to go from here. unsure if src.conf or make.conf matters he= re > >> > >> if this happens in currently actively supported fbsd release, maybe > >> etcupdate needs a bugfix to cleanup for edge cases > >> > >> if it's in unsupported, that should not cause any "pissages" either. f= ix > >> is somewhere > >> > >> so, the admin updated files manually because he was not able to get it > >> working? i bet you can recreate it and fix it for future cases > >> > >> since i haven't ever broken etcupdate, i don't know which data it uses > as > >> input. but seems like it reads wrong data out of somewhere. and entire > >> machine works, except this? > >> > >> i mean if this was bad upgrade leftover, how to fix? i mean doesn't > >> etcupdate get rework now, for pkgbase. while we do that, maybe it coul= d > be > >> made to handle this. or maybe even given non-destructive nuke mode so > >> people can start clean > >> > >> i don't think it's really entirely user error, considering he didn't > break > >> the machine > >> > >> i'm curious too. at worst you could do other install in another machin= e > >> and compare dirs as something must differ there. then, according to > >> findings, fix the old machine. maybe while doing this, some new bugfix > idea > >> appears > >> > >> but hell with getting mad over machine. he's pissed too, everyone's > >> pissed, server is not working and no productive work have been done he= re > >> > >> maybe something got lost in translation too > >> > >> > > > > --=20 Thomas --0000000000004d4ceb06431b42ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 8, = 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber <freebsd-current-freebsd-org111@ketas.= si.pri.ee> wrote:
first thing that comes to my mind...

is there any other fs where noexec is used?
The other = systems are set up the same way, mounting /usr/src
zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
=C2=A0
especially on which the etcupdate actually runs on?
It= runs on three other systems:
- stable/13
- stable/= 14
and a pre stable/15 (before ALPHA was out and the branch done)= .

It does not run if executed on a
- sta= ble/15
- current

in both cases "mak= e buildetc" works as expected if not called from inside "etcupdat= e".
=C2=A0
i haven't so far studied the whole thing but if you have put noexec eve= rywhere, including tmp dirs or whatever etcupdate uses, it could be it!
=
noexec does not touch "root", but standard user= s. Does etcupdate switch to some other user while executing? Does it do so = before branching stable/15?

And just switching int= o /usr/src, then executing "make etcupdate" does call "./mk_= cmds" and it does not fail because it is forbidden to run -- it runs.<= /div>

just a wild guess. noexec is not always used and it often blows up random t= hing unexpectedly. others have it disabled and therefore don't see it


On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle <tschweikle@gmail.com> = wrote:
>Looking at the log from etcupdate I found it failing with
>
>chmod 755 mk_cmds
>rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h
>cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et
>compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 >= et-h-ss_err.et
>+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk
>'outfile=3Det-h-ss_err.h' et-h-ss_err.et
>+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk
>'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5' '= localedir=3D' et-h-ss_err.et
>mv et-h-ss_err.h ss_err.h
>rm -f et-h-ss_err.et et-h-ss_err.h
>./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct
>make[4]: exec(./mk_cmds): Permission denied
>*** Error code 1
>
>Stop.
>make[4]: stopped making "all" in /usr/src/krb5/util/ss
>*** Error code 1
>
>Stop.
>make[3]: stopped making "bootstrap-tools" in /usr/src
>=C2=A0 =C2=A0 =C2=A0 =C2=A010.16 real=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 8.75 user=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.04 sys
>*** Error code 1
>
>Stop.
>make[2]: stopped making "_bootstrap-tools" in /usr/src
>*** Error code 1
>
>Stop.
>make[1]: stopped making "buildetc" in /usr/src
>*** Error code 1
>
>Stop.
>make: stopped making "buildetc" in /usr/src
>
>It fails, because it is not allowed to "exec ./mk_cmds", afte= r setting
>"chmod 0755" for "mk_cmds"? Within "/usr/src&q= uot; "mk_cmds" just does not exist
>=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -pr= int" would be able to
>find it:
>/usr/src # find . -iname '*/mk_cmds/*'
>/usr/src #
>
>"/usr/src" is mounted
>zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
>
>AND what makes it even more mysterious:
># cd /usr/src
># make buildetc
>
>works without reporting any error. If called from "etcupdate extra= ct" it
>fails.
>
>It works for FreeBSD:
>- stable/13
>- stable/14
>
>but not for:
>- stable/15
>
>Full log is attached.
>
>On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber <
>freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote:<= br> >
>> something bad clearly happened in that machine if it's able to= selfhost
>> build itself and work, except etcupdate. and that for a long time<= br> >>
>> i don't see any reason getting pissed about his machine myster= iously not
>> working, despite i haven't broken any machine myself since i i= nstalled
>> first fbsd, 4.6
>>
>> unsure how to go from here. unsure if src.conf or make.conf matter= s here
>>
>> if this happens in currently actively supported fbsd release, mayb= e
>> etcupdate needs a bugfix to cleanup for edge cases
>>
>> if it's in unsupported, that should not cause any "pissag= es" either. fix
>> is somewhere
>>
>> so, the admin updated files manually because he was not able to ge= t it
>> working? i bet you can recreate it and fix it for future cases
>>
>> since i haven't ever broken etcupdate, i don't know which = data it uses as
>> input. but seems like it reads wrong data out of somewhere. and en= tire
>> machine works, except this?
>>
>> i mean if this was bad upgrade leftover, how to fix? i mean doesn&= #39;t
>> etcupdate get rework now, for pkgbase. while we do that, maybe it = could be
>> made to handle this. or maybe even given non-destructive nuke mode= so
>> people can start clean
>>
>> i don't think it's really entirely user error, considering= he didn't break
>> the machine
>>
>> i'm curious too. at worst you could do other install in anothe= r machine
>> and compare dirs as something must differ there. then, according t= o
>> findings, fix the old machine. maybe while doing this, some new bu= gfix idea
>> appears
>>
>> but hell with getting mad over machine. he's pissed too, every= one's
>> pissed, server is not working and no productive work have been don= e here
>>
>> maybe something got lost in translation too
>>
>>
>



--
Thomas
--0000000000004d4ceb06431b42ea-- From nobody Sat Nov 8 23:22:37 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 4d3sRN0RH1z6FmSZ for ; Sat, 08 Nov 2025 23:22:56 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4d3sRM10HTz3L9c for ; Sat, 08 Nov 2025 23:22:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jdsOo90K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-64175dfc338so533205a12.0 for ; Sat, 08 Nov 2025 15:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762644168; x=1763248968; darn=freebsd.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=y8vlKynq7KqS4qytpyjCKyh4Hd3Hj8AImPVP7dv7Dg8=; b=jdsOo90K0rqYeaMDaXFA2kYP8331UxKecbXBUhXnjclv2PYInyHQ6BmET2XaK6OXtY 5fqi3E7NN0AO2tidfb6LM9Xwni1/v9sJfCKvP465nFkPYNchVFGLyUk9r9K+mOjFLXja OAAXEaOr1Jj7VTyTT09CO9V4bCsc0ze+e6TAquBS6XLwRx2eaG3I9vzVMFYtPJgK8new frg3ZgmccPW3XA74FqyH0dsuh6mZcRPXgKSPAj2FfQ8Ujpou0HNyXxVLIqu3PN3KpfwF vcbYJXOUYaFwjBrOGTUNyAs0EOhJYL18W4r+k2VNvBf4+BXfqGFeeMmUtIgRq1xhufKR KaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762644168; x=1763248968; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=y8vlKynq7KqS4qytpyjCKyh4Hd3Hj8AImPVP7dv7Dg8=; b=qS19mXBZywx+hSA+9DJrCzDGwwKNzdNhVbe7I0kG9UWNSkLAsYXJztKrH6E7T5SyrL sDeJVBjZVgHKl6+jmQtJV0yigVaAPwZd4Yeu7iRKSbfmKQooTW/AzJpQbXFdIIPSB/hF 0Z1pEL63npEshAb6DQbZq/S+P6afGeP0an76ZRb8/HcxjbqP5w7/Teh7G4u8ghso1j7q AYnw3tpWwiKMiz03GT2h8tNUfsAVHZ7oQGcn7k4YlAtT9Cy07XTMIOeJqBjlYM6WwBE0 1pFAAyjS4u9mglZaNVyjgQl44hDdvSo0Zd+UVxQSjEd/HUThVpLUHx62fsTVLAsp0+vH GCzw== X-Gm-Message-State: AOJu0YzUes4o8IotZwPJ5T7cHt5yq5stRKnP14ke4kdctbpc6S2hBypC UNG2Xs7MY4BvCVLcQ+mPk2JkMIatR8NBuU1UkbPAJGvduHjaQOtQHnl/Jwo5deYInCzpUwM+ely bGs7CPLoBBTTilhV1i9NRtCbZlx07AJXW8Sc= X-Gm-Gg: ASbGncvPnfvj4DncbbtycHkefzmrhNDpuRnBhKrG6ltQdXa/HhT2rKBcdkryNORQjFJ TXA7gAF1wTI46WTpB2ZB0EP5WWMhstMy/gJtgAKcyMnER9seDNR3+GjdpmhB7gEHl1njWnTGxFX mXNQ+StJDxBj5xVKPU9SPZqiHncGLeFKNbGC0XSVnednU3DtKfBvQQTKJk/f6dVK0isKZOTWm6K KRRKJjbyI5lnuB2vy3jLBH4JTPW9SaSZaDNYP7dy4/qaRDrpaan03MSiqtzHu66Lr1iXlqst8Vd mA8n73RWwxi5+Rzx0rpuy8LG5SDNBk29+c0b0w== X-Google-Smtp-Source: AGHT+IG0GrLukYKTwQM9lRw8asLySNnQqe1/6fKT58UeFdd/pUcJp5LuL6E1nOWtx6eVJmzUNiKfc/oMLsF2dJgI6sc= X-Received: by 2002:a05:6402:440a:b0:640:bb31:cbf4 with SMTP id 4fb4d7f45d1cf-6415dc0dcc6mr2723454a12.11.1762644168056; Sat, 08 Nov 2025 15:22:48 -0800 (PST) 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: Rick Macklem Date: Sat, 8 Nov 2025 15:22:37 -0800 X-Gm-Features: AWmQ_blBPWURBclXdCMfBjHw5J3da57O_CDvJjDcg1uL9Duncm8tiYTGxtWu9Fs Message-ID: Subject: RFC: Should copy_file_range(2) return after a few seconds? To: FreeBSD CURRENT Cc: "Peter 'PMc' Much" Content-Type: text/plain; charset="UTF-8" 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)[-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]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; 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]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from] X-Rspamd-Queue-Id: 4d3sRM10HTz3L9c Hi, Peter Much reported a problem on the freebsd-fs@ mailing list on Oct. 21 under the Subject: "Why does rangelock_enqueue() hang for hours?". The problem was that he had a copy_file_range(2) copying between a large NFS file and a local file that was taking 2hrs. While this copy_file_range(2) was in progress, it was holding a rangelock for the entire output file, causing another process trying to read the output file to hang, waiting for the rangelock. Since copy_file_range(2) is not any standard (just trying to emulate the Linux one), there is no definitive answer w.r.t. should it hold rangelocks. However, that is how it is currently coded and I, personally, think it is appropriate to do so. Having a copy_file_range(2) syscall take two hours is definitely an unusual case, but it does seem that it is excessive? Peter tried a quick patch I gave him that limited the copy_file_range(2) to 1sec and it fixed the problem he was observing. Which brings me to the question... Should copy_file_range(2) be time limited? And, if the answer to this is "yes", how long do you think the time limit should be? (1sec, 2-5sec or ??) Note that the longer you allow copy_file_range(2) to continue, the more efficient it will be. Thanks in advance for any comments, rick From nobody Sun Nov 9 00:42: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 4d3vD82vWtz6FtK2 for ; Sun, 09 Nov 2025 00:43:20 +0000 (UTC) (envelope-from kib@freebsd.org) 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 4d3vD54lS0z3VBM for ; Sun, 09 Nov 2025 00:43:17 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org 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 5A90gZKV024718; Sun, 9 Nov 2025 02:42:38 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5A90gZKV024718 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5A90gZa6024717; Sun, 9 Nov 2025 02:42:35 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 9 Nov 2025 02:42:35 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD CURRENT , "Peter 'PMc' Much" Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? 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=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham 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 [-1.94 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.94)[-0.937]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[kib]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4d3vD54lS0z3VBM On Sat, Nov 08, 2025 at 03:22:37PM -0800, Rick Macklem wrote: > Hi, > > Peter Much reported a problem on the freebsd-fs@ mailing > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > hang for hours?". > > The problem was that he had a copy_file_range(2) copying > between a large NFS file and a local file that was taking 2hrs. > While this copy_file_range(2) was in progress, it was holding > a rangelock for the entire output file, causing another process > trying to read the output file to hang, waiting for the rangelock. > > Since copy_file_range(2) is not any standard (just trying to > emulate the Linux one), there is no definitive answer w.r.t. > should it hold rangelocks. However, that is how it is currently > coded and I, personally, think it is appropriate to do so. > > Having a copy_file_range(2) syscall take two hours is > definitely an unusual case, but it does seem that it is > excessive? > > Peter tried a quick patch I gave him that limited the > copy_file_range(2) to 1sec and it fixed the problem > he was observing. > > Which brings me to the question... > Should copy_file_range(2) be time limited? > And, if the answer to this is "yes", how long do > you think the time limit should be? > (1sec, 2-5sec or ??) > > Note that the longer you allow copy_file_range(2) > to continue, the more efficient it will be. > > Thanks in advance for any comments, rick For me, making a syscall limited by runtime is very strange idea. IMO it should not be done. What can be done, I think, is to add signal interruption points into the copying loop. AFAIR we request a chunk to be copied, for some size of the chunk. After the copy is done, kernel could use sig_intr() to check for either interruption or suspend conditions. If non-zero is returned, you might finish the loop earlier, reporting the partial copy. From nobody Sun Nov 9 01:49:23 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 4d3whl4L1dz6Fytd for ; Sun, 09 Nov 2025 01:49:43 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4d3whj6MQnz3cv8 for ; Sun, 09 Nov 2025 01:49:41 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=WF6CVW31; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1762652965; bh=WRZ6IuhhV4CorOyuXs7VG14QGa8VN8TupAeIphjMyMA=; h=Date:From:To:Subject:In-Reply-To:References; b=WF6CVW31Q9lExnL2nOXd0XOxpHj4IZnildW4XD3Lys1sqUFB5OYnRSxlg0TkhHzex ZgPni+T+JTq/aUbTcWP2dcx76jAYo+KoHbTMqeU9lqn6NSuSzkiAkFHk05uA0vxltv guC1wax2MOd9p8q59qb4NaaQztZeZtOX/wg+8YSnmnZoKRTOrD/dGS1qCjvWs7NSdu 4+bSIzA1ui1SlJnYFr+4VuwyTbnD43E1+qxPfFwEkD7j8vtW1DkIp4K8fpRM5MlldW 2Ryz1vi/ununGshDBRrims/M4TGbWNLJO9mwX9YmmXId4KyUkTXNEXO6Fey18FSx6A ZuD5YBlS0wShtK2sgP9/ggzyVZsx5MrgcvW19I5UQ/bOLFV9Ki+KWq9ebKJ5EAsm7S X7Snol3AEtPmUBVEgflsvKb+FqwBqLxVmk+7lkoJH4b9ILV77lIB49r/02x7JoxoVU 1yIKxgEUby08gHKVWZtlXjnIlHdK5WmfNQMZvuJ3CTqBUSY8Vj8coJe3Ni9x+nItrZ fcB/4DP+rW8CTN8tYavWdQC3dJ8UXRAr48dDMfYe0RlZJurW/K6QSmspzXIHasIjtt kRGpOd7RS28/4A6dfxzUMWp1/ceRy4+smXrxMr7pCTgF5YG/iRH50bvAFpNjxx0vFi rzbijJYHIRUKJpWW13EfNYKY= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id EA0B15BFA7B for ; Sun, 09 Nov 2025 03:49:24 +0200 (EET) Date: Sun, 09 Nov 2025 03:49:23 +0200 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: "etcupdate extract" -- Failed to build new tree. User-Agent: K-9 Mail for Android In-Reply-To: References: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> 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-Spamd-Bar: / X-Spamd-Result: default: False [0.87 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_SPAM_MEDIUM(0.67)[0.671]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-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)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4d3whj6MQnz3cv8 On November 8, 2025 10:36:43 PM GMT+02:00, Thomas Schweikle wrote: >On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber < >freebsd-current-freebsd-org111@ketas=2Esi=2Epri=2Eee> wrote: > >> first thing that comes to my mind=2E=2E=2E >> >> is there any other fs where noexec is used? >> >The other systems are set up the same way, mounting /usr/src >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > > >> especially on which the etcupdate actually runs on? >> >It runs on three other systems: >- stable/13 >- stable/14 >and a pre stable/15 (before ALPHA was out and the branch done)=2E > >It does not run if executed on a >- stable/15 >- current > >in both cases "make buildetc" works as expected if not called from inside >"etcupdate"=2E > > >> i haven't so far studied the whole thing but if you have put noexec >> everywhere, including tmp dirs or whatever etcupdate uses, it could be = it! >> >noexec does not touch "root", but standard users=2E Does etcupdate switch= to >some other user while executing? Does it do so before branching stable/15= ? unfortunately noexec don't even let root execute anything directly read works, shell scripts, makefiles if you have other fses in that very same machine mounted noexec then this = code will fail=2E and it indeed does give permission denied i don't know where mk_cmds is=2E perhaps in obj? i'm currently not debuggi= ng this whether it should be able to run noexec, no idea, not everything can be noexec is there by purpose i assume, but maybe it could be temporary disab= led btw noexec as a security measure can be also bypassed tell us if disabling noexec on fses helped that's also fun thing, that not many add, or if they do, they know what ha= ppens=2E many building type tasks like to execute something in dirs you didn't tell that you had noexec on and nobody asked either so maybe it= 's noexec for all that time and you had to do manual work i hope it's fixed now!!! > >And just switching into /usr/src, then executing "make etcupdate" does ca= ll >"=2E/mk_cmds" and it does not fail because it is forbidden to run -- it r= uns=2E > >just a wild guess=2E noexec is not always used and it often blows up rand= om >> thing unexpectedly=2E others have it disabled and therefore don't see i= t >> >> >> >> On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < >> tschweikle@gmail=2Ecom> wrote: >> >Looking at the log from etcupdate I found it failing with >> > >> >chmod 755 mk_cmds >> >rm -f et-h-ss_err=2Eet et-h-ss_err=2Ec et-h-ss_err=2Eh >> >cp /usr/src/crypto/krb5/src/util/ss/ss_err=2Eet et-h-ss_err=2Eet >> >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 >> >et-h-ss_err=2Eet >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h=2Eawk >> >'outfile=3Det-h-ss_err=2Eh' et-h-ss_err=2Eet >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c=2Eawk >> >'outfile=3Det-h-ss_err=2Ec' 'textdomain=3Dmit-krb5' 'localedir=3D' et-= h-ss_err=2Eet >> >mv et-h-ss_err=2Eh ss_err=2Eh >> >rm -f et-h-ss_err=2Eet et-h-ss_err=2Eh >> >=2E/mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs=2Ect >> >make[4]: exec(=2E/mk_cmds): Permission denied >> >*** Error code 1 >> > >> >Stop=2E >> >make[4]: stopped making "all" in /usr/src/krb5/util/ss >> >*** Error code 1 >> > >> >Stop=2E >> >make[3]: stopped making "bootstrap-tools" in /usr/src >> > 10=2E16 real 8=2E75 user 1=2E04 sys >> >*** Error code 1 >> > >> >Stop=2E >> >make[2]: stopped making "_bootstrap-tools" in /usr/src >> >*** Error code 1 >> > >> >Stop=2E >> >make[1]: stopped making "buildetc" in /usr/src >> >*** Error code 1 >> > >> >Stop=2E >> >make: stopped making "buildetc" in /usr/src >> > >> >It fails, because it is not allowed to "exec =2E/mk_cmds", after setti= ng >> >"chmod 0755" for "mk_cmds"? Within "/usr/src" "mk_cmds" just does not >> exist >> >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -print" would b= e able to >> >find it: >> >/usr/src # find =2E -iname '*/mk_cmds/*' >> >/usr/src # >> > >> >"/usr/src" is mounted >> >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) >> > >> >AND what makes it even more mysterious: >> ># cd /usr/src >> ># make buildetc >> > >> >works without reporting any error=2E If called from "etcupdate extract= " it >> >fails=2E >> > >> >It works for FreeBSD: >> >- stable/13 >> >- stable/14 >> > >> >but not for: >> >- stable/15 >> > >> >Full log is attached=2E >> > >> >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < >> >freebsd-current-freebsd-org111@ketas=2Esi=2Epri=2Eee> wrote: >> > >> >> something bad clearly happened in that machine if it's able to selfh= ost >> >> build itself and work, except etcupdate=2E and that for a long time >> >> >> >> i don't see any reason getting pissed about his machine mysteriously= not >> >> working, despite i haven't broken any machine myself since i install= ed >> >> first fbsd, 4=2E6 >> >> >> >> unsure how to go from here=2E unsure if src=2Econf or make=2Econf ma= tters here >> >> >> >> if this happens in currently actively supported fbsd release, maybe >> >> etcupdate needs a bugfix to cleanup for edge cases >> >> >> >> if it's in unsupported, that should not cause any "pissages" either= =2E fix >> >> is somewhere >> >> >> >> so, the admin updated files manually because he was not able to get = it >> >> working? i bet you can recreate it and fix it for future cases >> >> >> >> since i haven't ever broken etcupdate, i don't know which data it us= es >> as >> >> input=2E but seems like it reads wrong data out of somewhere=2E and = entire >> >> machine works, except this? >> >> >> >> i mean if this was bad upgrade leftover, how to fix? i mean doesn't >> >> etcupdate get rework now, for pkgbase=2E while we do that, maybe it = could >> be >> >> made to handle this=2E or maybe even given non-destructive nuke mode= so >> >> people can start clean >> >> >> >> i don't think it's really entirely user error, considering he didn't >> break >> >> the machine >> >> >> >> i'm curious too=2E at worst you could do other install in another ma= chine >> >> and compare dirs as something must differ there=2E then, according t= o >> >> findings, fix the old machine=2E maybe while doing this, some new bu= gfix >> idea >> >> appears >> >> >> >> but hell with getting mad over machine=2E he's pissed too, everyone'= s >> >> pissed, server is not working and no productive work have been done = here >> >> >> >> maybe something got lost in translation too >> >> >> >> >> > >> >> > From nobody Sun Nov 9 01:55: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 4d3wqm3kN2z6G0Tk for ; Sun, 09 Nov 2025 01:55:48 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resdmta-c2p-566137.sys.comcast.net (resdmta-c2p-566137.sys.comcast.net [IPv6:2001:558:fd00:56::c]) (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 4d3wql5VN7z3gKv for ; Sun, 09 Nov 2025 01:55:47 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b=lvzwJjCe; dmarc=pass (policy=reject) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of kargls@comcast.net designates 2001:558:fd00:56::c as permitted sender) smtp.mailfrom=kargls@comcast.net Received: from resomta-c2p-555442.sys.comcast.net ([96.102.18.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resdmta-c2p-566137.sys.comcast.net with ESMTPS id HuISvI0GttIe4HuebvHtYa; Sun, 09 Nov 2025 01:55:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1762653341; bh=AzMNaoetZ6Wg7M1ZD1tdn2gnuKB8svTnwIEp/2wxtW0=; h=Received:Received:Message-ID:Date:MIME-Version:To:From:Subject: Content-Type:Xfinity-Spam-Result; b=lvzwJjCePwerNW48Fd+OYNHpssoSHzR9y+tOgXECLIXQDx4WIXlMORKl7uayG5uP8 yMYiuG+RS1L/mRLzTXvgFjqXj3xuYxcg7Wa7lZWcm1KVJ8VF7Gr+53NCob1vy6jDWd V3c+nlPg8JcL5CYBVxZOot3kJpgJ0RLB7dVljvs6i54gAv9ksKRb8JPocHMy+T5dRM u30xnryveGjkMWDTfQRPxkE4MOkMtFCSozhc2+pdTzcydVCthzrOCxH69JB8MOj2ax 2iKsYUhg1i/1MalAbrkrOc/Koa8ZfYDmXPERNPO6AoOTWDpm4h1bsexPOnpe2TOgG0 dLGthOF40gEMg== Received: from [10.0.0.30] ([73.83.213.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-c2p-555442.sys.comcast.net with ESMTPSA id HueavEX6CB5zeHueavjSaW; Sun, 09 Nov 2025 01:55:40 +0000 Message-ID: Date: Sat, 8 Nov 2025 17:55:40 -0800 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 From: Steve Kargl Subject: Backout git revision 4179e6b78297369f Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfHwgQ8PaYY+O/MvRU/7mtMy6SfR1CziFYbDewU5iCYrkwmjIPUjMwi89tLGD8ZXH07oJFRQYAHRZ5JkqLlEQ5E4ceXtaUZqJh/rOplrB6m++t27RHq4y czu+RfuX9Zjfd1uFxzXcgE/wRMCppP6SIUa2NXLSm6h5QEXLFhOLH5ezBTmJb7XgYSwmTqkMd0WOKA== X-Spamd-Bar: / X-Spamd-Result: default: False [-0.87 / 15.00]; HFILTER_HELO_5(3.00)[resdmta-c2p-566137.sys.comcast.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fd00:56::/64]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[comcast.net:dkim]; FREEMAIL_FROM(0.00)[comcast.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[comcast.net:+]; FREEMAIL_ENVFROM(0.00)[comcast.net]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; RCVD_IN_DNSWL_NONE(0.00)[96.102.18.241:received] X-Rspamd-Queue-Id: 4d3wql5VN7z3gKv Can someone back out the git commit 4179e6b78297369f? This is causing pkg-fallout@ to spam the freebsd-x11 mailing list. It seems no one reads replies to pkg-fallout. See for detail https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290432 -- steve From nobody Sun Nov 9 02:09:15 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 4d3x7f0L2bz6G1m6 for ; Sun, 09 Nov 2025 02:09:34 +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 4d3x7d5YgMz3hV4 for ; Sun, 09 Nov 2025 02:09:33 +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-6407e617ad4so3246394a12.0 for ; Sat, 08 Nov 2025 18:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762654167; x=1763258967; 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=uKJagq//uHmn5zXDLtOHMNYzzwZdJfI2JThImECbdPE=; b=bTEcdTILnFOhB4sjn8OzxeZ6fSsMZO7T8a4YKiSk+ABDkHDEANy0tkTNhmKFl6wllK Ry9A/G6I63YDEcphCsE5QBcuKAfmv43e0GnpQyp6uRWzLWVJXc4ryTOpP75AKfRbEvIX g2/BFNCWZBWnS41eiLBOnijuBO+NozeF9Bvg4fCexgrULMft8JZ4lz7yYUdIkebTCh5t 6LRq6/8efb2VPWhdW9FIHyJYDSFldBM0PsBMU6dJM4pWhupB8GESmEeYudya9zx/lnac QZ1SNkZeTlJrGtyGlifNlYlygnHpdN2JRffFi4Z4rIO8CssE1RPKLftF9EOIKsWJaWdj aXGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762654167; x=1763258967; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uKJagq//uHmn5zXDLtOHMNYzzwZdJfI2JThImECbdPE=; b=H/eggWmOU9XEFkeuIByWmXPZUsHAVeTn6leJScZsc8E+HFvHVU8OwUfw9ooflK5yDv TuNK4i6NXCGBjQGf/aZ3Gq9EY0vmDahGc/bxWlc6HiD1eTA09yvZ0RBtoX6EWMJtRH6+ eDfkZiOsMOfi/WZ/730IjqrEFAofaomXrYclpZToTf1NYlb/njWxofT3YtgNppXpw8Ib XiYBMJ0TiAZ6x5nf9vNZZ59UdOKP3B3g17VCnKeTajgA/ZQNYYdcIGYMCbyed0n+uTpW nScykOXOzARVoY974+AyozgP+cS456pllwF7dmmlcYTmgHfDpYZ55k0t1efuhrjeNwRK gHYg== X-Gm-Message-State: AOJu0YwlQNxOz+5vs35c9aZPWZ6YcydziovwVoi/3GpLCuVmXCBmdPjo 6Xiq5ZlpFHax5CTaJ3VVQ635NLXb7DCL0DejCg3pLRTuoArt+S5rVdtOLSacb4wuefZeTnCmWIV cggXG7cTxsAKFORgmF7wVHhgvQ4otNQ== X-Gm-Gg: ASbGncuoe6ogQagjcReB/cxHACsMePFaVTvtYpQ+35ExfY6h0iXXal6N8hp+UyEyJXn DEYF3s2clHCv2wKmLkvInJw+khpFi/7cECIH+R+5U36/J5Yfki9IrO5FkPMiYkUSXrBBU6d5tRH mC2X7uTN47ZVecR2ivkGzqXapp/ckQ94T211j6KdV6Q5Hgdz8/4LoeqDYLX0a2AFGgccArDuRUu x65/DoM3p+5Y5CCN4squgk082pZ3nF20vh5M2gGdyuL2V82drPe1JhkeHMaVuufWFAK8WXO4pLQ CB+dVEGTlJhovFxs X-Google-Smtp-Source: AGHT+IGBB2K+Uq5Ryg36qlyet5qn2m31W3R+Ioz5t0XgFWkLWbKHB7hTo3lcVGaAIT/ttpFZWTCPf0G06umMOJyayl4= X-Received: by 2002:a05:6402:1d54:b0:641:270:2c8a with SMTP id 4fb4d7f45d1cf-6415a27829bmr3689433a12.14.1762654166989; Sat, 08 Nov 2025 18:09:26 -0800 (PST) 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: Rick Macklem Date: Sat, 8 Nov 2025 18:09:15 -0800 X-Gm-Features: AWmQ_bmpfQ7gKgwGw5RUQGbtMSqhLp5pv1CyPGIi05IcF7uvJtQnM_IXLPJLjRw Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Konstantin Belousov Cc: FreeBSD CURRENT , "Peter 'PMc' Much" 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: 4d3x7d5YgMz3hV4 On Sat, Nov 8, 2025 at 4:43=E2=80=AFPM Konstantin Belousov wrote: > > On Sat, Nov 08, 2025 at 03:22:37PM -0800, Rick Macklem wrote: > > Hi, > > > > Peter Much reported a problem on the freebsd-fs@ mailing > > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > > hang for hours?". > > > > The problem was that he had a copy_file_range(2) copying > > between a large NFS file and a local file that was taking 2hrs. > > While this copy_file_range(2) was in progress, it was holding > > a rangelock for the entire output file, causing another process > > trying to read the output file to hang, waiting for the rangelock. > > > > Since copy_file_range(2) is not any standard (just trying to > > emulate the Linux one), there is no definitive answer w.r.t. > > should it hold rangelocks. However, that is how it is currently > > coded and I, personally, think it is appropriate to do so. > > > > Having a copy_file_range(2) syscall take two hours is > > definitely an unusual case, but it does seem that it is > > excessive? > > > > Peter tried a quick patch I gave him that limited the > > copy_file_range(2) to 1sec and it fixed the problem > > he was observing. > > > > Which brings me to the question... > > Should copy_file_range(2) be time limited? > > And, if the answer to this is "yes", how long do > > you think the time limit should be? > > (1sec, 2-5sec or ??) > > > > Note that the longer you allow copy_file_range(2) > > to continue, the more efficient it will be. > > > > Thanks in advance for any comments, rick > > For me, making a syscall limited by runtime is very strange idea. > IMO it should not be done. > > What can be done, I think, is to add signal interruption points into > the copying loop. AFAIR we request a chunk to be copied, for some > size of the chunk. After the copy is done, kernel could use > sig_intr() to check for either interruption or suspend conditions. > If non-zero is returned, you might finish the loop earlier, reporting > the partial copy. > It already interrupts when a signal like C is posted. The reporter didn't want the copy (he was actually using "cat") to terminate. He wanted to read the output file when it was only partially copied, which doesn't work because of the rangelock. (It appears it does work on Linux.) A partial copy_file_range() is normal and an NFSv4.2 server will return a partial copy after 1sec or so since there is a general understanding (not wired down in any RFC) that an RPC should always reply in 1-2sec. rick From nobody Sun Nov 9 03:40:25 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 4d3z990xmqz6G7x7 for ; Sun, 09 Nov 2025 03:41:01 +0000 (UTC) (envelope-from kib@freebsd.org) 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 4d3z9828Qbz3qpl for ; Sun, 09 Nov 2025 03:41:00 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org 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 5A93eQX6032994; Sun, 9 Nov 2025 05:40:29 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5A93eQX6032994 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5A93ePhb032993; Sun, 9 Nov 2025 05:40:25 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 9 Nov 2025 05:40:25 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD CURRENT , "Peter 'PMc' Much" Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham 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 [-2.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; HAS_XAW(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEFALL_USER(0.00)[kib]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4d3z9828Qbz3qpl On Sat, Nov 08, 2025 at 06:09:15PM -0800, Rick Macklem wrote: > On Sat, Nov 8, 2025 at 4:43 PM Konstantin Belousov wrote: > > > > On Sat, Nov 08, 2025 at 03:22:37PM -0800, Rick Macklem wrote: > > > Hi, > > > > > > Peter Much reported a problem on the freebsd-fs@ mailing > > > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > > > hang for hours?". > > > > > > The problem was that he had a copy_file_range(2) copying > > > between a large NFS file and a local file that was taking 2hrs. > > > While this copy_file_range(2) was in progress, it was holding > > > a rangelock for the entire output file, causing another process > > > trying to read the output file to hang, waiting for the rangelock. > > > > > > Since copy_file_range(2) is not any standard (just trying to > > > emulate the Linux one), there is no definitive answer w.r.t. > > > should it hold rangelocks. However, that is how it is currently > > > coded and I, personally, think it is appropriate to do so. > > > > > > Having a copy_file_range(2) syscall take two hours is > > > definitely an unusual case, but it does seem that it is > > > excessive? > > > > > > Peter tried a quick patch I gave him that limited the > > > copy_file_range(2) to 1sec and it fixed the problem > > > he was observing. > > > > > > Which brings me to the question... > > > Should copy_file_range(2) be time limited? > > > And, if the answer to this is "yes", how long do > > > you think the time limit should be? > > > (1sec, 2-5sec or ??) > > > > > > Note that the longer you allow copy_file_range(2) > > > to continue, the more efficient it will be. > > > > > > Thanks in advance for any comments, rick > > > > For me, making a syscall limited by runtime is very strange idea. > > IMO it should not be done. > > > > What can be done, I think, is to add signal interruption points into > > the copying loop. AFAIR we request a chunk to be copied, for some > > size of the chunk. After the copy is done, kernel could use > > sig_intr() to check for either interruption or suspend conditions. > > If non-zero is returned, you might finish the loop earlier, reporting > > the partial copy. > > > It already interrupts when a signal like C is posted. > > The reporter didn't want the copy (he was actually using "cat") > to terminate. He wanted to read the output file when it was > only partially copied, which doesn't work because of the > rangelock. (It appears it does work on Linux.) Apps can install timer which would generate SIGALRM after 1 or 2 secs. Then the syscall is interrupted and partial copy is reported. > > A partial copy_file_range() is normal and an NFSv4.2 server > will return a partial copy after 1sec or so since there is a > general understanding (not wired down in any RFC) that > an RPC should always reply in 1-2sec. > > rick From nobody Sun Nov 9 04:06: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 4d3zkS6sXqz6G9gF for ; Sun, 09 Nov 2025 04:06:24 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4d3zkS467zz3vbY for ; Sun, 09 Nov 2025 04:06:24 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64149f78c0dso2258497a12.3 for ; Sat, 08 Nov 2025 20:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762661178; x=1763265978; 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=oa7c+lUYNhgANcruC5Ks071uHd5oLrCUzNXCtaebTxg=; b=HeJKn1PIfz6EdJzB9zk0H2zgEzC8DWU6CMF/N37Lt1zCqBmEam6kQo78EZsykgin37 D1vBxAQ8dwSAGlYNSeUORg8rzxlOejnuAdS+8JaVesv/+Idu+CWbzsyHElzgU8owYexm Y62/H0mv9rO/H1+NI9+sMAl/5eXdvRY7DKy6f5JdgaDH7ij0rpS423LKA4MQ3JtLFYRh ocSPVQrVQHA6UszSA2ub2uKYGBrErekVypHQc9EMVSYpKa99CeBz6rSc8oMfzfarz4Ku dyj+rfIuKJTqnjWFZ7KJBVidADZ8QQPN5cJ9geZSff7nnq1/6c7Oh0+fkmkAwVOVByqO DmPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762661178; x=1763265978; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oa7c+lUYNhgANcruC5Ks071uHd5oLrCUzNXCtaebTxg=; b=aeju0r0reILeOjIMdid+UHYAwGjv0BGZuJj4un7RNzHOtFaWwYyw4Bcj5+xZUnKlt/ w6jLvaOoW4TQD1Zo9Fp+87jCgPdnUzC6jn03sfyrkL8+1qYP+T2TxzXco1re+JAE0Wkl ym8rMpBJYFsHNe+bTgvuvky853cK52Abzt/XzoLigdtn7HXHin3mZ5uOC1v5DZgqDWjI 5aWWruu4Rzq069Rj4DlivH6aClwqu6YdgEhP6/4e93JZnxHyTiszbj6fat9D7oN0Y44m Fs2U9VVJ3+qMn5I/TYED1kOnJamvvq1ICMMZQb0K52RuPndAPTfAcPCerZAsTyoPwCEd 1ACw== X-Gm-Message-State: AOJu0YzLZEcA1vM/eyIzzXf2YXvSkbY4J3q0kcC5NVeebPif/trjSw2e txyxzMxApdu2ZC+gTlR5p4DsGPR3B8NP0HiHkEno/x5nTPZsW9ngnYOfw7Zqfc63qe6xcrCoH8B OOYO3aQ8ymL6VRO5cruKwtmEYRHB4TQ== X-Gm-Gg: ASbGncv4nugm9gtp+JibY7k21LHjwqfiFtamaK86d1YMw1LWVVAApOARuupqq3zufae LcLsE0Fh7M3Q7/+LSJ39e0NKiWg4cRgWQE0j7suSCsOglJWNQ00sqv7VhK6PyS7Mvu4INNH8Pt9 Svi49kVlVTMSrZJfN3pGm3LA0TJAI/1u378mOtr+OdpLK0OMJXfj1Pj5gN5dxXCGD33kGQ93phY jXGD9oXkjF6BETYT2xdbEsMXROIntpcWMIl/QJNcv+nlX0A5/sAevQiIfusGgD1t636VZbTULqt +78Vhu96RVrm9Gtfeb/9cIhceFkdoJVJEpNbig== X-Google-Smtp-Source: AGHT+IEYhZmykYcbYK4D2di+hQ66CQ81K7N3CNI9AeR7cCM0d9ivB7xvf46KqIJpyy5F3xFkRyUH06BKj/+FwoueTk4= X-Received: by 2002:a05:6402:4559:b0:63e:6511:4186 with SMTP id 4fb4d7f45d1cf-6415ea4e7cdmr3569290a12.37.1762661178036; Sat, 08 Nov 2025 20:06:18 -0800 (PST) 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: Rick Macklem Date: Sat, 8 Nov 2025 20:06:06 -0800 X-Gm-Features: AWmQ_bmcbiPMYf6BUed96V7ToK-vmBOpKGbPn3Fjdgjykn-tuO5Rx7a9MyjsxME Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Konstantin Belousov Cc: FreeBSD CURRENT , "Peter 'PMc' Much" 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d3zkS467zz3vbY On Sat, Nov 8, 2025 at 7:41=E2=80=AFPM Konstantin Belousov wrote: > > On Sat, Nov 08, 2025 at 06:09:15PM -0800, Rick Macklem wrote: > > On Sat, Nov 8, 2025 at 4:43=E2=80=AFPM Konstantin Belousov wrote: > > > > > > On Sat, Nov 08, 2025 at 03:22:37PM -0800, Rick Macklem wrote: > > > > Hi, > > > > > > > > Peter Much reported a problem on the freebsd-fs@ mailing > > > > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > > > > hang for hours?". > > > > > > > > The problem was that he had a copy_file_range(2) copying > > > > between a large NFS file and a local file that was taking 2hrs. > > > > While this copy_file_range(2) was in progress, it was holding > > > > a rangelock for the entire output file, causing another process > > > > trying to read the output file to hang, waiting for the rangelock. > > > > > > > > Since copy_file_range(2) is not any standard (just trying to > > > > emulate the Linux one), there is no definitive answer w.r.t. > > > > should it hold rangelocks. However, that is how it is currently > > > > coded and I, personally, think it is appropriate to do so. > > > > > > > > Having a copy_file_range(2) syscall take two hours is > > > > definitely an unusual case, but it does seem that it is > > > > excessive? > > > > > > > > Peter tried a quick patch I gave him that limited the > > > > copy_file_range(2) to 1sec and it fixed the problem > > > > he was observing. > > > > > > > > Which brings me to the question... > > > > Should copy_file_range(2) be time limited? > > > > And, if the answer to this is "yes", how long do > > > > you think the time limit should be? > > > > (1sec, 2-5sec or ??) > > > > > > > > Note that the longer you allow copy_file_range(2) > > > > to continue, the more efficient it will be. > > > > > > > > Thanks in advance for any comments, rick > > > > > > For me, making a syscall limited by runtime is very strange idea. > > > IMO it should not be done. > > > > > > What can be done, I think, is to add signal interruption points into > > > the copying loop. AFAIR we request a chunk to be copied, for some > > > size of the chunk. After the copy is done, kernel could use > > > sig_intr() to check for either interruption or suspend conditions. > > > If non-zero is returned, you might finish the loop earlier, reporting > > > the partial copy. > > > > > It already interrupts when a signal like C is posted. > > > > The reporter didn't want the copy (he was actually using "cat") > > to terminate. He wanted to read the output file when it was > > only partially copied, which doesn't work because of the > > rangelock. (It appears it does work on Linux.) > Apps can install timer which would generate SIGALRM after 1 or 2 secs. > Then the syscall is interrupted and partial copy is reported. Yep, although in Peter's case it was just "ca(1)t". Also, the timeout coul= d be enabled via a flag in the flag argument to copy_file_range(2). That is probably simpler than a SIGALRM. (The current 1sec timeout flag for the NFS server is "in kernel only", but it's easy to expose it to the syscall. rick > > > > > A partial copy_file_range() is normal and an NFSv4.2 server > > will return a partial copy after 1sec or so since there is a > > general understanding (not wired down in any RFC) that > > an RPC should always reply in 1-2sec. > > > > rick > From nobody Sun Nov 9 04:26: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 4d409p6BjGz6GC2d for ; Sun, 09 Nov 2025 04:26:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4d409p4W7Jz3xZK for ; Sun, 09 Nov 2025 04:26:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="PF9LRP/r"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762662392; bh=/Moffev79vTmKwV4lR1jlu/Du0gs60gz2KOtPylaEF0=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=PF9LRP/rftvgHK+YcHuf+Hj0yboZbH4Ko5AWA6rfo48VifKVLTax2ZRqHEPjJqcn1eWUmOWF16Y0+HERXuqlHl6+oVMNY5R+UxFmfjXRFHXxuBNhJMyxBtWjbR9mV8v9cgsdvHKQliSCmbxwN6b9L56MeVeBHJ7kiYOcvKG62RXAv8Bc9lWeIzRNgoBK7kXwj9/dYh7+dGyQtotoLdDSi/NygphLkQRSJxQ93sHPt/Rb+9/5zW7i+NU2Gw9+bD7y7+0GrhTmBmMuoQ/JTIjDTVkoItVZ/eBPm1RoGNXhznhweoBIbikSiNaeKJsB/QinIoD6UE0M5IvWJH1uLEw4XQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762662392; bh=XmtEFBxv9SxRC388KbSCFmiVNbRE9iBtKc0KVs1r+b0=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=dmXME0ySCYT/raYcBQGYXhmBwSYDd/91KSeGh4K+2w4WEkQj9ZzNuvl8Lz7W7W58d7cBcCElKbxBsoSUQSOzzla7gKM+5uMlpxETV0R2Y7nN1jrJ6aiBuuQSH0HYyIqliCwQIT4/zLrqXoVvtc36QdSVVWjd8AGoLg8Yc8iijKKVrIBRVCSLSkZ2/j+PCCbDoVm7s2NHpeoCIjzB1iXANArCsOioGfu21m6PpGXUXqNoJBSonPt5dwglF9TL9P+RG7P6mWHKfWk7YaiVuaXRc+63e3yD/teTRmMOq3izuwb+DZwI1kM+EC0QkD/0py/pt3z584Bpf++2E0mvFjvLoA== X-YMail-OSG: boOpCz0VM1l3qqlbmJJMmgo0hZ7oSYl0uRZB0ZR6.DLkuhJJMSxunZPpOnsB0bF H5pVjuow7HRELc9E9P6bn95RvlMYpN8Qemy2PtQ.TWO9juzzlDIYf.RAnUI9Jj4guYPWnVGBV13S PE7.ieBL8jrUqto0qClGBPvflKbOSZMNbxaKIjD1Bdi0DTO_TyrOjPsXNZtxzW45FUs2sutvTSLX SJo9HjlC15Cc.YRzzP0C2Eq_4Gq0I2ciUrPdAa0Hb3a8dNyZ45_Jit05JVu1nq1cMQ_cy4_CAngJ XjWuF5Rk0saAw48it3m0DJnPXI4YMd5NOG0VxWQkcpph.0n._n9LAetpwfjNXxgisCEQqV8rRNK9 CIgvpOQ9mZqyNXR3BFj881PFvta7QMcecNK.PAYLTo5ZvgHRI6kg1DChVNUyRiQ0lu.m5n07hLk4 MhF0_nXTbk6kmk.G7cuSerdRaeS.fODtN9sjnmkZs9fGqEj22qrIhbbJU1UstTAxjNAqL3BeddVa P3qdmttuj6Nk78L3o9krI0y.HlPpV9SbFggcbXgVnVNcBxB5rSaotSDlpYdkw.O3M3iTeKWtUKV5 EA0vBLpoJxd4JZLBcQ9S5Mv99keCnJAVS3QVhv9DEru9AcTn8u0ozLWr.qtMszzvXWyK6PLFnNBZ O1Mf7G6QbOM0zHSRHhwKTghzKDECd2AOBs53o.3NAarZ1Mx_oHH0GSi.K_AeDgAtYUIHOUg7Yl66 ZOa3FQXVxI1bLYQNKQ6RNzTpIPKjAFyUwXBAZI.12HvXQEPZld2EYHqqvy_3GcIhAWMtjImeW6J7 uRrvB52jwr2p1BOQyWYSL_A6AG97Un8wJspqMuTapqNXjYip0309nn_smtyvkuSK064OTjf7kkbG QvN4CEaFE8BfcCGTPzuddjnoGErvTbu3hj1f0kVY4ixPyWDq3nd0Q3ofVAJ9t252fNM8OITjhscW w2cmbdcvBrKCVhbRhi10jicMjf5fiShYQnp4TlN79QF2_1mEK_XIP6ZXhvDORwjcE6ydLsBX.7VQ EOaNq1cG.8Hl4ROCPiPuRHo.XS2lMPT5gN08h4NueIKa5i3JG2a_DZGm.SeozvafIAAxHVcRnHQQ b4PDjB4qW2CO.rsMyW_lgV213yhLmxxzwM7v8DiQtVL9_DpUUooKBgwDPFQnJ3QptZ.ZWPLbbTVm QXOin.gGVVZHaQJQr1f0i7YqOU_hYUwGgsYIpbzzMYtU.sj78OBO57I1.cF_CUwx_GwataTGS21P cuJk4ENLby3mJvKjSLK5l2d6PbI6MKXAhIVx9zP6Vav2N1AxWtleaVNxC0zgOtF9Uc.kR1h6DP44 59OFFwzFS3DMhNTym7RIWGEE0pHxkxKpWVo4jXDmsigovOZbagmxzW9vV8GbbOc43hvZwtTtp10u KQPvxIKz3w_IIedizcr7LRI2rSdfOg15ehzTP5.snTjCFD4v3.mD0lpQb6sBSoSkg_H8t69DmRqL sjdK.EE_t.FW2ssEG3WvyW8gZAyvWY6Sh59oxpuspP6k4yDLNYXOfn7HfXNzxdU6x8qWH51uUaUk _0DxTPKAss4HUmF960umTdmFDoWdkPLvYfBrm08xJh9t7oS7RY74WP1nDWZRCnCKkoCbvmhaPop9 QjbWBLn_UuQ7W8A.C.tylWdGcoXjik_92.7brcYF3z8PNp0cOwC90Tza3ZW5zFzYAHtYZlruTEHc _nAzFuWGSMrlQheVQfr6V.56UP7oS6_GfcJ_fMIdLsABnJ_KG2qcNj7NYg5MuWrPY1HpZ9vsErP. BG80dc9S.W1d7EtgoQ_bfxZZOKCZ3J91dn6O299eBtQkLqh7.uh676RePdv6_uHdjGEoKGeLRN3e QHrW6p7OkNvCl5BsT.6Loz8DBC7wwkriEjNcZsraYvarHuBhd.XzrNz.Vh.YBpAB7CgaT9fjxsat mjORBSnZ7gkfjYLhqcZfHkFt3i05gfTOJtLaWPISkfXLMEczSikFbAiWxq9G5wDM70Tbj21WOcaB wZZVkUCU7MueB.RYIifCvi_ax9Bd8_RNvcIattMtkI9nF5EpIGX_32Wtqv.758Q78NilWrQUkNWP SyBQERzwFuy6HgyuBprgI99axmc0FmzN1ZCj1POtC1gmwrvISJoXSGSSnCJE9YQQNse39.27mWJz PYLl3GcqzDAUBV6H8aEzz91oX0F7tpykBMXGvI.HX84XSix_Em4_LobjLDjaud8ZqR7ffkt1Dwje .Vsh48mKv31SNB3qeVfhpJcs.szB3CPFTV38cjVlpjA6WDQTsXw2Lxk01n2YUaBzLEPMjc8WCxg4 yFEyMrdw8xyBZbm88LP8gL.lCDk8- X-Sonic-MF: X-Sonic-ID: e14e9ee1-1209-48ee-9adf-7b925b26b592 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 9 Nov 2025 04:26:32 +0000 Received: by hermes--production-gq1-86c5846576-z6xgm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3bd2aecb8320789b981202e29d5dc1ae; Sun, 09 Nov 2025 04:26:30 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii 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: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] Message-Id: <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> Date: Sat, 8 Nov 2025 20:26:19 -0800 Cc: "bz@freebsd.org" To: kargls@comcast.net, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[comcast.net,freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from] X-Rspamd-Queue-Id: 4d409p4W7Jz3xZK Steve Kargl wrote on Date: Sun, 09 Nov 2025 01:55:40 UTC : > Can someone back out the git commit 4179e6b78297369f? > This is causing pkg-fallout@ to spam the freebsd-x11 > mailing list. It seems no one reads replies to pkg-fallout. > See for detail >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D290432 It appears that commit is in stable/15 and in releng/15.0 as: = https://cgit.freebsd.org/src/commit/sys/compat/linuxkpi/common?h=3Dreleng/= 15.0&id=3D62c3b77d1d1084dc46663eed52e288307b5c7e64 Your request is probably a very big ask as this point. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Nov 9 07:00: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 4d43bJ2H6pz6GNk8 for ; Sun, 09 Nov 2025 07:00:28 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resqmta-c2p-569298.sys.comcast.net (resqmta-c2p-569298.sys.comcast.net [IPv6:2001:558:fd00:56::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d43bJ0Ccwz3FH0 for ; Sun, 09 Nov 2025 07:00:28 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; none Received: from resomta-c2p-555483.sys.comcast.net ([96.102.18.238]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c2p-569298.sys.comcast.net with ESMTPS id HzOlvBnzG0zLCHzPRvMB3d; Sun, 09 Nov 2025 07:00:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1762671621; bh=+7B/ON0NSkGiLr0f8L5sSqsF/WlRjxNV/7ZdWfKI8lA=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=1EgUrrbB46XSdbK7XJHIJAHtNKd1+aQvmRigK3B0qdqIR8C1Ar7H5KExbwQLWA1D7 oS0Ts6DJbqhhWDzRXp+rzjlvPjzkx2Gqum3lPiNm1zIRSDVOgRfR3fbQr2z5l9WW8h z/qPhz9JbNqW+MvR2rYVS2/vHTI46R7o+Jbp0RlXsg43ujgfBlA0u6XOk24BNKz3Ve dsZrgr93GryIikACgstg/tXQIsHl5KAQKVjmf0PddUSNswAlBWVDBHXF+hNnDQD1vd 9mMKxkC4UIRIOSjGGpDRUr8mwOdOwCGHACuoHjk8lV/mHPbzTIdhywXGmS5qyTK6rn cDHX4af6mbPRQ== Received: from [10.0.0.30] ([73.83.213.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-c2p-555483.sys.comcast.net with ESMTPSA id HzPQvFI0XzKztHzPQvTw9B; Sun, 09 Nov 2025 07:00:21 +0000 Message-ID: <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> Date: Sat, 8 Nov 2025 23:00:20 -0800 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: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] To: Mark Millard , FreeBSD Current Cc: "bz@freebsd.org" References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> Content-Language: en-US From: Steve Kargl In-Reply-To: <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfHMjsyGHvy7SS+GsFH2OEmK6RyE/C5ZmZD5xAZK2qG5pp3rNKZezcnYq7qi6qv7/wYMENHkifGq1GoGOJWZGPzgDMS7GfgTNdxUB2TFbZwuXFBq6+Lvp CycrzN+0E4wdzqFyhl9VLrUsfWZB1nmIZYK826XmQm92RdQ39+uUoaH+GHGtUZ+pGgBBcAW5VTPjQUR0wxw3pump8QaPdcJ8olp3hosla1RVcnVoP6cui0Sl fRl+zY1OM2PyiZBBEH5tsw== X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d43bJ0Ccwz3FH0 On 11/8/25 20:26, Mark Millard wrote: > Steve Kargl wrote on > Date: Sun, 09 Nov 2025 01:55:40 UTC : > >> Can someone back out the git commit 4179e6b78297369f? >> This is causing pkg-fallout@ to spam the freebsd-x11 >> mailing list. It seems no one reads replies to pkg-fallout. >> See for detail >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290432 > > > It appears that commit is in stable/15 and in releng/15.0 as: > > https://cgit.freebsd.org/src/commit/sys/compat/linuxkpi/common?h=releng/15.0&id=62c3b77d1d1084dc46663eed52e288307b5c7e64 > > Your request is probably a very big ask as this point. Yes, the patch was merged into stable/15. It should not have been! It's not a big ask. Either back out the commit or maybe, just maybe, someone can commit the patch in PR290432. There are dozens of pkg-fallout@ emails to freebsd-x11. Many have a reply from me pointing to the patch in PR290432. So, either back out the patch that breaks X11 for many people or commit the patch in the PR. -- steve From nobody Sun Nov 9 07:14:01 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 4d43v76T1zz6GPXN for ; Sun, 09 Nov 2025 07:14:11 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [31.134.205.98]) (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 4d43v64Q1Fz3Gk2 for ; Sun, 09 Nov 2025 07:14:10 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=W1KsFt0Z; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 31.134.205.98 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws Received: from crmpreview1.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview1.colo2.realworks.nl (Postfix) with ESMTP id 09E9340147; Sun, 9 Nov 2025 08:14:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1762672442; 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=cYROr2AXLrmZSBliZguFxPLJ9AosncXyPHHjhAwTnoU=; b=W1KsFt0Zbhw2aBTHsXRRHQ+cdMYibMZHdMrzqHjXtKLavMFh71prC+z0I/uKSzbqIimJje GD0hGpnUPMzjiuHJKDYpFrUmP4noTJQyYl1PZqNbzbENUIqyruWv0shNGoB+xhGi9XjJnb Uv1L/s1mVNgZUMxKfVFuSrQx+F1+4XJoz0AzW56mlAXsbvFHRaZXly6TdhJT13dTGpxKoR +o21CsrW2QFOHsl2c3f8UY0JrUizhGUrLCz2ZGCyN3q4drH6U2qFNr0GGvy270mvqFSXRf D8JvK2+ykV4ASRqffL3jH7UoHRu2ERvTXhHVVZ9raeavTtjiLpmUw0mg2LkzlQ== Date: Sun, 9 Nov 2025 08:14:01 +0100 (CET) From: Ronald Klop To: Rick Macklem Cc: Peter 'PMc' Much , FreeBSD CURRENT Message-ID: <2100145914.14642.1762672441817@localhost> In-Reply-To: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? 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_14641_1157727444.1762672441814" X-Mailer: Realworks (772.17) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:31.134.205.64/26]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4d43v64Q1Fz3Gk2 ------=_Part_14641_1157727444.1762672441814 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: Rick Macklem Datum: 9 november 2025 00:23 Aan: FreeBSD CURRENT CC: Peter 'PMc' Much Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? >=20 >=20 > Hi, >=20 > Peter Much reported a problem on the freebsd-fs@ mailing > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > hang for hours?". >=20 > The problem was that he had a copy_file_range(2) copying > between a large NFS file and a local file that was taking 2hrs. > While this copy_file_range(2) was in progress, it was holding > a rangelock for the entire output file, causing another process > trying to read the output file to hang, waiting for the rangelock. >=20 > Since copy_file_range(2) is not any standard (just trying to > emulate the Linux one), there is no definitive answer w.r.t. > should it hold rangelocks. However, that is how it is currently > coded and I, personally, think it is appropriate to do so. >=20 > Having a copy_file_range(2) syscall take two hours is > definitely an unusual case, but it does seem that it is > excessive? >=20 > Peter tried a quick patch I gave him that limited the > copy_file_range(2) to 1sec and it fixed the problem > he was observing. >=20 > Which brings me to the question... > Should copy_file_range(2) be time limited? > And, if the answer to this is "yes", how long do > you think the time limit should be? > (1sec, 2-5sec or ??) >=20 > Note that the longer you allow copy_file_range(2) > to continue, the more efficient it will be. >=20 > Thanks in advance for any comments, rick >=20 >=20 >=20 >=20 >=20 Why is this locking needed? AFAIK Unix has advisory locking, so if you read a file somebody else is wri= ting the result is your own problem. It is up to the applications to adhere= to the locking. Is this a lock different than file locking from user space? Why can=E2=80=99t this tail a file that is being written by copy_file_range= if none of the applications request a lock? Regards, Ronald. ------=_Part_14641_1157727444.1762672441814 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: Rick Macklem &= lt;rick.macklem@gmail.com>
Datum: 9 november 2025 00= :23
Aan: FreeBSD CURRENT <freebsd-current@freebsd.or= g>
CC: Peter 'PMc' Much <pmc@citylink.dinoex.sub.= org>
Onderwerp: RFC: Should copy_file_range(2) retur= n after a few seconds?

Hi,

Peter Much reported a problem on the freebsd-fs@ mailing
list on Oct. 21 under the Subject: "Why does rangelock_enqueue()
hang for hours?".

The problem was that he had a copy_file_range(2) copying
between a large NFS file and a local file that was taking 2hrs.
While this copy_file_range(2) was in progress, it was holding
a rangelock for the entire output file, causing another process
trying to read the output file to hang, waiting for the rangelock.

Since copy_file_range(2) is not any standard (just trying to
emulate the Linux one), there is no definitive answer w.r.t.
should it hold rangelocks.  However, that is how it is currently
coded and I, personally, think it is appropriate to do so.

Having a copy_file_range(2) syscall take two hours is
definitely an unusual case, but it does seem that it is
excessive?

Peter tried a quick patch I gave him that limited the
copy_file_range(2) to 1sec and it fixed the problem
he was observing.

Which brings me to the question...
Should copy_file_range(2) be time limited?
And, if the answer to this is "yes", how long do
you think the time limit should be?
(1sec, 2-5sec or ??)

Note that the longer you allow copy_file_range(2)
to continue, the more efficient it will be.

Thanks in advance for any comments, rick



Why is this locking needed?
AFAIK Unix has advisor= y locking, so if you read a file somebody else is writing the result is you= r own problem. It is up to the applications to adhere to the locking.
=
Is this a lock different than file locking from user space?
= Why can=E2=80=99t this tail a file that is being written by copy_file_range= if none of the applications request a lock?

Regar= ds,
Ronald.

------=_Part_14641_1157727444.1762672441814-- From nobody Sun Nov 9 08:52: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 4d46564Ll8z6GWLM for ; Sun, 09 Nov 2025 08:52:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4d46562950z3TFf for ; Sun, 09 Nov 2025 08:52:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64165cd689eso1151722a12.0 for ; Sun, 09 Nov 2025 00:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762678370; x=1763283170; 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=ra+kdZAQe9q2GXzirnlDBvPR0mKyggTmfFxHQdhZuk0=; b=UlyiYDtmyo1Hb5TPVVtzKeRKKB6N2IgCJNk8ORDqJLHZ4sJQwsrDDF3hH4cvvggKY6 0KsRL1hDYz1Fpcyw4iCh1O5CWmCbob+f+7rV8DHWpKdUhOqdH/4+P3i4EEreNGd8skmY z+dX7b+35DTrrzsY/9XAUVu/eYXXHRQ8zW+3xYL/8DEvrGNOYo4HuXCNoCzYxUO8728X zAmOqVkQaNPSnkYJ/muoaEuCfurXyhBctl6QcO2OMO5pcqj9p2ZCbhBAdQyOxNwW63ys tbg0qTBPluLVflm0OaIz+qyvT3oamJ89og7YSQK5InM1tEXCrG+ZY/av25g1LndopeKb QJQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762678370; x=1763283170; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ra+kdZAQe9q2GXzirnlDBvPR0mKyggTmfFxHQdhZuk0=; b=f42NaxZ3XtPIs1bU0O16QGpO139QaVZ8TScOLP0lEUeGH7BHqtTMIilYGS+tQGM+Km vYkLG2kM32urtqZzjJFZwXMaz3FlvcchuQSqrjgGT6OlvrjX/8L0tUC1iU6aMxnrAtcV qyLTJGnXGSSMevoxkqngT7xhSG0UudtQnMqcf6EEFtWZ8CYeB5M0OPf03EQ0ZjMSo4GR Kwg6QXX28HplIzKL2wNXJKkdXvDGPbRP/+bJz/e1vElRKgkdTpFNjY56n7w74RIPLS7W YfeBF0jOPNyOIWyoN/wkD1IMQ9OTccSKAuOQJCswup60yNcAAOv91RaKjiqrEt8ty0qT pRCg== X-Forwarded-Encrypted: i=1; AJvYcCWBlYmh2woUx+rOwMBF0egSGD/EpcL4xdFcQY85YEnpaafARR14GJxDu3HeAQQifsq9Sd0nJ8eZG+xkGYYTUjo=@freebsd.org X-Gm-Message-State: AOJu0YwK9c1lU0SPn9dM7ONTP5i7SlH329TbpnJn2DGN0tevoCqv9Cc0 E1E/BZNHxI2PiGKqcsIhesgqQY1dbWOPP+no10KBE66JVeVS+M4aiwxb17uqhDRpCK3/TbjlOHj iEqAYfcEztuxLLhqwVtSjySHUVH8Nt0U2h+Rn5A== X-Gm-Gg: ASbGncsf/Qliu5Ul6CJpyFFuHCtP9MNbPYSl6R/RrrjdR2tmL2hkHUfYSF1W43jlKe+ bGj04fteATxAN0ADEOifGvXzOdz6tVupORIyiQmFB2W4JW0d0M7vq0WqnjMWUIHtCpdBaKO0Zbd mF63llreB5Eq2Wwp5x6Z0rIo14qNvYurunUwqiIoFxhnGSBVk/Atad85HPXqGb4dvJ6lPQ7v/VU A4KzqQLFCeaBrtGuLgmwscZcpRnI+sVnAlFcoSDhaB+GYPYy/JTazfmFT02Kj+0pOnExRLvNCfr cLK1NyV8GAOg2lUk5Pw9CNPZ2Cs= X-Google-Smtp-Source: AGHT+IEOV81SdWDrI1P5msFrd6rrA8x3G91GBbv/JOrf3E+t0rlnkLNTiwZa566wYtpgcVFXyTGkMbH/XmGfKuEEPrY= X-Received: by 2002:a05:6402:454a:b0:640:931e:ccac with SMTP id 4fb4d7f45d1cf-64146f33e02mr4711274a12.7.1762678369982; Sun, 09 Nov 2025 00:52:49 -0800 (PST) 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: <2100145914.14642.1762672441817@localhost> In-Reply-To: <2100145914.14642.1762672441817@localhost> From: Rick Macklem Date: Sun, 9 Nov 2025 00:52:38 -0800 X-Gm-Features: AWmQ_bmKnUScoLVbgUXNg_UBCaHYbszq0NYU8aVSLrqNG_k1wVPQ7kx3p-EVM7w Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Ronald Klop Cc: "Peter 'PMc' Much" , FreeBSD CURRENT 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d46562950z3TFf On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop = wrote: > > > Van: Rick Macklem > Datum: 9 november 2025 00:23 > Aan: FreeBSD CURRENT > CC: Peter 'PMc' Much > Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? > > Hi, > > Peter Much reported a problem on the freebsd-fs@ mailing > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > hang for hours?". > > The problem was that he had a copy_file_range(2) copying > between a large NFS file and a local file that was taking 2hrs. > While this copy_file_range(2) was in progress, it was holding > a rangelock for the entire output file, causing another process > trying to read the output file to hang, waiting for the rangelock. > > Since copy_file_range(2) is not any standard (just trying to > emulate the Linux one), there is no definitive answer w.r.t. > should it hold rangelocks. However, that is how it is currently > coded and I, personally, think it is appropriate to do so. > > Having a copy_file_range(2) syscall take two hours is > definitely an unusual case, but it does seem that it is > excessive? > > Peter tried a quick patch I gave him that limited the > copy_file_range(2) to 1sec and it fixed the problem > he was observing. > > Which brings me to the question... > Should copy_file_range(2) be time limited? > And, if the answer to this is "yes", how long do > you think the time limit should be? > (1sec, 2-5sec or ??) > > Note that the longer you allow copy_file_range(2) > to continue, the more efficient it will be. > > Thanks in advance for any comments, rick > > ________________________________ > > > > Why is this locking needed? > AFAIK Unix has advisory locking, so if you read a file somebody else is w= riting the result is your own problem. It is up to the applications to adhe= re to the locking. > Is this a lock different than file locking from user space? Yes. A rangelock is used for a byte range during a read(2) or write(2) to ensure that they are serialized. This is a POSIX requirement. (See this post by kib@ in the original email discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/0047= 04.html) Since there is no POSIX standard for copy_file_range(), it could be argued that range locking isn't required for copy_file_range(), but that makes it inconsistent with read(2)/write(2) behaviour. (I, personally, am more comfortable with a return after N sec than removing the range locking, but that's just my opinion.) rick > Why can=E2=80=99t this tail a file that is being written by copy_file_ran= ge if none of the applications request a lock? > > Regards, > Ronald. > From nobody Sun Nov 9 16:56: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 4d4Jq63Vvjz6Fgtp for ; Sun, 09 Nov 2025 16:56:34 +0000 (UTC) (envelope-from bz@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 4d4Jq53lSLz46P4; Sun, 09 Nov 2025 16:56:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762707393; 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=YDnoObN1Zk8rLDAD2BNLmRBj1OG5LDo/yrjNCM+J6vM=; b=tMdyrpbYsuh66vw/YlDtdlKy6jdJBrYooVKfb0ovy+eGlIu+3v3PjmhvtijHOxlITWJgS5 oBHE31L60RbeIFuwfXxsg0B9rsTdFvgC+FV7FSdeeJ/5VIVbVFOh8J4lyEI5wzDIqkXUoX 4AWjGJx79o3US4jj3p2BPn+nAk7nknEy9Erl41v26hEb11eUoh9KezhlceJt0wOFYgb4sM jdO0yFoH6ZbDwsmTyw2pIr/cqy5jADX5D03g2zSM0cqN4lBWypg8+/kfD2kNPNcZJTb41I 0ARESiCVnQXl9G4WA2faa8Psvh6Ck5sOLFaRqqlZopviw4X+/cWaD6nPd6LVZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762707393; 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=YDnoObN1Zk8rLDAD2BNLmRBj1OG5LDo/yrjNCM+J6vM=; b=sVqP2IEBh8BGZxfIwp2NWORWSOtUOUVEnRN54zw4abM0dXaAi5rZPbTWk+v0XVCUrt8hmI P5zyL9fB/fGKZ3jNDQMbwMkyA9eUxm5YO4tbA/zWXkPOIqhFz9801dhitLp7CTKSksSOsA WjeE55OEF6mp7/416b+UdRlSFcekk+tRmiKCZZIS8FzXbO1ldivraUprKotecwhBmfZ80C soSw9hlGfftW0UiFeHNMU0pliFB7SMXAcvyTTD+O6vbWGn6biDc7bEpLAnIGdwA1xNkQ5L ptDKxDLYyuw/99BKrIyn2+CXFI29q0a8p3mMcBS7ax4dlxhrlXlrwDLs4vLBgA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762707393; a=rsa-sha256; cv=none; b=ioZw9Hm2omn/70e6oJpVFQKXtnF/y0SBg8vSzKif4FIrQ32UCAad7MIEpixROMJBz9twZ/ lijkwx6hiBrE/Wur8TYwKXpr/kMK9aI+Ru5pznSvAPIzNSDGrmsauvchsStRhHJK8EgiFq SEChRjpwDJy/7TMypC2g1bxni9ZUHpMh4C7sQ7nq8D7ciMdRCyCE/IliaeUpDflc38Iyxf HLj6pjv+URSdFqIlAs+f4G4j+3aNB9A//FLj75KfL82KFSp2zFcdSOM3o262pxOuyzw40z 71MkFO3PqJga6LMV8Rg3wCyqm94HTSEFKhonRpCwjTnqsSUnjCAPZO5zbM5cVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 "E8" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d4Jq52B44z960; Sun, 09 Nov 2025 16:56:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) 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 337E7A64805; Sun, 09 Nov 2025 16:56:18 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E070C2D029E6; Sun, 9 Nov 2025 16:56:30 +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 TkxAdtZ0-RlT; Sun, 9 Nov 2025 16:56:29 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (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 8070F2D029D8; Sun, 9 Nov 2025 16:56:29 +0000 (UTC) Date: Sun, 9 Nov 2025 16:56:28 +0000 (UTC) From: "Bjoern A. Zeeb" To: Steve Kargl cc: FreeBSD Current Subject: Re: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] In-Reply-To: <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> Message-ID: <162qrp4-qr99-5qr6-413s-6r7rpr39nno9@SerrOFQ.bet> References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> 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; charset=US-ASCII; format=flowed On Sat, 8 Nov 2025, Steve Kargl wrote: > On 11/8/25 20:26, Mark Millard wrote: >> Steve Kargl wrote on >> Date: Sun, 09 Nov 2025 01:55:40 UTC : >> >>> Can someone back out the git commit 4179e6b78297369f? >>> This is causing pkg-fallout@ to spam the freebsd-x11 >>> mailing list. It seems no one reads replies to pkg-fallout. >>> See for detail >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290432 >> >> >> It appears that commit is in stable/15 and in releng/15.0 as: >> >> https://cgit.freebsd.org/src/commit/sys/compat/linuxkpi/common?h=releng/15.0&id=62c3b77d1d1084dc46663eed52e288307b5c7e64 >> >> Your request is probably a very big ask as this point. > > Yes, the patch was merged into stable/15. It should not have > been! > > It's not a big ask. Either back out the commit or maybe, > just maybe, someone can commit the patch in PR290432. > > There are dozens of pkg-fallout@ emails to freebsd-x11. > Many have a reply from me pointing to the patch in > PR290432. > > So, either back out the patch that breaks X11 for many > people or commit the patch in the PR. I followed-up on the PR but I have no clue where pkg-fallout stuff for drm-kmod modules go -- do you have a link to them? Not that I am doing drm work or ports but I'll be happy to look. If the commit was a problem it must have been one for almost 6 weeks. Someone could have mentioned this since somwhere. The above + nvidia blocked wireless updates for more than two months and all of this was known since some time in July so it's quite late now. The above LinuxKPI change cleans up stuff in drm-kmod which should have happened a long time ago (or never been done that way in first place but I guess years ago LinuxKPI just wasn't there yet) and there's more of that needed to avoid blockers for other things in the future. The workaround I suggested for you in the PR would likely have to be applied conditionally to 5.15-lts (or maybe even 5.10) but 5.15-lts is not referenced at all by graphics/drm-kmod. So if you want things to work, it's the ports which needs to be fixed. /bz -- Bjoern A. Zeeb r15:7 From nobody Sun Nov 9 18:12: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 4d4LWM71jyz6Fp1C for ; Sun, 09 Nov 2025 18:13:03 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resqmta-h2p-567039.sys.comcast.net (resqmta-h2p-567039.sys.comcast.net [IPv6:2001:558:fd02:2446::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) by mx1.freebsd.org (Postfix) with ESMTPS id 4d4LWM4Ms7z3cVR for ; Sun, 09 Nov 2025 18:13:03 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; none Received: from resomta-h2p-555059.sys.comcast.net ([96.102.179.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h2p-567039.sys.comcast.net with ESMTPS id I7XWvsfm5oGyZI9uJvAa9k; Sun, 09 Nov 2025 18:12:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1762711975; bh=ff3nWpGQQCTKjPeAqfeUTGSJ+EkJ8NtMf4WvlITpODs=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=1woRR6cjP513q291brcxLTW8vxsOIjRSMi22cMAtxefDkBeeMBlR0qr3vEZiMturZ B7PlcuDjF/eudX9ycpKl6nusP19kDiQEQxi0ZUCGM20M+PqxTglzTebv+EAWhcnK7X hlzpsT6L3Om6fsLyHOASbjHUYrb4l7ZNOLEgJdWb+Q0wW0ZPofrs+/NJ33I6L/Ceiu rAeNaFKgAWVBCGD3KQd/y8sy2XdULT2C5jB1/Ua+js/ShwCdSu4+9x2jycnbaXcNO6 3pP6z+nFzm6q6d7yrVDt8LiG/pqbS0vZx/E2G3Ae9SnQ4X4DqnQWO/yTvP8NMQsZGP 8oVbO0/Ewka4A== Received: from [192.168.204.22] ([128.208.234.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-555059.sys.comcast.net with ESMTPSA id I9u9vG2oTO38bI9uAvA0GV; Sun, 09 Nov 2025 18:12:52 +0000 Message-ID: <8cfec553-ac9b-4357-80c6-74b7442289e0@comcast.net> Date: Sun, 9 Nov 2025 10:12:45 -0800 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: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] To: "Bjoern A. Zeeb" Cc: FreeBSD Current References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> <162qrp4-qr99-5qr6-413s-6r7rpr39nno9@SerrOFQ.bet> Content-Language: en-US From: Steve Kargl In-Reply-To: <162qrp4-qr99-5qr6-413s-6r7rpr39nno9@SerrOFQ.bet> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfB3g9mJzwxq3FxfqUe1391KNC+SPZDW3+QXSBRR3vxmrZ+gD1xpfZlUyQ+5qYMEwpJCVDNeNX9SBj+gsci+fhlAvkNPM8XO5ndrdUX59FSwWopg4A8o9 IpKpYSMAS5SDbeGJgZiNyr2GRWXCzIuZJpgKlyixhr61veQJ7LaiRDc20TyUSQxyS9L6w0uMJLkPdiLz9w63I9vZniily56RlGWRu84AFgGJ6A+MM1awUXwG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d4LWM4Ms7z3cVR On 11/9/25 08:56, Bjoern A. Zeeb wrote: > > So if you want things to work, it's the ports which needs to be fixed. > First, commit the patch from the PR. That fixes the problem. Second, it is an interesting stance to to take. It's okay to break/diminish the FreeBSD experience for others in the name of progress. -- steve From nobody Sun Nov 9 19:46: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 4d4Nbb1ZLnz6Fvt2 for ; Sun, 09 Nov 2025 19:46:51 +0000 (UTC) (envelope-from bz@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 4d4Nbb108Cz3p9d; Sun, 09 Nov 2025 19:46:51 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762717611; 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=z+rS+WKMhT+COpISdFBpgsxRmb9oy758hm3WBsr1rEk=; b=ymR63hW9iRcq0HwCOD4zdrUrDv8S2ZWXzgmuobyKx2KKtzuxri3H8aCBjC2ZnIKimaMRel VwplDno3s2KHluZFCGMfcSY/YcagzmMnJETgwhGwUgVXLdpDn2n+qfQZ9F0p87rmFdbhr3 YY+igtQV1mIQUWUxKwKWcxretiiYhGfYxgOlWUDlgW6bI5pyfacbImgScHBupjdIT8oKce 3mv1LA4CmLbhX+HX9TZDTIPMhAn5Oth9sQGMfpI5pgWEg5MqbfNdipwgvQ3RPxMnS0ISKX fkzX9Fpx7tW6PLYHd2TMUV49e8A+gIFIWDIx8pp80Pk/XB/yIuwiDsF6g9mCzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762717611; 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=z+rS+WKMhT+COpISdFBpgsxRmb9oy758hm3WBsr1rEk=; b=CTNNtpq0HVEJlW7wdkT2FD5ecKMB3k78vMkx9mWlrKiQdLzjivBqNrvnxuLf1yRZxXI0US 3dV8xOzhd1F0YIXdXswi2xFuNppETLmB7A3ZFs394rsXGd3gWWYlG8jJXCPgstlL0r2xLe iEnN0WLpKH4Kd7OblWAJr9hptcYmz6n84sYI2KKy/0cQeUtYwnDZFxny3NDpiMPsPmUeO7 nm5nl6lcLzgP7ztkK1e7hv03/6+VDwO8EJZOhghGlGmfzx/oEZDFfArgmc7WYyna5hSChi zWDCaGGwoCYt+q0nKZW7DjYbAZ5hQvHs+mgTq3HE2hEjMwy3I8KNPrCeW39p5g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762717611; a=rsa-sha256; cv=none; b=tzf3EzRMjkKfH4XKR4LMVLKMj5QppFc3NL8lAiF6eKAwAfpmhbjJ8JwYwtwjqvhj8mRaXj w9xiFIJAPqWu0L7q9midOATTxZwGM+Yb6AwnRHldJxiAgFmIH0Mop+WRboPuqdzgbRh2t1 KV8PPuJ5QUy7nkjZRMUAt2atx4Fp6g3u+qa3tAjUmhzAxaRZr+TEk2HY/T8fMK1Hcsnaql 2KXwuLqBFO5AmQZEUh/Nk0MJi70HZj1PxepSnnyPeJQcQsSW6ggo6TczbpcHEYvgT9B51l gnWFyEIQhckOtHDveFNYKdYOsTCdS9GrWeUrmKL0BhDgS3eEVR96kNOvdtH+hQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 "E8" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d4NbZ6WTqzDKT; Sun, 09 Nov 2025 19:46:50 +0000 (UTC) (envelope-from bz@FreeBSD.org) 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 231E9A64805; Sun, 09 Nov 2025 19:46:37 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 13C292D029E6; Sun, 9 Nov 2025 19:46:49 +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 NOorRAOUnKYy; Sun, 9 Nov 2025 19:46:44 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (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 ABAFC2D029D8; Sun, 9 Nov 2025 19:46:44 +0000 (UTC) Date: Sun, 9 Nov 2025 19:46:44 +0000 (UTC) From: "Bjoern A. Zeeb" To: Steve Kargl cc: FreeBSD Current Subject: Re: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] In-Reply-To: <8cfec553-ac9b-4357-80c6-74b7442289e0@comcast.net> Message-ID: References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> <162qrp4-qr99-5qr6-413s-6r7rpr39nno9@SerrOFQ.bet> <8cfec553-ac9b-4357-80c6-74b7442289e0@comcast.net> 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; charset=US-ASCII; format=flowed On Sun, 9 Nov 2025, Steve Kargl wrote: > On 11/9/25 08:56, Bjoern A. Zeeb wrote: >> >> So if you want things to work, it's the ports which needs to be fixed. >> > > First, commit the patch from the PR. That fixes the problem. The -D is not for a drm-kmod/ports fix please; there's another semi-native driver in src which uses LinuxKPI headers and needed this and there's still a need to fix that. Then I'll see if I can get away with it within LinuxKPI itself. I added a suggested patch to your PR for the port for some grpahics/ports person to start work with and get it in. > Second, it is an interesting stance to to take. It's okay to > break/diminish the FreeBSD experience for others in the name > of progress. If that would be the case, then I probably wouldn't have bothered following up and helping identifying a better fix the moment I became aware of the problem. I am sorry x11 hasn't dealt with this since (must be) end of September. /bz -- Bjoern A. Zeeb r15:7 From nobody Sun Nov 9 22:36:24 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 4d4SMS5mfvz6G8Lp for ; Sun, 09 Nov 2025 22:36:36 +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 4d4SMS1cvDz3CnN; Sun, 09 Nov 2025 22:36:35 +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 5A9MaOjC003683; Mon, 10 Nov 2025 07:36:25 +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=1762727786; bh=IdiwI/5OceTBQco+3kXLjVnIJv5sTJRImEiB408d0wo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=I+8uoBzK1ITCyl8XANhxp8Gkmkt5euPwo+seD314zlw/gflcIdNpeO2oz6N2zwMLG xbUPVrAzuYwAgq3udHO9k3c5GVYODFPGuW16pboNV5pUxI5Bay0FjX3v3apAS3EU6J ZWbCr40qeUUWd4I6zyfqyuy+Zj2Hzk/hUculmPps= Date: Mon, 10 Nov 2025 07:36:24 +0900 From: Tomoaki AOKI To: "Bjoern A. Zeeb" Cc: Steve Kargl , FreeBSD Current Subject: Re: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] Message-Id: <20251110073624.00c77b3aab13e541f4d64407@dec.sakura.ne.jp> In-Reply-To: References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> <162qrp4-qr99-5qr6-413s-6r7rpr39nno9@SerrOFQ.bet> <8cfec553-ac9b-4357-80c6-74b7442289e0@comcast.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 4d4SMS1cvDz3CnN On Sun, 9 Nov 2025 19:46:44 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Sun, 9 Nov 2025, Steve Kargl wrote: > > > On 11/9/25 08:56, Bjoern A. Zeeb wrote: > >> > >> So if you want things to work, it's the ports which needs to be fixed. > >> > > > > First, commit the patch from the PR. That fixes the problem. > > The -D is not for a drm-kmod/ports fix please; there's another semi-native driver > in src which uses LinuxKPI headers and needed this and there's still a need to > fix that. Then I'll see if I can get away with it within LinuxKPI itself. > > I added a suggested patch to your PR for the port for some grpahics/ports > person to start work with and get it in. > > > > Second, it is an interesting stance to to take. It's okay to > > break/diminish the FreeBSD experience for others in the name > > of progress. > > If that would be the case, then I probably wouldn't have bothered following up > and helping identifying a better fix the moment I became aware of the problem. > > I am sorry x11 hasn't dealt with this since (must be) end of September. > > /bz > > > -- > Bjoern A. Zeeb r15:7 What's interesting here looking into freebsd-pkg-fallout ML is that (putting aside builder start failures) graphics/drm-515-kmod alone is failing. Yes, graphics/nvidia-drm-515-kmod[-devel] doesn't. As graphics/nvidia-drm-*-kmod[-devel] ports uses only some parts of distfile for corresponding graphics/drm-*-kmod ports, possibly it could help narrowing down where is the problem in. (Would be hard, though.) Note that I've checked posts on November and October using ML archive. Regards. -- Tomoaki AOKI