From nobody Mon Dec 18 12:59:02 2023 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 4Sv0Jc428Hz54Sxw for ; Mon, 18 Dec 2023 12:59:12 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (P-256) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv0Jb3bp8z3D9w for ; Mon, 18 Dec 2023 12:59:11 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=DdQC7iga; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org; dmarc=pass (policy=quarantine) header.from=blastwave.org Received: from [172.16.35.9] (cpe8c6a8d4d360a-cm8c6a8d4d3608.cpe.net.cable.rogers.com [99.253.151.152]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.16.1) with ESMTPSA id 3BICx3fN087188 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 18 Dec 2023 07:59:03 -0500 (EST) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1702904344; bh=9OohomhS78tdrZPuoJ2mk6HsynfhnOvHVYNOucs5bNw=; h=Date:To:From:Subject; b=DdQC7igaraSI7gkwjgeWXe1mP7+abjd2dPaqv+ObpiepKpCVT9YX01lWmBfL8ugYE tZ/pKEcd/vVbhvyVFy+9ORZYnM9A/bfUP+QeeXookvaMTIlNxysVZYGQIttlHrBc4W f0HAVhe1JAX2zaiWd3HZ7WR/dKqTRQdOY0jtBhYecj3kzjAs5pL2+rQKpMfLpT2RCj i971YE6x1tCGE1fgcSkUTwBPZugjVVzVMt7XRZfvAv+OtljVxHeQ1LsR7Kk1iUfMZg 2yxw7L/Gmd+J+ajhB04GbbduBlElNG81y4yOzezG3Iv/FiS/5M6+fc3+Z/R2g3F8IM HQ54is6TSbRCw== Message-ID: <1539f659-fdff-9dad-e385-444d890c68c4@blastwave.org> Date: Mon, 18 Dec 2023 07:59:02 -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/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 To: current@freebsd.org Content-Language: en-CA From: Dennis Clarke Organization: GENUNIX Subject: The ports quarterly tree 2023Q4 is borked for www/firefox Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 3BICx3fN087188 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Spamd-Result: default: False [-4.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[blastwave.org:+]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Sv0Jb3bp8z3D9w X-Spamd-Bar: ---- I do not know where else to post this. Seems that a bug report about the problem does not mean much : Bug 275814 - www/firefox has the wrong version in the Makefile https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 This issue is pretty clear. This morning I flushed out my ports tree and started over fresh : hydra# poudriere ports -c -U ssh://anongit@git.FreeBSD.org/ports.git \ ? -B 2023Q4 \ ? -f zroot/poudriere/ports/2023Q4 \ ? -m 'git+ssh' -p 2023Q4 -v [00:00:00] Creating 2023Q4 fs at /usr/local/poudriere/ports/2023Q4... done [00:00:01] Cloning the ports tree...Cloning into '/usr/local/poudriere/ports/2023Q4'... remote: Enumerating objects: 192710, done. remote: Counting objects: 100% (192710/192710), done. remote: Compressing objects: 100% (181019/181019), done. remote: Total 192710 (delta 11046), reused 115681 (delta 5175), pack-reused 0 Receiving objects: 100% (192710/192710), 83.07 MiB | 4.91 MiB/s, done. Resolving deltas: 100% (11046/11046), done. Updating files: 100% (155563/155563), done. done hydra# hydra# poudriere ports -l 2023Q4 git+ssh 2023-12-18 12:29:26 /usr/local/poudriere/ports/2023Q4 hydra# hydra# hydra# cat /usr/local/poudriere/ports/2023Q4/www/firefox/distinfo TIMESTAMP = 1702328424 SHA256 (firefox-121.0.source.tar.xz) = edc7a5159d23ff2a23e22bf5abe22231658cee2902b93b5889ee73958aa06aa4 SIZE (firefox-121.0.source.tar.xz) = 530302784 hydra# hydra# head /usr/local/poudriere/ports/2023Q4/www/firefox/Makefile PORTNAME= firefox DISTVERSION= 120.0.1 PORTEPOCH= 2 CATEGORIES= www wayland MASTER_SITES= MOZILLA/${PORTNAME}/releases/${DISTVERSION}${DISTVERSIONSUFFIX}/source \ MOZILLA/${PORTNAME}/candidates/${DISTVERSION}${DISTVERSIONSUFFIX}-candidates/build1/source DISTFILES= ${DISTNAME}.source${EXTRACT_SUFX} MAINTAINER= gecko@FreeBSD.org COMMENT= Web browser based on the browser portion of Mozilla hydra# So the Makefile does not match the distfile and this borks up poudriere over and over and over for about a week now : hydra# hydra# pwd /usr/local/poudriere/ports/2023Q4 hydra# git blame www/firefox/distinfo ^17b2a0299 (Christoph Moench-Tegeder 2023-12-17 23:45:07 +0100 1) TIMESTAMP = 1702328424 ^17b2a0299 (Christoph Moench-Tegeder 2023-12-17 23:45:07 +0100 2) SHA256 (firefox-121.0.source.tar.xz) = edc7a5159d23ff2a23e22bf5abe22231658cee2902b93b5889ee73958aa06aa4 ^17b2a0299 (Christoph Moench-Tegeder 2023-12-17 23:45:07 +0100 3) SIZE (firefox-121.0.source.tar.xz) = 530302784 hydra# There is no way I can be the only person on the planet that likes to have Firefox on their machine ... built from the sources. Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Mon Dec 18 13:35:57 2023 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 4Sv173704xz54W2G for ; Mon, 18 Dec 2023 13:35:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv1735rL1z4dt0; Mon, 18 Dec 2023 13:35:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702906559; 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=0cQhhgwS+wOFyrrVOjuevd6FEH7TxU9cSV3JZEW+sBY=; b=J0XlWpxWf/1q+UVQ7kF7NGMb424RT+02IyL/9el0xb2f+o0PgtxxdCfe6ZsLeIvRsi2uZM GewMHL5nLE2m80pJtm3sztHkLVqaPAj92DuufLu9DhT7GeO2sI4jh95HSiZ6rwpyellZoU tDFGJ/Lw1WmyKkH19DE1myKPHZ7BNJeHZTHRkL8fOG8qVefdaKMw66jmnvpsOJhAvlf/Pm BGpB2UWhPFpMZ5DffC2d6vfgcg6YBL6bQrl8yCeJVxnymWvvzbFl+YgwB1FN/a2MsuAuZz 9zuS0AnE8CL26ZJUGkoWyFO6qLHw4uE8gA/8TkytZH/C6nSK7LHnf4yW80Cymw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1702906559; a=rsa-sha256; cv=none; b=eCofC/L6jBIHBEk0NY1yRAu+9ywr78QTSObYggsHJNNdgzJayVq98YuAf/Z5SU0GYZ0RoH 7Vm3z1XnFRmG4QtVUP16kMSbAWVbVwihmsUFownX2EdGdAt0f62F5jeABkRDnLYvdoV+DX KBb0PIbFWDpyxILc3/iaHJQiluULO3B4b7AWJyukLeReCJ44MyjfifSTL3efel0YxaE088 uUX5ts7TpppRY7L/VQHQwmWtNlR7TBgvORotcSyoiNNdAJfWXBl+nKgehyn+nH734ua+ZZ lcQPxsVGJoBZy9DMEXuo/DU3jukDr7v8R3Nq+MfMc1+/8GMDlF7ymOJsDuNwKQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1702906559; 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=0cQhhgwS+wOFyrrVOjuevd6FEH7TxU9cSV3JZEW+sBY=; b=QkWI0rT/31cYAo33+ACZsvIkN/O6AswXj9575whJ9I1vjT58Wl8os4gI9IL6dyLOhb6rrc N599v+sTsDxrYNYDEYNQjDTmoHGV8YmaAgJuV2qep/QEVOd7wHx/n2kelJl/LCskuM/nVj WMp51rK0Utdr28Yo3XczJ86iWtqzrKpxHk+I85fLZEvFMcfsmegPwT78GlhB+FoFz+82di oLM4prdbqGquFKzgmAdZsGuliJIChCu+mRZm2YZxyqYjK7A6DLrFbdeiT4ZMb+wmmaUeyv EiAt8JFRWO5ECHkjN0FJHzhIZXF++V12L+bXFCBJny3YmT9BiRjIrFg9MIgDpA== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Sv1734C7PzC7d; Mon, 18 Dec 2023 13:35:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 131B5520C3; Mon, 18 Dec 2023 14:35:58 +0100 (CET) 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 \(3731.700.6\)) Subject: Re: The ports quarterly tree 2023Q4 is borked for www/firefox From: Dimitry Andric In-Reply-To: <1539f659-fdff-9dad-e385-444d890c68c4@blastwave.org> Date: Mon, 18 Dec 2023 14:35:57 +0100 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <71B662BD-215F-429B-BE57-D37C571F63E8@FreeBSD.org> References: <1539f659-fdff-9dad-e385-444d890c68c4@blastwave.org> To: Dennis Clarke X-Mailer: Apple Mail (2.3731.700.6) On 18 Dec 2023, at 13:59, Dennis Clarke wrote: >=20 >=20 > I do not know where else to post this. Seems that a bug report about = the > problem does not mean much : >=20 >=20 > Bug 275814 - www/firefox has the wrong version in the Makefile > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275814 Should be fixed by: = https://cgit.freebsd.org/ports/commit/?h=3D2023Q4&id=3Dec15ee20bdd912ca319= 82b1be0062da5fb783ac7 -Dimitry From nobody Mon Dec 18 13:43:10 2023 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 4Sv1HQ5CNKz54WTb for ; Mon, 18 Dec 2023 13:43:14 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 (P-256) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sv1HP6F4bz3NqQ; Mon, 18 Dec 2023 13:43:13 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; none Received: from [172.16.35.9] (cpe8c6a8d4d360a-cm8c6a8d4d3608.cpe.net.cable.rogers.com [99.253.151.152]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.16.1) with ESMTPSA id 3BIDhABA088114 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Mon, 18 Dec 2023 08:43:11 -0500 (EST) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1702906991; bh=nL8o6RnVMBEESA4OaIhtjiFIKDsNZmMtEJ7a5z72I74=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=f/4C39HdDUpCaVXaDOYUyTRkTgGsCqF7B5Cw9AZ1cd0VOF8zH3tdPFpbpJWHLrlSA 9r2oWlDd2bzymLQN5YgZ9Ppx/g84Qorj+EJWuCi5lKW9dqFVCg1+6iejA84N/jH81T UX5UarvR7DXUeaNahMO/CiKjouqGvDCfkY+zT6CBGcpULbpBBkLnTdhoYjKLq9h5dl H9/0a6xBqyt2c+WlYtveeYlODcUINd3pEh5T1CTckSyra8WR7C9bXbLEM0oGaxVcan 69irxBYCr4VPHJ4i7hz9NO04YWlFdLqzS9i0au1/Z5eIwjWWo8rj0ScUFNHr0X7JNw Wvh08F0Ec3fWQ== Message-ID: <44541c00-acf9-8559-3cac-8febac509760@blastwave.org> Date: Mon, 18 Dec 2023 08:43:10 -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/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: The ports quarterly tree 2023Q4 is borked for www/firefox Content-Language: en-CA To: Dimitry Andric Cc: current@freebsd.org References: <1539f659-fdff-9dad-e385-444d890c68c4@blastwave.org> <71B662BD-215F-429B-BE57-D37C571F63E8@FreeBSD.org> From: Dennis Clarke Organization: GENUNIX In-Reply-To: <71B662BD-215F-429B-BE57-D37C571F63E8@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 3BIDhABA088114 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sv1HP6F4bz3NqQ On 12/18/23 08:35, Dimitry Andric wrote: > On 18 Dec 2023, at 13:59, Dennis Clarke wrote: >> >> >> I do not know where else to post this. Seems that a bug report about the >> problem does not mean much : >> >> >> Bug 275814 - www/firefox has the wrong version in the Makefile >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 > > Should be fixed by: > https://cgit.freebsd.org/ports/commit/?h=2023Q4&id=ec15ee20bdd912ca31982b1be0062da5fb783ac7 > > -Dimitry > > awesome ! we have liftoff once again : hydra# hydra# poudriere ports -l 2023Q4 git+ssh 2023-12-18 12:29:26 /usr/local/poudriere/ports/2023Q4 hydra# hydra# poudriere ports -p 2023Q4 -u [00:00:00] Updating portstree "2023Q4" with git+ssh... done hydra# hydra# poudriere bulk -J 6:8 -j 132_amd64 -p 2023Q4 -f pkgs_to_build.txt [00:00:00] Creating the reference jail... done [00:00:01] Mounting system devices for 132_amd64-2023Q4 [00:00:01] Mounting ports/packages/distfiles [00:00:01] Stashing existing package repository [00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/132_amd64-2023Q4 /etc/resolv.conf -> /usr/local/poudriere/data/.m/132_amd64-2023Q4/ref/etc/resolv.conf [00:00:01] Starting jail 132_amd64-2023Q4 [00:00:01] Will build as nobody: (65534:65534) [00:00:01] Logs: /usr/local/poudriere/data/logs/bulk/132_amd64-2023Q4/2023-12-18_13h40m31s [00:00:01] Loading MOVED for /usr/local/poudriere/data/.m/132_amd64-2023Q4/ref/usr/ports [00:00:02] Ports supports: FLAVORS SELECTED_OPTIONS [00:00:02] Gathering ports metadata [00:00:08] Calculating ports order and dependencies [00:00:09] Sanity checking the repository [00:00:09] Checking packages for incremental rebuild needs [00:00:11] Deleting stale symlinks... done [00:00:11] Deleting empty directories... done [00:00:12] Cleaning the build queue [00:00:12] Sanity checking build queue [00:00:12] Processing PRIORITY_BOOST [00:00:12] Balancing pool [00:00:12] Recording filesystem state for prepkg... done [00:00:12] Building 1 packages using 1 builders [00:00:12] Starting/Cloning builders [00:00:14] Hit CTRL+t at any time to see build progress and stats [00:00:14] [01] [00:00:00] Building www/firefox | firefox-121.0,2 Thank you very much ! Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Thu Dec 21 12:22:47 2023 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 4SwqMR5D5dz54kJp for ; Thu, 21 Dec 2023 12:22:59 +0000 (UTC) (envelope-from eduardo@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwqMR4VlMz4Bb8 for ; Thu, 21 Dec 2023 12:22:59 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703161379; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=zTcjRh45gxF1Q5qH47nE7Dzyz7r680e6bvSbCquYq20=; b=Yyy3MWNXqbZSw4k81sTR+TopuGPBXwHWyW5LIqHN/BpAnsX5MRjc8odSn+Yx81NjAYli53 1SuGB58iBFAbyKQjPOTQBlt1fXudL2xQr2ePuKGAPgguoHGzc1mbXuUvggX6vzr49nJaAb Y17u+PLRgT7eqeCnepYnaXq3X0Ch651VeO9VxhR0y5iu5LlczVRlxE6o3Ei7l0VlaTaOev a5xkuW+gdaO5x1QfW8D7A2gIOAYDJdI6v4HEYgEWdGF6OaZ2F4o/rLVGjnj/EGJsvRA7Mq 7NkTBx1HDWtsNtLD3A4yvuih91t/YOb/po/AtawVaVRi/7k7hM5c8VrMEY/RAw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703161379; a=rsa-sha256; cv=none; b=I5IZLmueVmAgSwSjRvrt1j5W38slztjZ25HenVCEppSJMD+TGkKii4ncg7eK7KS9BMGIJv EQm9gIX3p+JYSSju1Ls8Hzi4nHI0ScyawGA3vQT5xRNJt2pCd3HdpJtQ4O+xy7Cf/2Zcsh NT/77xEuzyngHfYqoV/fJa2/D3pjrvaIk3tmmsc5ZsZEyjbpmXkfsJsTxXS2z8XUYnfxGE 7SWe4nHZEIHDrG9y7P6m/HIHttXGchV1/C0s+TpeUkA9qyDt9XWDaSjQWRMyhfj9UseMwF BYXw9eDiJNwvuWIfsjyYOaKDis+HHWQycU6+amhIF9Y4IOnmO3St1QuC/fVGHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703161379; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=zTcjRh45gxF1Q5qH47nE7Dzyz7r680e6bvSbCquYq20=; b=u2hJoQQIc/KTS4IyFumOanOLqwY9Ri0MpklXIjdtI5ExshGJpOzjMf8wXsT96PWtViD2rC /oEVlR3kteCF8xKfV+lH1L2NyQ+NKFzc2R9bVtlyxrTWjMxMbSLtZbflCF6V23YagVCGHt BluYO9FkFQ/4njLQzA4jVoGFodrPN+APKKCd81ZzOick41lVlQSzAjjv30pwswZIEWx4N3 yOPvFfuiwjqqvCXc3XrEoveEJ8MDCfrpAdzltd4bTC5ceW0ZruDITMs4th5GFyvecj32zQ +H1E3EMvyF78naRXRb6cotSdO7vu33+UMYMxrfkTcpYsJWhVKjL7KEXd0VbM6w== Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SwqMR3XL6z16HY for ; Thu, 21 Dec 2023 12:22:59 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4279007fb34so4223791cf.3 for ; Thu, 21 Dec 2023 04:22:59 -0800 (PST) X-Gm-Message-State: AOJu0YyrAIU7ECEwU5zQgpCb5hjaZdAkT8n/DrnvSbHbBCRmmj2yHMKI EgVo3upqajFmeP636Tp6w+EGUoUA/R3jZIn2Yps= X-Google-Smtp-Source: AGHT+IFMB+07UVeO/9Qemkujb7ifj1J5az9yQLxp5HsxQHxg2O1hNsR9XZ6bvqthcUtMllhDtJ1PH4+Yc6ZQO8l0/wo= X-Received: by 2002:a05:622a:5d4:b0:427:9efa:b823 with SMTP id d20-20020a05622a05d400b004279efab823mr646064qtb.98.1703161378819; Thu, 21 Dec 2023 04:22:58 -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: Nuno Teixeira Date: Thu, 21 Dec 2023 12:22:47 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: symlink to /boot/loader.efi To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000fad19b060d042843" --000000000000fad19b060d042843 Content-Type: text/plain; charset="UTF-8" Hello all, On every current upgrade I update efi/freebsd/loader.efi (amd64) and efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. For safety reasons I always have a copy of last running loader by appending "-old.efi" to loader or boota64 and use beinstall to get BEs if needed. Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> /boot/loader.efi ? Thanks, -- Nuno Teixeira FreeBSD Committer (ports) --000000000000fad19b060d042843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

On every current = upgrade I update efi/freebsd/loader.efi (amd64) and efi/boot/boota64 (aarch= 64) with new copies on /boot/loader.efi.
For safety reasons I alw= ays have a copy of last running loader by appending "-old.efi" to= loader or boota64 and use beinstall to get BEs if needed.

Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -= >=C2=A0/boot/loader.efi ?

Thanks,

--
Nuno Teixeira
FreeBSD Committe= r (ports)
--000000000000fad19b060d042843-- From nobody Thu Dec 21 12:48:52 2023 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 4SwqxL435pz54m0m for ; Thu, 21 Dec 2023 12:48:54 +0000 (UTC) (envelope-from dim@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwqxL32Tyz4FxQ; Thu, 21 Dec 2023 12:48:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703162934; 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=/ofeBCduUF3WvRWyBWPdZcEhqQPGVPqFDhn6eUqhBjU=; b=nkRn6dQ/5LLiRCQ6TDBVrg/f+UpjNRRs4LUTQlY/m2L4uXL9TUM+ZAldetevNw1EuRJUR1 HH3ZfS9Mygt6UZGaOHxR3PbVrzTJmowUy9SLbWYkRqzpTKfE+osqWgBFFVMOXk0/QYNCE4 zYMo4WYl/fAnL2PVT+EhNxLPeJOmK6FPeSH2mtsgWz3JEEU11wkyQU1cZmEaL7m3+glmuJ MkGCxo2v20SVwDapmIwX9uRGiDJUKBIUOqCYiN8tz6j4i3xYhXKI5uPq27aiNY7kOoXxsj ND+qa7JXCKQVeodYRvTXHk8QmdSs3KlVm74WBsnngqxnkfA2Cv7s32bUoG/oyw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703162934; a=rsa-sha256; cv=none; b=sTdT6/zHphhCRWRtxZy8yAKDD/Sl4wHuXZIFWlPtzGSFDTrupg9yan+eym8wVtnbm9Qzv6 3R9Sxb1cp2uEIublKhWFvRQjSHdDihrzx0MVcQSVK1gnqz6gFGYVyO4C4sDKrkY4mcgtZT cdh1peNGzAs3GwI4nEdmBYgatlrDiyG5P6aabFlGTw//Siz+BxT/fQCOujJlcZ98gUb2Tm 60xFEhUsd1jgaNgVKw9EqIthd2w4LtvSxVXucPEbTnBxRTMZkpTGCwaYYowufGaeeDyMKZ j36g3o1pRKu0DfYDMYt7LQ+0JkLFjRoo0pwLGohkxcvovZTqVIjaUv25lQSzxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703162934; 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=/ofeBCduUF3WvRWyBWPdZcEhqQPGVPqFDhn6eUqhBjU=; b=XVWJ1lSDTOPlU/XhQ4Wh1jSP6J1YiMsF1F9Jn+Nwp11gN8NKgSwKUsJ99uRySvd0UCVHXI yQiCrUgKkEDVveCv47REYYBaxupJkbprmpmBSrMCK0zZg+mkHbZB9Ed7WDcMHdVBuh5+s8 7KCxDfyaKA4/Mz+bfShzK9tMqgIZvjF//x6oI8Se77H5IAd7i6IJXzpyeqxf6Q8IX6z48x kXzJJXApUqu7kK0KskxwjJbVS6unO3ugph7IsQwTdP67N3/oYpNbd2OhT/edNprm/y4tIP 4VMyezVVT+aHa8DMAtgK0WdodSsA/S5zNJK9OVs9933HgCoN2qqcfhadcSledg== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SwqxL1PjRz17LQ; Thu, 21 Dec 2023 12:48:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E83EC4ED0E; Thu, 21 Dec 2023 13:48:52 +0100 (CET) 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 \(3731.700.6\)) Subject: Re: symlink to /boot/loader.efi From: Dimitry Andric In-Reply-To: Date: Thu, 21 Dec 2023 13:48:52 +0100 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <631DF939-4E18-4319-BE94-335E63B27B09@FreeBSD.org> References: To: Nuno Teixeira X-Mailer: Apple Mail (2.3731.700.6) On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: >=20 > On every current upgrade I update efi/freebsd/loader.efi (amd64) and = efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > For safety reasons I always have a copy of last running loader by = appending "-old.efi" to loader or boota64 and use beinstall to get BEs = if needed. >=20 > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> = /boot/loader.efi ? Symlinks do not work on FAT file systems, so I assume you mean a symlink = placed in /boot (assuming that is UFS or ZFS), which points to = /boot/efi/efi/freebsd? At the moment I think installworld would not write 'through' such a = symlink. In fact, it makes a hard link from /boot/loader_lua.efi to = /boot/loader.efi, unlinking any previous /boot/loader.efi. That said, it would be nice to have some sort of semi-official way of = upgrading the real EFI loader through installworld. It would probably = require some top-level Makefile magic. -Dimitry From nobody Thu Dec 21 12:59:54 2023 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 4SwrBH10rmz54mDl for ; Thu, 21 Dec 2023 13:00:07 +0000 (UTC) (envelope-from eduardo@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwrBG5dGnz4HZb; Thu, 21 Dec 2023 13:00:06 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703163606; 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=K10Tx7k2GWIzJGwO+pXUjte18UgJXB0GM1og8hnbkMI=; b=hMQik2D+WjHr1tkwU4ShmGVpH3UYqBdmNCebO3g1/ssf3GC/TuvfyDgymFxBmKpzR3WcSZ uQjgITgFwWESjglbSmpJGzl+ddaGiOAyjwz7l/zAkDzqONObU+1C+3g3f0AmMVDPu3FaVS FthbFRE/vLd0Z+7WSzsUAaSjsS2VXDN6jmTBi0IaVLpXZGElgAmg8cnkCy1LLqy9R3YFtm +gzLYpyfPIqPqgIFY8PtKX/Nl3UYvsWbfbBLaz69tKiPCoLMZWi0jvjd3PB0oy/WKCsh/U hfM6SvuFD5AX3Fdqs7C9dLW7p9VsDwC+yeTzXCzNfpX4z2QTJJWSOxyME9Lbfw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703163606; a=rsa-sha256; cv=none; b=IT6fQ0nlOTaJjjYZ6XbTxNsZUdio5DYX6lPstjyVHMJyUmbwwOqcs7+MoKcsS0eYIIN3xF YnFbqHM7nzbpH3tkFQPnrsW/jiJCM2xtzhyNlzzKpqQfCpi9FMBvslDOm5+kmsmmY6Qxro DeE4z8bU9HGAQC5jTszkTjT8jQjqPpy9aribcOkr7F+nTT70iPImL83YdCJOMDRPjThSJV xF0r2XylTH3qM2p2Nw36bjB+hUZz4AXAiVi1P7iM6mQRH1MXDLiQ2DgbzvvNdzGA3ri62V 1YLpJ5uwSBagQpWi2S9ixplhK61cXIUaNMjHsQU39Sh9zaSQA5q87DeczkWH0A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703163606; 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=K10Tx7k2GWIzJGwO+pXUjte18UgJXB0GM1og8hnbkMI=; b=fiyhYkLStQZqhVZ5RdjqbxR6aVBM8P6cnXDigYJLuF/CBSSk320B0Vr8FGSp2J6gfCEw+X 92KJou3SeKocLsqRGxFEtdc81c4zFm6RpS6QsY4KIEa8J1VUdm6nzwbjuuLsagywxux5Ig iAXXKqeI4n2IleWUF098n+2SEssXjFBZ5pRavHk+/7QRrWm6bN/MaoNoTgIDKqeag+5JhD 9Tno/7PjPJdAYzqhOpScmigUALicNWww2D7+/CQOZzzxb0tNrZt2wiunDQZ3IylQIWYuJ2 vA2fFbJumXyVietPXuTgngROK8VTnmQ87kflzs5s3VdWDLuZQ13yS1HmqWY5gQ== Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SwrBG4WrNz171W; Thu, 21 Dec 2023 13:00:06 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-42792fe28c2so5539671cf.0; Thu, 21 Dec 2023 05:00:06 -0800 (PST) X-Gm-Message-State: AOJu0YwmXBLpQ1BwGZajwrVPgQNoo42GakkXXiLLclrDzR+z4JqnO6PZ 4PQIHTnHn4Z+P8b3jxT3gU8mBLeDEkg3QVMGok8= X-Google-Smtp-Source: AGHT+IE3260ZsOzWVkRuv1CHJJfO1DaIkFYynFAK2pRAjdN7qkKpmxTRegaJCzsxvW9iYxhcbgMQyR/rxz7PtsFRkqo= X-Received: by 2002:a05:622a:18a8:b0:423:a5e3:bbff with SMTP id v40-20020a05622a18a800b00423a5e3bbffmr969004qtc.33.1703163606277; Thu, 21 Dec 2023 05:00:06 -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: <631DF939-4E18-4319-BE94-335E63B27B09@FreeBSD.org> In-Reply-To: <631DF939-4E18-4319-BE94-335E63B27B09@FreeBSD.org> From: Nuno Teixeira Date: Thu, 21 Dec 2023 12:59:54 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: symlink to /boot/loader.efi To: Dimitry Andric Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000bf2524060d04ad18" --000000000000bf2524060d04ad18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dimitry, For a moment I forgot that efiboot is a fat system... I am inspired on what installworld does to kernel and kernel.old. I was thinking in something like it but with efi boot, something automatic. Thanks! Dimitry Andric escreveu no dia quinta, 21/12/2023 =C3=A0(= s) 12:48: > On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > For safety reasons I always have a copy of last running loader by > appending "-old.efi" to loader or boota64 and use beinstall to get BEs if > needed. > > > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> > /boot/loader.efi ? > > Symlinks do not work on FAT file systems, so I assume you mean a symlink > placed in /boot (assuming that is UFS or ZFS), which points to > /boot/efi/efi/freebsd? > > At the moment I think installworld would not write 'through' such a > symlink. In fact, it makes a hard link from /boot/loader_lua.efi to > /boot/loader.efi, unlinking any previous /boot/loader.efi. > > That said, it would be nice to have some sort of semi-official way of > upgrading the real EFI loader through installworld. It would probably > require some top-level Makefile magic. > > -Dimitry > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000bf2524060d04ad18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dimitry,

For a moment = I forgot that efiboot is a fat system...
I am inspired on what in= stallworld does to kernel and kernel.old.
I was thinking in somet= hing like it but with efi boot, something automatic.

Thanks!

Dimitry Andric <dim@freebsd.org> escreveu no dia quinta, 21/12/2023 =C3=A0(s) 12= :48:
On 21 Dec 2= 023, at 13:22, Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> On every current upgrade I update efi/freebsd/loader.efi (amd64) and e= fi/boot/boota64 (aarch64) with new copies on /boot/loader.efi.
> For safety reasons I always have a copy of last running loader by appe= nding "-old.efi" to loader or boota64 and use beinstall to get BE= s if needed.
>
> Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi ->= /boot/loader.efi ?

Symlinks do not work on FAT file systems, so I assume you mean a symlink pl= aced in /boot (assuming that is UFS or ZFS), which points to /boot/efi/efi/= freebsd?

At the moment I think installworld would not write 'through' such a= symlink. In fact, it makes a hard link from /boot/loader_lua.efi to /boot/= loader.efi, unlinking any previous /boot/loader.efi.

That said, it would be nice to have some sort of semi-official way of upgra= ding the real EFI loader through installworld. It would probably require so= me top-level Makefile magic.

-Dimitry



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--000000000000bf2524060d04ad18-- From nobody Thu Dec 21 13:22:14 2023 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 4Swrgq6Xz0z54nXq for ; Thu, 21 Dec 2023 13:22:15 +0000 (UTC) (envelope-from dim@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Swrgq66Ypz4KYR; Thu, 21 Dec 2023 13:22:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703164935; 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=siFlT2yk7iMV/slOwqmFuCAGSJWwFK+I71Fb6XXwb94=; b=cLOLe7iOTE9On6Cfv7w2qPYakx/0yrgnxL8yHv8m24PsTxzaz00HSWQtG9zDFldVHYr7Y0 OjptknwMfPEzP2SXvc2tOT2xfYfAQ/h1cIHZWmU6bAJs96hZ/GDf8UyhZN+eZdWxp9R/hr oezZTwXyKX1zdXpzQqJHRl9mku3V350FK7a1ZV3nSjgoaahUSfqZ11URkUNWJHj2UqHckk vp5SNMF6Qd/5cPMlsc2NADPHhWThr827PuRZHkZD7EDySoY1R17HsQNImH+Ppce3z/jnlr TI9W5cZqW3gDQWgzlVv2gD5bb6mEod43wX6CgVX8uPTB5ovA7JUlWnmt74L2xQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703164935; a=rsa-sha256; cv=none; b=qMKyaMdj2Xb+LuSuC7tQq0zq9Kt9exm9QPwkMHV9gb+ujGL8i5lSfibX2fwxH9sJjVMpQs ML+Kl0ea4PEYMC6rjoTbMuQstW3QpZS4bBpOpJnjm3cwgrMmDEtiWYAADxWlAszu79bvhy nCIcNI2/ZCgqa5k972ZNYGlhKGKuCmKpAmP99Ncy0Xf8h9LQokyicD7C/e9HMZNL192ULg yt0pYSkRzTQlHmWo7yXY2FIIZfHKm/jPKIoNkzgbbjHWWWhglvlskJ7IfWB+CCso6ahBKR yfE6x3texBzP4xJOlbXVh3dZQtxpLxpiLmJtAcBH6tfPz66zZoF5DvFY6E8Udw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703164935; 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=siFlT2yk7iMV/slOwqmFuCAGSJWwFK+I71Fb6XXwb94=; b=N4vuplE6SsESI4m40ew8flX+DLV7AsPdf90MIUQrk3fo0iF8aJ2NY3MPRP/EDaMICLboOI lQxLfYrI9VXRkP/lDW+hXJHU/FMoMXq7pKl2Q5zC7O50ln2W/pMfhxh+LNH1jnuOZagpt5 W8fLRB7EXEIP5uTK1zxKz2YktAH2tn+FpV6q8a8q2JfoIU+D7F4RLGb7SayIDTvqsS+blA IjcrmCuczCnbi4jzqgUVldBfB/Lw8uOuibKTATPUT2DBN1pwOuMW/mqOB0f6tfXwQCHXLC deku/1rAfpxIeItXJWNrA49npXlNBcYue3Np6FK/S4I6jNOI9dLCyNVRwzJ3ZA== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Swrgq4SXtz16xx; Thu, 21 Dec 2023 13:22:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8AF114F24B; Thu, 21 Dec 2023 14:22:14 +0100 (CET) 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 \(3731.700.6\)) Subject: Re: symlink to /boot/loader.efi From: Dimitry Andric In-Reply-To: Date: Thu, 21 Dec 2023 14:22:14 +0100 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <90AA5680-49A9-4630-80EF-0580E8F31EA2@FreeBSD.org> References: <631DF939-4E18-4319-BE94-335E63B27B09@FreeBSD.org> To: Nuno Teixeira X-Mailer: Apple Mail (2.3731.700.6) Yeah, my procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld procedure. That said, I am unsure if the pathname /boot/efi/efi is always the same, = at least for all UEFI systems. It is the default layout when you do a = regular install with recent installer onto a UEFI system, but some users = may use completely different mount points. So you should still have some = way of configuring the default location for loader installation. Also, on default installations a fallback entry named = /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of = loader.efi but with a different name. Namely, the default name that UEFI = (on x86_64 at least) searches for, if it doesn't know anything else. = I.e. if it isn't configured via efibootmgr(8), or the EFI variables have = been junked for some reason. It might make sense to also update that = file. -Dimitry > On 21 Dec 2023, at 13:59, Nuno Teixeira wrote: >=20 > Hello Dimitry, >=20 > For a moment I forgot that efiboot is a fat system... > I am inspired on what installworld does to kernel and kernel.old. > I was thinking in something like it but with efi boot, something = automatic. >=20 > Thanks!=20 >=20 > Dimitry Andric escreveu no dia quinta, 21/12/2023 = =C3=A0(s) 12:48: > On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > >=20 > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and = efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > For safety reasons I always have a copy of last running loader by = appending "-old.efi" to loader or boota64 and use beinstall to get BEs = if needed. > >=20 > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> = /boot/loader.efi ? >=20 > Symlinks do not work on FAT file systems, so I assume you mean a = symlink placed in /boot (assuming that is UFS or ZFS), which points to = /boot/efi/efi/freebsd? >=20 > At the moment I think installworld would not write 'through' such a = symlink. In fact, it makes a hard link from /boot/loader_lua.efi to = /boot/loader.efi, unlinking any previous /boot/loader.efi. >=20 > That said, it would be nice to have some sort of semi-official way of = upgrading the real EFI loader through installworld. It would probably = require some top-level Makefile magic. >=20 > -Dimitry >=20 >=20 >=20 > --=20 > Nuno Teixeira > FreeBSD Committer (ports) From nobody Thu Dec 21 15:17:46 2023 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 4SwvFC4s5gz54v3V for ; Thu, 21 Dec 2023 15:17:51 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwvFC1m9Zz3C89 for ; Thu, 21 Dec 2023 15:17:51 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Authentication-Results: mx1.freebsd.org; none Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1rGKny-001gvo-Iq for freebsd-current@freebsd.org; Thu, 21 Dec 2023 16:17:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iherebuywisely.com; s=selector1; h=Message-Id:In-Reply-To:Date:Subject:CC: To:From:MIME-Version:Content-Transfer-Encoding:Content-Type; bh=mWIaQikrpoSzH5OG9qUnlTapFi1Jp5JykK/mZgc3lJU=; b=fuElmWgRv8SzbCZsGIoDu/TWBY AkcatHdzcJstAmi6Zrp1rUB/Nh5tCG5mq47RITWrenYiQA2Br9WvYDEgAAh8dDEjtlDl021eYzqjd 7LRncFlvpR3yuIpl1PPPV1AX9e7vORWReFnA0GGg9zRNHsOJfvPl1iARe42H6BE6GIjof9Ypw5EQ/ wAweJZCaCRblWPjqO0GUTS6pix6C7m0U/Ktnja91NXyVc9XVcV9YXD1SmebuShRxaE2ADUT5+48V9 eTyJ0MDEmcynC2nz70iDElFrvPhSEDWMXbt2PPKCAggGmtbk6qZuDj5w2CleXJv9Vph1kvix81fJx +ZoiAoyw==; Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1rGKny-0004AI-4x; Thu, 21 Dec 2023 16:17:46 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1rGKny-0003yc-3Q; Thu, 21 Dec 2023 16:17:46 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline 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 Received: from [Authenticated alias (650894)] by runbox.com with http (RMM6); Thu, 21 Dec 2023 15:17:46 GMT From: "Jeffrey Bouquet" To: "Nuno Teixeira" CC: "Dimitry Andric" , "FreeBSD CURRENT" Subject: Re: symlink to /boot/loader.efi Date: Thu, 21 Dec 2023 07:17:46 -0800 (PST) X-RMM-Aliasid: 650894 X-Mailer: RMM6 In-Reply-To: Message-Id: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwvFC1m9Zz3C89 I am wondering if all the information in this thread present and future sho= uld be included in the scenarios at the bottom of /usr/ports/UPDATING with technical explanati= ons about how and why? AFAIK the file was created before UEFI and thus in that regard= obsolete.=20 On Thu, 21 Dec 2023 12:59:54 +0000, Nuno Teixeira wro= te: > Hello Dimitry, >=20 > For a moment I forgot that efiboot is a fat system... > I am inspired on what installworld does to kernel and kernel.old. > I was thinking in something like it but with efi boot, something automati= c. >=20 > Thanks! >=20 > Dimitry Andric escreveu no dia quinta, 21/12/2023 =C3= =A0(s) > 12:48: >=20 > > On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > > > > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and > > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > > For safety reasons I always have a copy of last running loader by > > appending "-old.efi" to loader or boota64 and use beinstall to get BEs = if > > needed. > > > > > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> > > /boot/loader.efi ? > > > > Symlinks do not work on FAT file systems, so I assume you mean a symlink > > placed in /boot (assuming that is UFS or ZFS), which points to > > /boot/efi/efi/freebsd? > > > > At the moment I think installworld would not write 'through' such a > > symlink. In fact, it makes a hard link from /boot/loader_lua.efi to > > /boot/loader.efi, unlinking any previous /boot/loader.efi. > > > > That said, it would be nice to have some sort of semi-official way of > > upgrading the real EFI loader through installworld. It would probably > > require some top-level Makefile magic. > > > > -Dimitry > > > > >=20 > --=20 > Nuno Teixeira > FreeBSD Committer (ports) From nobody Thu Dec 21 15:35:54 2023 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 4SwvfJ3fc4z54w59 for ; Thu, 21 Dec 2023 15:36:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwvfJ1wNpz3FhG for ; Thu, 21 Dec 2023 15:36:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a22deb95d21so112212366b.3 for ; Thu, 21 Dec 2023 07:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703172965; x=1703777765; 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=YzGgmbbBCYy0B5pz7Bk5ilFj6uFQqD3M5gyAPfE2uvs=; b=xgcIi3CqYK1Cj65N71KwmSjJrZDWczbfYHLXUWjkxvtFFCekiLnjQgQ8wJt5W+3cGh uv2zz4m2rWrAouWPIXP4wROwYNO8mljhrBe9EFT4z7fdUCL/oR/2+Af6JGQVcLgHcSWo wbCPfNv4eMcC1BzgSagmDm9jceChsTi0RKeiScpfehS7BB5HtJEXJPsjQAK1FY5jp/4e Ph++XUV3d2YVrfVpIQffPcENE2uFHHUtb35jjUA8yqydd9oyfS/v11aMlDs25VUQbU4h ItFISuAJocnWqxYXzHXkOffPNTCeTtCaZFy9bU6gV78Lro6hKAN8l1Ts0HeTYgfvGNXr Cuow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703172965; x=1703777765; 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=YzGgmbbBCYy0B5pz7Bk5ilFj6uFQqD3M5gyAPfE2uvs=; b=VBTDJtGqXC2NfceKvM4Ki2dQpwniuunjt6eri74iXeXUvpgUNhovDthVPk8/hcdodZ ZQF8xAj1aCKfTH1BBM1VMEMpSwczU6E9zUQV8bDoF0WXz/W7IemtLEH/yeZ22A3MuIqP Cx27V8t9gh1cpuh6Xmz+U+kqdTYcc9vEZ1Fq5q3S+6fvtfQs472BoaPYWxn7uTmcaJ3Q qfOJGOX9WONhfSjyswD/5OCmN5ODN7GqPUjh1z8Lj0knHbDerSM/8mb188n3h1UlrD0F XxG7+8zTAmnBTUkeICaN7y4F0eIDRmBKgjhIcgQZf0QbMhcSG5zmOPlzmV/MfI4TBkIB y/sg== X-Gm-Message-State: AOJu0YxfuFGQaff5n9w+NzeZraS8wWvVQcVIOByF0hYK5jftgN42bEFR kjfxvvYEhbkb+a8LjztySE3ZwZo+mLUydvgT6cP2ojdQWNSzJl0RsNw= X-Google-Smtp-Source: AGHT+IGl8pp8s5CkOKWBocu4iX76nbaCzmr5bPCGHlHQH2zwvKfeWKu/Av2+KBb1poEJRid0gbcY/owdMjeE1ZHB5Ms= X-Received: by 2002:a17:907:6096:b0:a26:8f29:f7d7 with SMTP id ht22-20020a170907609600b00a268f29f7d7mr2088492ejc.88.1703172965410; Thu, 21 Dec 2023 07:36:05 -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: Warner Losh Date: Thu, 21 Dec 2023 08:35:54 -0700 Message-ID: Subject: Re: symlink to /boot/loader.efi To: Jeffrey Bouquet Cc: Nuno Teixeira , Dimitry Andric , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000983806060d06db28" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwvfJ1wNpz3FhG --000000000000983806060d06db28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2023, 8:18=E2=80=AFAM Jeffrey Bouquet wrote: > I am wondering if all the information in this thread present and future > should be included in > the scenarios at the bottom of /usr/ports/UPDATING with technical > explanations about > how and why? AFAIK the file was created before UEFI and thus in that > regard obsolete. There is more info on updating noe on the man pages, but we likely aren't there yet. A note in UPDATING sounds like a great idea. Warner On Thu, 21 Dec 2023 12:59:54 +0000, Nuno Teixeira > wrote: > > > Hello Dimitry, > > > > For a moment I forgot that efiboot is a fat system... > > I am inspired on what installworld does to kernel and kernel.old. > > I was thinking in something like it but with efi boot, something > automatic. > > > > Thanks! > > > > Dimitry Andric escreveu no dia quinta, 21/12/2023 =C3= =A0(s) > > 12:48: > > > > > On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > > > > > > > On every current upgrade I update efi/freebsd/loader.efi (amd64) an= d > > > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > > > For safety reasons I always have a copy of last running loader by > > > appending "-old.efi" to loader or boota64 and use beinstall to get BE= s > if > > > needed. > > > > > > > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> > > > /boot/loader.efi ? > > > > > > Symlinks do not work on FAT file systems, so I assume you mean a > symlink > > > placed in /boot (assuming that is UFS or ZFS), which points to > > > /boot/efi/efi/freebsd? > > > > > > At the moment I think installworld would not write 'through' such a > > > symlink. In fact, it makes a hard link from /boot/loader_lua.efi to > > > /boot/loader.efi, unlinking any previous /boot/loader.efi. > > > > > > That said, it would be nice to have some sort of semi-official way of > > > upgrading the real EFI loader through installworld. It would probably > > > require some top-level Makefile magic. > > > > > > -Dimitry > > > > > > > > > > -- > > Nuno Teixeira > > FreeBSD Committer (ports) > > > > --000000000000983806060d06db28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Thu, 21 Dec 2023 12:59:54 +0000, Nuno Teixeira <eduardo@freebsd.org<= /a>> wrote:

> Hello Dimitry,
>
> For a moment I forgot that efiboot is a fat system...
> I am inspired on what installworld does to kernel and kernel.old.
> I was thinking in something like it but with efi boot, something autom= atic.
>
> Thanks!
>
> Dimitry Andric <dim@freebsd.org> escreveu no dia quinta, 21/12/= 2023 =C3=A0(s)
> 12:48:
>
> > On 21 Dec 2023, at 13:22, Nuno Teixeira <eduardo@freebsd.org<= /a>> wrote:
> > >
> > > On every current upgrade I update efi/freebsd/loader.efi (am= d64) and
> > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > > For safety reasons I always have a copy of last running load= er by
> > appending "-old.efi" to loader or boota64 and use beins= tall to get BEs if
> > needed.
> > >
> > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader= .efi ->
> > /boot/loader.efi ?
> >
> > Symlinks do not work on FAT file systems, so I assume you mean a = symlink
> > placed in /boot (assuming that is UFS or ZFS), which points to > > /boot/efi/efi/freebsd?
> >
> > At the moment I think installworld would not write 'through&#= 39; such a
> > symlink. In fact, it makes a hard link from /boot/loader_lua.efi = to
> > /boot/loader.efi, unlinking any previous /boot/loader.efi.
> >
> > That said, it would be nice to have some sort of semi-official wa= y of
> > upgrading the real EFI loader through installworld. It would prob= ably
> > require some top-level Makefile magic.
> >
> > -Dimitry
> >
> >
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)



--000000000000983806060d06db28-- From nobody Thu Dec 21 23:21:00 2023 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 4Sx5yw3Tyrz54Pqy for ; Thu, 21 Dec 2023 23:21:12 +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 4Sx5yv64pvz4ZD3; Thu, 21 Dec 2023 23:21:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 3BLNL06T075539; Fri, 22 Dec 2023 08:21:01 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 22 Dec 2023 08:21:00 +0900 From: Tomoaki AOKI To: Dimitry Andric Cc: Nuno Teixeira , FreeBSD CURRENT Subject: Re: symlink to /boot/loader.efi Message-Id: <20231222082100.4c9b0220ef15180ad2ff36df@dec.sakura.ne.jp> In-Reply-To: <90AA5680-49A9-4630-80EF-0580E8F31EA2@FreeBSD.org> References: <631DF939-4E18-4319-BE94-335E63B27B09@FreeBSD.org> <90AA5680-49A9-4630-80EF-0580E8F31EA2@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sx5yv64pvz4ZD3 On Thu, 21 Dec 2023 14:22:14 +0100 Dimitry Andric wrote: > Yeah, my procedure is the same as yours: I first copy /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then copy the freshly built and installed /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this could not be just another step in the installworld procedure. > > That said, I am unsure if the pathname /boot/efi/efi is always the same, at least for all UEFI systems. It is the default layout when you do a regular install with recent installer onto a UEFI system, but some users may use completely different mount points. So you should still have some way of configuring the default location for loader installation. > > Also, on default installations a fallback entry named /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of loader.efi but with a different name. Namely, the default name that UEFI (on x86_64 at least) searches for, if it doesn't know anything else. I.e. if it isn't configured via efibootmgr(8), or the EFI variables have been junked for some reason. It might make sense to also update that file. > > -Dimitry Just an idea. It would be nice if loader.efi (hopefully, boot1.efi,too) could pass "where am I placed?" info, maybe via kenv. Would need boot1.efi to pass something (ideally, "where am I booted from?", but "boot1_used=1" is sufficient). To do so, loader.efi can confirm whether it was loaded via boot1.efi or directly from UEFI firmware. If nothing is passed to it, it can probe "where it is?" using UEFI call and set it, otherwise, it should be /boot/loader.efi, so nothing is needed to do. If no related kenv is set and freebsd-boot partition exists, it should be booted with legacy (BIOS) boot. The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI device path. So would need analyzing where actually is on booted FreeBBSD environment. > > > On 21 Dec 2023, at 13:59, Nuno Teixeira wrote: > > > > Hello Dimitry, > > > > For a moment I forgot that efiboot is a fat system... > > I am inspired on what installworld does to kernel and kernel.old. > > I was thinking in something like it but with efi boot, something automatic. > > > > Thanks! > > > > Dimitry Andric escreveu no dia quinta, 21/12/2023 à(s) 12:48: > > On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > > > > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > > For safety reasons I always have a copy of last running loader by appending "-old.efi" to loader or boota64 and use beinstall to get BEs if needed. > > > > > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> /boot/loader.efi ? > > > > Symlinks do not work on FAT file systems, so I assume you mean a symlink placed in /boot (assuming that is UFS or ZFS), which points to /boot/efi/efi/freebsd? > > > > At the moment I think installworld would not write 'through' such a symlink. In fact, it makes a hard link from /boot/loader_lua.efi to /boot/loader.efi, unlinking any previous /boot/loader.efi. > > > > That said, it would be nice to have some sort of semi-official way of upgrading the real EFI loader through installworld. It would probably require some top-level Makefile magic. > > > > -Dimitry > > > > > > > > -- > > Nuno Teixeira > > FreeBSD Committer (ports) -- Tomoaki AOKI From nobody Fri Dec 22 09:09:12 2023 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 4SxM1g0HYtz5506Q for ; Fri, 22 Dec 2023 09:09:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.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 4SxM1d6bPzz4JBr for ; Fri, 22 Dec 2023 09:09:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FHyTC0J8; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703236163; bh=QtfF28HO3ICdiD+ZPauuUUL19PcF6ecB1HSiaHUokGA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=FHyTC0J89a/nzYzoseVxyocxVhdcnpuWxUmS9zHxKGwZlB8gJiemD7phx9x2HOBF6OkklDMcjTgY6vAP9lo5iEGCYbdWn/Q54FldViwTybUBPEzDnlzjj7jw9yLaeRbK8kT392wOg7vyL75DRr+/h/HkSh/6j0v6kTOcv4IrsLYUfULobevu00uf22lxI+7dBQAZJkQ+dJCyVCoXJRQnR6kEEOYE7v3q26Usgipp65QjzuArBMsFqS7Mu1UXghnSAKDQec2eGlXfErMYVA6ss7yk/PvyL4tR8AB/M0QD9lGukQFUEGsrn2yx9c8TohrRBu409d0ZSb9ZuYu30zK9zQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703236163; bh=QOLVFyVJcTZb7zzDuiMouPdSROOOI1t9jLqekZw6eqZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hroX3F4J/D+v1WLOlQCoN1s67MxLxs9SL0bVNKJJ+eAL5gxmTGbksp592NxtLcAr1sxw1bx7VQmQ+TyuKb7DTCG5O9Txno1Ksj1rNMY9iy7i7Crq9PdP7wwmsq6UnQYv6ib3m4+wfQA780cGScHOTk2vKYCZISu78Z7ypZQJsV+KslFPcOwwutY8CtcfYnfML+6zqoEehgCn8HYr7vdjwjiRXW+mcQIyTntsU02aj1zyaIdCO5EjihemjAiF2EAtSknKHiKb+QMFe2axAuNVYA2Sr7x/SaA/k6UmpEwHFRL6mFw7PuyIjr15eZ3MhLGa24/EY++n2vh0giawMsRpdw== X-YMail-OSG: d6YLH7kVM1l9CZ.ajADVwh2zmE4NR23hWfJdU3oCw5XGvP1CBCat0WEcjFfvkZE VAh3DwCUAwv2m3DdP9YH9Op2zrvVRSbNlAjeYDihJyFxltbLyT5qz20E8pX1HXRhmso623Z_bKy4 sJZJcmPU8uTlMpCUPRNbe8s3Yj0EEyMo8YX8WxZ8iM5imHseDuqcdAtZF.MKXNcATgs40Q3OghTM F89zxJavKe07rwshLfclOkYNtm5b5_ToIiJwPHhXvJcmIfKiityNcsrvbBIOfgSRMx78hOwGBbOU jZgcEosLY6OEIbhbS1PnFRPOcbQAZubUuUVwgb6zAnE1ElbgQAHRy9krByzGC86CVM5gaBZLztJR FpF30404vFyDVW5m8sgDDXO2Zsh1KAOJO9.R91wDCjL1gkZ21ZjtWsHrbarvNdZJ64HgYTM5oG1P ZTawI0WYSPiatj4D_vMVTDTZ.eTFlVvp4OwovwKJEDmv100KDI0.JIuYgtt_Q8sKvEgelv7DMQGh oR_1LAVXhHBXP4DApfPo5DntUU1pYISjgUxKD0bS9lsPb7YwUb0WQZusnsYt6vs4OW2JuCPs.iX5 rTqG2fjjyMlwp5Rzpk7CPqYHqUi0mwXd3NnMUJRAj2z60Lmuk_sGfM3KTavsSh.biKBWtU1L6EEf htdYkFaoTCJ8WIQxhGZLQrwnRszZotjA2dKwAbvLcr1jJ3LU3_zGOIbvSh3U._M_Uidbuo7LnKGX HcCVZ3tVCzaBjm1QBuQXOECroy0SKmMCnUJKh1z.pg.zV2MYVfwi8Q8AXw9Td6jxRpNNdWGj5vYv 8LE2jCIuYhe6bTm2XbPFWBYN3a_8yii7E0c2pZGofMGkQc8T4FGzhGQrOJbkpROb2vjt_efRexWA 3aC9gDLx4WRQHZEhRGeYNtIOddqtemoJNdYTEwImNn8nATfoyJeo6nxvuahYGQ084ZRzA6GJAqla ZN8wg1vEqNzBLb5jFFedM0uzXRueIlz_gi4Wy56FB6IGJfm2XPjuDbQ.F_Yxq80IEKj7RUHU4gj7 4GFQaPePOETSK.RCPioMZUs2oYlqiSM7scqzelRIe5j7ENHAwKH0HW7Ik_74tFo7xpaekZKHhKot XPzZ.luw7f9.PtDtsi9V96O3OUAKBVmT7S1_rS.DHxbsDduZz6Vat8BUS_VX5wwVgfZr0JsGCibb kaIQqPfmxKVb4FMaysdhagUpQkJQ59EAgZtCLtQP.0WV7oClcwZZt.WoksF9HNl0BSp9o.5W8PgS ni_aENYzJqXHEz7ujtXy5feGpVeP1kNP.e_argCRlRXjB9uUz1u0PzOEyG6wCbryr57JX6GD2XHz ZEMB3D_J04qh5V3WyBzESwUh7kIzmOkLTIj_w4_Is9hTUOkSPj2uC0aFwmn9Qawirc6rw.xmwnFW LoFZsXm4Y42PHbcPRTEFfwzeII0nIIIib_yNg8TF9GqjQpFypavVSzbVMQdkvOfQfQDYBlWBjcmS PbUiSwkuIZXTmkK4JXy6kFXZj6bUXCofXH6y.uUDhO6K._K7sh1swst7Pn8z0R3J72ttHMUvvR7p NiiqJx74Ky4BYOwB2VtrjKW_A7qEhaaZfpVBI1SfaKNtia3Yc_FMFuVjpz9mVFq3io_W0LC76BYs 3.Uby_PLFTU1aBiYka.FuPehRZ6LJsCjSrdEngw.VP7VWrToM8Xawn3ATd.17WMvprrkKfcKSQ4b dIYQ1suUkaBj9.hTeoFcJi6bfiI2ro_99UrkSLBGk5Zs09nNh8cXkg9NLCPu0i7WPV8pB1ZC3sSk 3RuNvvu_Wpfu3sQGKBBR2fXOBu0iAy2P5BwL5AbxzdmYl.63sLBXj504FXKQmzQ1rI3jinZW3SKw aZ9QJMFJTmo6A_AoCbkKSSvWDM_K3995OnPp4XDfG_FazVT8fNo.OvjOyazYdgcmAyAoNzwEi0p7 HrC1HJufVGDp0cEWaIYrx7vOWzuw1FNgQojSIy0yembLffa1qjZVAKFWpSbF3eosFbhpwxq2VeEs 2Zrwn52Cb0j4Fixi0LzPdSjZVGoiIe03gNbrtpp8msbxQIDlNZ4ZOoJ6p9phqhPTOrGxf9PMM5a. FFSo2X02uw6hQUYZXyzkVr.lMX.R.0nF88shrv3tgMOWN9YBrBg4rIqiiY8nZoTBQomqAtaXCvNU QwghX8aJPR4HsvJSQ9qu9nJTxAqOZTu6xCyk1fwIgpD.Otr0Og6WaToilByC7QWRI_YQun1z6df2 iFJ97RtLZr8GkAu68rX0KruaGin1kia_wTa.WoLKJRaMPyTOh44Qntzvd8Lo9wbaqg0Sd0iVRbnY 2HA-- X-Sonic-MF: X-Sonic-ID: f3933671-ff4e-46b2-8d4c-4e46bc68f08a Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Dec 2023 09:09:23 +0000 Received: by hermes--production-gq1-6949d6d8f9-ghhkt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 78026209010c5c58cd08f76aef538544; Fri, 22 Dec 2023 09:09:23 +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 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi Message-Id: Date: Fri, 22 Dec 2023 01:09:12 -0800 To: Tomoaki AOKI , Current FreeBSD X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SxM1d6bPzz4JBr X-Spamd-Bar: --- Tomoaki AOKI wrote on Date: Thu, 21 Dec 2023 23:21:00 UTC : > On Thu, 21 Dec 2023 14:22:14 +0100 > Dimitry Andric wrote: >=20 > > Yeah, my procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld procedure. > >=20 > > That said, I am unsure if the pathname /boot/efi/efi is always the = same, at least for all UEFI systems. It is the default layout when you = do a regular install with recent installer onto a UEFI system, but some = users may use completely different mount points. So you should still = have some way of configuring the default location for loader = installation. > >=20 > > Also, on default installations a fallback entry named = /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of = loader.efi but with a different name. Namely, the default name that UEFI = (on x86_64 at least) searches for, if it doesn't know anything else. = I.e. if it isn't configured via efibootmgr(8), or the EFI variables have = been junked for some reason. It might make sense to also update that = file. > >=20 > > -Dimitry >=20 > Just an idea. >=20 > It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > "where am I placed?" info, maybe via kenv. >=20 > Would need boot1.efi to pass something (ideally, "where am I booted > from?", but "boot1_used=3D1" is sufficient). >=20 > To do so, loader.efi can confirm whether it was loaded via boot1.efi = or > directly from UEFI firmware. If nothing is passed to it, it can probe > "where it is?" using UEFI call and set it, otherwise, it should > be /boot/loader.efi, so nothing is needed to do. To my knowledge aarch64 and armv7 never use the copy in /boot/loader.efi during a boot. It has to have been copied into the appropriate msdosfs such that it has an appropriate path and name there. That is what is found and used during the boot. > If no related kenv is set and freebsd-boot partition exists, it should > be booted with legacy (BIOS) boot. If there even is a "legacy (BIOS) boot" is a platform specific issue as far as I know. > The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI > device path. So would need analyzing where actually is on booted > FreeBBSD environment. See the earlier point about aarch64 and armv7 not using /boot/* files while loading the FreeBSD loader: the FreeBSD loader variant used is the first stage able to look inside UFS or ZFS file systems. Loading and starting the FreeBSD loader happens before that stage in those types of contexts. > . . . Also, to my knowledge, powerpc (32-bit), powerpc64, and powerpc64le do not involve any variant of loader.efi or UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. Again: more platform specific rather than generic. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 22 09:36:24 2023 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 4SxMd35S3cz551dv for ; Fri, 22 Dec 2023 09:36:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-zteg06023901.me.com (mr85p00im-zteg06023901.me.com [17.58.23.192]) (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 4SxMd32xMZz4LtL for ; Fri, 22 Dec 2023 09:36:39 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1703237798; bh=T7cVNBoqlQtYnNbI0Bv8JUWWN9FJWQbn8HDopel3Exs=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=pI4TR7Tl05eK5HYyYLBQ9vZKIsgr7EISc9HCRh/JYvIIYXHF9sZJpWoAQHvahRjqc +tXKsZ7WC6huFkCx3gPODeOlkaboBgIEtIGb0S+4IiZKnCoD8KDqt3rVtwtqfZg4tJ pWVg6c4nIziJ4TySgDE1VQ2fbaClgOobnVTzAS36REG5GnEQ53ktfKved/E0c9ZJHU c/hIvwsbiICRh/Dc81n6epLKMXoCMsD8umdqxSBIDhzBmJ1gKcfkTpgJqLenoyyGw1 BmPnrIZ+Acpa1ImMQdvwoF5L2/QzBgqdyEaFPOdwaiMpCgkBBWuzZ/BZcAUlKpDPpz qpR82DQCRDVUQ== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06023901.me.com (Postfix) with ESMTPSA id 467206E01E9; Fri, 22 Dec 2023 09:36:37 +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 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi From: Toomas Soome In-Reply-To: Date: Fri, 22 Dec 2023 11:36:24 +0200 Cc: Tomoaki AOKI , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> References: To: Mark Millard X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Proofpoint-ORIG-GUID: SgFGJEoD6jIzb1F_viA2RyU6M8OFLG1P X-Proofpoint-GUID: SgFGJEoD6jIzb1F_viA2RyU6M8OFLG1P X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-22_04,2023-12-21_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 suspectscore=0 malwarescore=0 clxscore=1011 adultscore=0 mlxscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2312220068 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxMd32xMZz4LtL > On 22. Dec 2023, at 11:09, Mark Millard wrote: >=20 > Tomoaki AOKI wrote on > Date: Thu, 21 Dec 2023 23:21:00 UTC : >=20 >> On Thu, 21 Dec 2023 14:22:14 +0100 >> Dimitry Andric wrote: >>=20 >>> Yeah, my procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld procedure. >>>=20 >>> That said, I am unsure if the pathname /boot/efi/efi is always the = same, at least for all UEFI systems. It is the default layout when you = do a regular install with recent installer onto a UEFI system, but some = users may use completely different mount points. So you should still = have some way of configuring the default location for loader = installation. >>>=20 >>> Also, on default installations a fallback entry named = /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of = loader.efi but with a different name. Namely, the default name that UEFI = (on x86_64 at least) searches for, if it doesn't know anything else. = I.e. if it isn't configured via efibootmgr(8), or the EFI variables have = been junked for some reason. It might make sense to also update that = file. >>>=20 >>> -Dimitry >>=20 >> Just an idea. >>=20 >> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass >> "where am I placed?" info, maybe via kenv. >>=20 >> Would need boot1.efi to pass something (ideally, "where am I booted >> from?", but "boot1_used=3D1" is sufficient). >>=20 >> To do so, loader.efi can confirm whether it was loaded via boot1.efi = or >> directly from UEFI firmware. If nothing is passed to it, it can probe >> "where it is?" using UEFI call and set it, otherwise, it should >> be /boot/loader.efi, so nothing is needed to do. >=20 > To my knowledge aarch64 and armv7 never use the copy in > /boot/loader.efi during a boot. It has to have been copied > into the appropriate msdosfs such that it has an > appropriate path and name there. That is what is found > and used during the boot. All UEFI systems start from ESP (EFI System Partition). The only good = reason to install boot1.efi there is when you have very small ESP and = need to save that space - and in that case the boot1.esp will search and = execute /boot/loader.efi. The problem about boot1.efi (or any other UEFI chainload) is that = loading file and executing it will not replace current program in = memory, but will add new one, this may be problem with systems with = minimal memory configurations. And yes, boot1.efi is not really platform = specific - it is just another EFI application - one can build and use it = on arm (or any other) systems and then it will load and start = /boot/loader.efi. starting loader directly from ESP has few advantages =E2=80=94 you wont = waste memory for boot1.efi, you save a bit of boot time, you can use = auxiliary files from ESP to pass some information to loader.efi (for = example to tell where your rootfs is in case of multiboot setups). the boot1.efi could be a bit more appealing if it would be able to load = and start kernel directly, allowing to build very memory limited setups, = but then again, it does sound like very specific corner case. rgds, toomas >=20 >> If no related kenv is set and freebsd-boot partition exists, it = should >> be booted with legacy (BIOS) boot. >=20 > If there even is a "legacy (BIOS) boot" is a platform > specific issue as far as I know. >=20 >> The easiest to be set by loader.efi and/or boot1.efi would be raw = UEFI >> device path. So would need analyzing where actually is on booted >> FreeBBSD environment. >=20 > See the earlier point about aarch64 and armv7 not using > /boot/* files while loading the FreeBSD loader: the > FreeBSD loader variant used is the first stage able to > look inside UFS or ZFS file systems. Loading and > starting the FreeBSD loader happens before that stage > in those types of contexts. >=20 >> . . . >=20 > Also, to my knowledge, powerpc (32-bit), powerpc64, and > powerpc64le do not involve any variant of loader.efi or > UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > Again: more platform specific rather than generic. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20 From nobody Fri Dec 22 09:54:47 2023 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 4SxN2H1bKGz552gk for ; Fri, 22 Dec 2023 09:55:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxN2G4VMsz4PZB for ; Fri, 22 Dec 2023 09:55:02 +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=1703238899; bh=herQ+XvE7DaqLnRKjLSGx4NhECMJTrT3OrG5e/ymbQk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X217e19X2HTWS8wxppMyPpilp3VraroicZJU6scaEt8nYZRFs7AcUcAs9X/dG8SzKpU7a1zA6d0C5XFyaI9xSU0WriFUGNpfTXamkmwpE9WYSO2BvlmdNvbDf1G7GEoblAVxwT52SFb5JYgJZmY8ZSxI/ZMyDj2L3pl2XrsbB7X+Fn7ulkvKRe38nMKLAongHcUh2RYv4QeO/fC2VoDfv34JGuEu8wTcfDxZGrt0yQDA18D6uW+y+OkGffx7oBq3H3zWNijdxY8c0G4gHx4Dg3XKMwfX7UVO7KYfpXOXBGhprO02slvquUmJH4QOEKnyNZQf+l5lalRPnTLOKb7lHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703238899; bh=kA+fa+35i3cy2IY1vP5+eogTxZrsiP8aCFEqUefRd7b=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CJfdqbUKfRhFV2DvTt7rno0AhM4tRPhC782Vgx389rFVUY2wSADjULkCxAUAsFNpQEYb5L+4Ylfqsf0l1/WImTxUTPvB1e38YIlVCdZ4cX135XyzuZEGUguc3VJeBxNo3UH/O3FUOtWLoBisnKKpMqcgh03qS7OrA4ahq1tq1bZ1nJhz+IU4kke72OemD+O8VwDkQ2CL+E99GV3FO32fVoft6fuyTw6m7EDtvsKce/MmU/Uqhv9IIcgDPEtawXP6ipnVT7V5eM3JF02hIwzGTklMFmgoJWXgJua7b57FEFaThiV/1gXEqAe/SSivQIYTh3BmsrXmMdAmvYBnpfev6w== X-YMail-OSG: F3WkGsQVM1nt3cyx09tNQlg3AODHkerGS_5cp.gGhVAk_BiMGdMRny577B6e5GI h_mj4XjJysS_qJ2_jSNlbHLaiQz9.j2GTB7GZRPU4a.RlxeZ3teBDfXSSjxjrvkk.Ou9iJxa0a2x SR61IKB2PgR60gZiMERxmoI1eDTigDzRGnCj34axWjWCPqJPEoKRkx1B4fGbCYwbcFxmayJugwGa 5BMwIBl2h1d_P8ey355hy_oj9b4L6_cObIp8JciNPiLZzCRJp.gUcztGUoBaMEOO7D7iywQKpqy8 1aODre2wZIas8NbLBynl3yCe46MKqYTUWhEFYBhUqgy9CRiVe87UW3hivv8LYk9xg7go6Tk1hUa4 XABc5kVX5lAapWDc_oARC38cDMzF6n.uciDL6mL0ZrbZ.0KMgsOXupcar6XJQmYr7iKOaZShpEkK D4ELlCBe3Y2vGn2DN3P4lOUbMJoz5nMRNnMz69di5EK53y1aItOlSvpqNDiS1RLBzl_qqNfS.lM9 g_vIm2Do6i3XHPSCHqQ.eXPBrahMdYIBV6R8UdWLlorEyRhh2edVHfx7JLkDSXluEgyS_I14SBud vJXF9Du.Je18GiC_nCMmFRPRPfYspbYKoeedgpSbkpZBUeGseziruvchVCf0U_RcN9XbyvUYr5HG 3p6QbduJPcgFj0II6McAhHEtasvBTNbrMYR1dNuafXGrNvNtv4VgLZ5svoTfdCriC22.mSsrZy0L yZElM_wvdWJRh20UlBV8JBrVtEuUoIA4xO1jQ35GgePurUlASqlFHAGgxeRQwrK3lRoYNDNTZh49 EVn6E8tGtgNKdC1bTamBMgwsi3z_RM5zmgHrnPG38vbkWNRx6ePXBBomxRexRtR_04Rc1pnzOAtr TpITXugssnCGCUbAZDtzw9TI4wmZ7ssSYi4CqLEFNVQ85lgYK6PXZh4rAPWbftum_o9knPaAKNXr fwSHADepi6p0A2o_EpniKFy32qkefttJq0F.09gELNWWmnQ57JOxeKWQC6VNjwcsI_nKG4THxbyu PrkBedRSS_Y_Hz4WWhU.wmxeKaYg8X4exq7ZBDckX2flOfCIOB4bcI.9DpzmXKWtMIiYa2u3Om5h Tk218dOB0Gdh15XUW2Pz6_P6.Pg71Gae__gvrqb37nZSXUKlqVMXUyo6fSs29BzhGxANKHdVzB6j MDnsKWX0xN_HGmJGwpN7bYsRiOaX4Lmm7uoi7XEFqDcPLPpkuma38IQCUmUt1l6uj6jWuuan6X6V 1siujArO0mEdVjxOf00THCm6goDjIwTMLolXk.h1.a0PN8XapXXdJh27r.pzlP7wmsxc0zyy8jIH FZLbz2riYEh4qqrYC3mbcxZxAWfuSixpuinYP4zZvBxFl5Ja6w_zc_3HSVxINrv4zzkuDPAoJN7c qz0JoYBOeqnSb2tp2Zmet3TaAch_3gAE0qGJCqdLPRj1_tW5kZjl1v0qH_KolrPs3eSuKKr2khp5 SoSkYktpAFTf6FCANj7_TolWSD_kQw7bzj9cEJMdp.YPESR_LscnVk7tnLC6e0_9FWZsCIL24WsM xCaAZM3cMnM9BzcTYjHB.ZJ76TcrFd61POpachk_czmTDy0CZUX2i06EN2IUZMJgcRQVTT1OfbuS lgRNXceisbaUWnMCi6Zerjqrfbo3dk24RWVfNVZogkLuZ3QIzJIhg9mMb..DxzZLrP5jYgVbT3HN PO1pSc61d.BSg8zdT6Igrs2YyA6ay8B0UYqi3Bc1iancxC2EGNK_P4GJPeD_TaCvwk8NWTosHYSg 9elnLBHfFGn3V3VyqEq.V48BkMZae.EiiqNEsAcX.EUVkH3qHfz86Rk9KXAAePUiwXD9F8v0If_y yw.menW1nFbZMYCQRVbprI4Nk_9.OWeB98sAsoE3Gq2X2paSv4FYvjzvnMIveqy3NTphv5fZHwJI 0PIkNrCVq8VwXXGIrbYEBVw_yD0J8yXyeTkofkuolcnmJpCxGnvk9YWhZrWpAshsaAPG8cgdwjwe 1M86SKoXrwfcDqsLJdiGj.XcOrCN43KG2FQOU2Z9fFDGy.mWIXigambsC452MXNHcXCUpyKxKGNa qHBXLaShA32mJN4y5UUmWpAeLL7Gyuqf3skGyEA1yCAbsqQzyJoyn.7vhH1I0B10QrL5Kc9rJB8_ OJpE8zHU6b4JdpmyEL.vF5BCWHk8yJmWbi2UnytFzJrvKtbK07HPhPlKRoAVmbIp81QL08.2yIkj JlWmiTbSYtJXQHCjNXWILQubUNeBGRLahTcA66LiMBMhdDqlycuXIzmFZ9H29AX20zB7npJMnhj2 D.g-- X-Sonic-MF: X-Sonic-ID: 4eff05b3-e9e2-4559-b234-cf0722c0a584 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Dec 2023 09:54:59 +0000 Received: by hermes--production-gq1-6949d6d8f9-47mhb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 42a26158befc0d86a25cc63eba2c6c5b; Fri, 22 Dec 2023 09:54:58 +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 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi From: Mark Millard In-Reply-To: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> Date: Fri, 22 Dec 2023 01:54:47 -0800 Cc: Tomoaki AOKI , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> To: Toomas Soome X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxN2G4VMsz4PZB On Dec 22, 2023, at 01:36, Toomas Soome wrote: >=20 >=20 >=20 >> On 22. Dec 2023, at 11:09, Mark Millard wrote: >>=20 >> Tomoaki AOKI wrote on >> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>=20 >>> On Thu, 21 Dec 2023 14:22:14 +0100 >>> Dimitry Andric wrote: >>>=20 >>>> Yeah, my procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld procedure. >>>>=20 >>>> That said, I am unsure if the pathname /boot/efi/efi is always the = same, at least for all UEFI systems. It is the default layout when you = do a regular install with recent installer onto a UEFI system, but some = users may use completely different mount points. So you should still = have some way of configuring the default location for loader = installation. >>>>=20 >>>> Also, on default installations a fallback entry named = /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of = loader.efi but with a different name. Namely, the default name that UEFI = (on x86_64 at least) searches for, if it doesn't know anything else. = I.e. if it isn't configured via efibootmgr(8), or the EFI variables have = been junked for some reason. It might make sense to also update that = file. >>>>=20 >>>> -Dimitry >>>=20 >>> Just an idea. >>>=20 >>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass >>> "where am I placed?" info, maybe via kenv. >>>=20 >>> Would need boot1.efi to pass something (ideally, "where am I booted >>> from?", but "boot1_used=3D1" is sufficient). >>>=20 >>> To do so, loader.efi can confirm whether it was loaded via boot1.efi = or >>> directly from UEFI firmware. If nothing is passed to it, it can = probe >>> "where it is?" using UEFI call and set it, otherwise, it should >>> be /boot/loader.efi, so nothing is needed to do. >>=20 >> To my knowledge aarch64 and armv7 never use the copy in >> /boot/loader.efi during a boot. It has to have been copied >> into the appropriate msdosfs such that it has an >> appropriate path and name there. That is what is found >> and used during the boot. >=20 >=20 > All UEFI systems start from ESP (EFI System Partition). The only good = reason to install boot1.efi there is when you have very small ESP and = need to save that space - and in that case the boot1.esp will search and = execute /boot/loader.efi. Yep. May be I misinterpreted what the text strongly tied to "it should be /boot/loader.efi" and so ended up not pointing out an actual distinction. > The problem about boot1.efi (or any other UEFI chainload) is that = loading file and executing it will not replace current program in = memory, but will add new one, this may be problem with systems with = minimal memory configurations. And yes, boot1.efi is not really platform = specific - it is just another EFI application - one can build and use it = on arm (or any other) systems Not powerpc (32-bit), powerpc64, or powerpc64le: these are not UEFI systems at all, if I understand right. Of course, if only tier 1 is documented, such would not be covered. But documentation that is limited to tier 1 should say so explicitly --but various examples have historically not done so. > and then it will load and start /boot/loader.efi. >=20 > starting loader directly from ESP has few advantages =E2=80=94 you = wont waste memory for boot1.efi, you save a bit of boot time, you can = use auxiliary files from ESP to pass some information to loader.efi (for = example to tell where your rootfs is in case of multiboot setups). >=20 > the boot1.efi could be a bit more appealing if it would be able to = load and start kernel directly, allowing to build very memory limited = setups, but then again, it does sound like very specific corner case. Thanks for the UEFi-context notes that go well beyond anything I referenced. Good stuff. > rgds, > toomas >=20 >=20 >>=20 >>> If no related kenv is set and freebsd-boot partition exists, it = should >>> be booted with legacy (BIOS) boot. >>=20 >> If there even is a "legacy (BIOS) boot" is a platform >> specific issue as far as I know. >>=20 >>> The easiest to be set by loader.efi and/or boot1.efi would be raw = UEFI >>> device path. So would need analyzing where actually is on booted >>> FreeBBSD environment. >>=20 >> See the earlier point about aarch64 and armv7 not using >> /boot/* files while loading the FreeBSD loader: the >> FreeBSD loader variant used is the first stage able to >> look inside UFS or ZFS file systems. Loading and >> starting the FreeBSD loader happens before that stage >> in those types of contexts. >>=20 >>> . . . >>=20 >> Also, to my knowledge, powerpc (32-bit), powerpc64, and >> powerpc64le do not involve any variant of loader.efi or >> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. >> Again: more platform specific rather than generic. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 22 10:02:54 2023 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 4SxNCg0qzNz5537T for ; Fri, 22 Dec 2023 10:03:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (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 4SxNCf5RR3z4RHd for ; Fri, 22 Dec 2023 10:03:10 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1703239388; bh=9qJJ1Ca06mpqvwsIHFJ3D5ZMN2J6VHIZxmgp4Im5YiU=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=KAQ5XRFhf8yue+uZrdlo3xPUIP7tABp2KmqcGDy6iy8xARe6BZYWNIFagGYycMYYo RXeV+1sxuLolyJWlUnNbzLzZ/yFe7a21VQNxWRIOlOM6C0eJ3+UfxE3cjXBL+4JRxf Cb46+RZhU8a9kqG52ZBdbjIZ2h2YU3yLNDfhhtjMFdxeL7EG0qwSzqizjXtjqf5r+J 9CrF1Vtsz3DcUeKA/jgXPs3Go6ad+D7mw5E3Tuf2EoHbJ+fd5eUZbTg4eyhv+gJlOO gahQgp+I8Ma8NXMl2bU4yDqgf5/UHmqFiR8MPBA6bW+qH9ytDMcl6Go2bpPwFkfO5+ OD+9rU/dTnMLw== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id 355913058416; Fri, 22 Dec 2023 10:03:07 +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 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi From: Toomas Soome In-Reply-To: <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> Date: Fri, 22 Dec 2023 12:02:54 +0200 Cc: Tomoaki AOKI , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Proofpoint-ORIG-GUID: qBLBzdLKdjBtZsMJaHV_gJLvOEdBIWyv X-Proofpoint-GUID: qBLBzdLKdjBtZsMJaHV_gJLvOEdBIWyv X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-22_05,2023-12-21_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 spamscore=0 phishscore=0 clxscore=1015 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2312220072 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxNCf5RR3z4RHd > On 22. Dec 2023, at 11:54, Mark Millard wrote: >=20 > On Dec 22, 2023, at 01:36, Toomas Soome wrote: >>=20 >>=20 >>=20 >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: >>>=20 >>> Tomoaki AOKI wrote on >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>>=20 >>>> On Thu, 21 Dec 2023 14:22:14 +0100 >>>> Dimitry Andric wrote: >>>>=20 >>>>> Yeah, my procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld procedure. >>>>>=20 >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the = same, at least for all UEFI systems. It is the default layout when you = do a regular install with recent installer onto a UEFI system, but some = users may use completely different mount points. So you should still = have some way of configuring the default location for loader = installation. >>>>>=20 >>>>> Also, on default installations a fallback entry named = /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of = loader.efi but with a different name. Namely, the default name that UEFI = (on x86_64 at least) searches for, if it doesn't know anything else. = I.e. if it isn't configured via efibootmgr(8), or the EFI variables have = been junked for some reason. It might make sense to also update that = file. >>>>>=20 >>>>> -Dimitry >>>>=20 >>>> Just an idea. >>>>=20 >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could = pass >>>> "where am I placed?" info, maybe via kenv. >>>>=20 >>>> Would need boot1.efi to pass something (ideally, "where am I booted >>>> from?", but "boot1_used=3D1" is sufficient). >>>>=20 >>>> To do so, loader.efi can confirm whether it was loaded via = boot1.efi or >>>> directly from UEFI firmware. If nothing is passed to it, it can = probe >>>> "where it is?" using UEFI call and set it, otherwise, it should >>>> be /boot/loader.efi, so nothing is needed to do. >>>=20 >>> To my knowledge aarch64 and armv7 never use the copy in >>> /boot/loader.efi during a boot. It has to have been copied >>> into the appropriate msdosfs such that it has an >>> appropriate path and name there. That is what is found >>> and used during the boot. >>=20 >>=20 >> All UEFI systems start from ESP (EFI System Partition). The only good = reason to install boot1.efi there is when you have very small ESP and = need to save that space - and in that case the boot1.esp will search and = execute /boot/loader.efi. >=20 > Yep. May be I misinterpreted what the text strongly tied to > "it should be /boot/loader.efi" and so ended up not pointing > out an actual distinction. >=20 >> The problem about boot1.efi (or any other UEFI chainload) is that = loading file and executing it will not replace current program in = memory, but will add new one, this may be problem with systems with = minimal memory configurations. And yes, boot1.efi is not really platform = specific - it is just another EFI application - one can build and use it = on arm (or any other) systems >=20 > Not powerpc (32-bit), powerpc64, or powerpc64le: these are > not UEFI systems at all, if I understand right. Yes, building EFI application implies platform with UEFI support.=20 rgds, toomas >=20 > Of course, if only tier 1 is documented, such would not be > covered. But documentation that is limited to tier 1 should > say so explicitly --but various examples have historically > not done so. >=20 >> and then it will load and start /boot/loader.efi. >>=20 >> starting loader directly from ESP has few advantages =E2=80=94 you = wont waste memory for boot1.efi, you save a bit of boot time, you can = use auxiliary files from ESP to pass some information to loader.efi (for = example to tell where your rootfs is in case of multiboot setups). >>=20 >> the boot1.efi could be a bit more appealing if it would be able to = load and start kernel directly, allowing to build very memory limited = setups, but then again, it does sound like very specific corner case. >=20 > Thanks for the UEFi-context notes that go well beyond anything > I referenced. Good stuff. >=20 >> rgds, >> toomas >>=20 >>=20 >>>=20 >>>> If no related kenv is set and freebsd-boot partition exists, it = should >>>> be booted with legacy (BIOS) boot. >>>=20 >>> If there even is a "legacy (BIOS) boot" is a platform >>> specific issue as far as I know. >>>=20 >>>> The easiest to be set by loader.efi and/or boot1.efi would be raw = UEFI >>>> device path. So would need analyzing where actually is on booted >>>> FreeBBSD environment. >>>=20 >>> See the earlier point about aarch64 and armv7 not using >>> /boot/* files while loading the FreeBSD loader: the >>> FreeBSD loader variant used is the first stage able to >>> look inside UFS or ZFS file systems. Loading and >>> starting the FreeBSD loader happens before that stage >>> in those types of contexts. >>>=20 >>>> . . . >>>=20 >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and >>> powerpc64le do not involve any variant of loader.efi or >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. >>> Again: more platform specific rather than generic. >>>=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 From nobody Fri Dec 22 14:07:45 2023 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 4SxTfJ1Wgxz55G9M for ; Fri, 22 Dec 2023 14:08:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxTfH4qyKz3Dk9 for ; Fri, 22 Dec 2023 14:08:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 3BME7lSv012274; Fri, 22 Dec 2023 16:07:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3BME7lSv012274 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 3BME7jWE012272; Fri, 22 Dec 2023 16:07:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Dec 2023 16:07:45 +0200 From: Konstantin Belousov To: Toomas Soome Cc: Mark Millard , Tomoaki AOKI , Current FreeBSD Subject: Re: symlink to /boot/loader.efi Message-ID: References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxTfH4qyKz3Dk9 On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > Tomoaki AOKI wrote on > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > >> Dimitry Andric wrote: > >> > >>> Yeah, my procedure is the same as yours: I first copy /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then copy the freshly built and installed /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this could not be just another step in the installworld procedure. > >>> > >>> That said, I am unsure if the pathname /boot/efi/efi is always the same, at least for all UEFI systems. It is the default layout when you do a regular install with recent installer onto a UEFI system, but some users may use completely different mount points. So you should still have some way of configuring the default location for loader installation. > >>> > >>> Also, on default installations a fallback entry named /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of loader.efi but with a different name. Namely, the default name that UEFI (on x86_64 at least) searches for, if it doesn't know anything else. I.e. if it isn't configured via efibootmgr(8), or the EFI variables have been junked for some reason. It might make sense to also update that file. > >>> > >>> -Dimitry > >> > >> Just an idea. > >> > >> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > >> "where am I placed?" info, maybe via kenv. > >> > >> Would need boot1.efi to pass something (ideally, "where am I booted > >> from?", but "boot1_used=1" is sufficient). > >> > >> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > >> directly from UEFI firmware. If nothing is passed to it, it can probe > >> "where it is?" using UEFI call and set it, otherwise, it should > >> be /boot/loader.efi, so nothing is needed to do. > > > > To my knowledge aarch64 and armv7 never use the copy in > > /boot/loader.efi during a boot. It has to have been copied > > into the appropriate msdosfs such that it has an > > appropriate path and name there. That is what is found > > and used during the boot. > > > All UEFI systems start from ESP (EFI System Partition). The only good reason to install boot1.efi there is when you have very small ESP and need to save that space - and in that case the boot1.esp will search and execute /boot/loader.efi. > No, this is not the only good reason, or even the least important reason. boot1.efi is extremely convenient for the normal (*) configuration where machine is dedicated for a single FreeBSD system. It finds and chain-load real loader.efi from the first UFS GPT partition which I always assign to the root. This means that I do not need to care about updating loader.efi at all, it is done during normal installworld. * at least for me I use this setup for >5 years on all my disk-booting machines. > The problem about boot1.efi (or any other UEFI chainload) is that loading file and executing it will not replace current program in memory, but will add new one, this may be problem with systems with minimal memory configurations. And yes, boot1.efi is not really platform specific - it is just another EFI application - one can build and use it on arm (or any other) systems and then it will load and start /boot/loader.efi. > > starting loader directly from ESP has few advantages — you wont waste memory for boot1.efi, you save a bit of boot time, you can use auxiliary files from ESP to pass some information to loader.efi (for example to tell where your rootfs is in case of multiboot setups). > > the boot1.efi could be a bit more appealing if it would be able to load and start kernel directly, allowing to build very memory limited setups, but then again, it does sound like very specific corner case. > > rgds, > toomas > > > > > >> If no related kenv is set and freebsd-boot partition exists, it should > >> be booted with legacy (BIOS) boot. > > > > If there even is a "legacy (BIOS) boot" is a platform > > specific issue as far as I know. > > > >> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI > >> device path. So would need analyzing where actually is on booted > >> FreeBBSD environment. > > > > See the earlier point about aarch64 and armv7 not using > > /boot/* files while loading the FreeBSD loader: the > > FreeBSD loader variant used is the first stage able to > > look inside UFS or ZFS file systems. Loading and > > starting the FreeBSD loader happens before that stage > > in those types of contexts. > > > >> . . . > > > > Also, to my knowledge, powerpc (32-bit), powerpc64, and > > powerpc64le do not involve any variant of loader.efi or > > UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > > Again: more platform specific rather than generic. > > > > === > > Mark Millard > > marklmi at yahoo.com > > > > > > From nobody Fri Dec 22 14:15:42 2023 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 4SxTqK6VkGz55H2r for ; Fri, 22 Dec 2023 14:15:57 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (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 4SxTqK36vRz3FZZ for ; Fri, 22 Dec 2023 14:15:57 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1703254556; bh=zeNhZ3eLtxD0sPuHiblaNS4y1oA0WH+4/zrj6bwVelw=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=Qs5jsLw6dcFi2J5aHdo1wIV5HVTpH0glXmNvNpUSLdHhhCAJB3DXKfNBjBzxVT6Bk tjExqwXKjvv54QaMApda8ovs813FUVVUsgMVF2ZbIbsenFoGWM6vh9wd7m4a0rE/zU zcoEIlOcrpXe5Ac/jMLV8LO7eJaJ+HqLDnSTgl8qfVH5p98jVG8yDQXayGk0uFUbwP EdoLc1O40ZfEIkfCYVBLZUo7UimEii0YUkr2P2NVKM1ReA6E8AVXcr2spPZyzDgXqQ VERUQkk1HwIvINgulbPUf1cW2cfsiQlhn90+CI15d20YaP975NEX+/WvA4YZHshpDT YXmhoj2cFhM4Q== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id AC637740135; Fri, 22 Dec 2023 14:15:54 +0000 (UTC) From: Toomas Soome Message-Id: <6276D9E8-D1D6-4ED5-96FB-BBF2875E079E@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5A2DCD88-A445-469A-B59B-FB51C305F959" 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 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi Date: Fri, 22 Dec 2023 16:15:42 +0200 In-Reply-To: Cc: Mark Millard , Tomoaki AOKI , Current FreeBSD To: Konstantin Belousov References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Proofpoint-GUID: 7_kSmVwDg8beUQNGTSPYwe-Ytsd4PUAm X-Proofpoint-ORIG-GUID: 7_kSmVwDg8beUQNGTSPYwe-Ytsd4PUAm X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-22_08,2023-12-21_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 adultscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2312220105 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxTqK36vRz3FZZ --Apple-Mail=_5A2DCD88-A445-469A-B59B-FB51C305F959 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22. Dec 2023, at 16:07, Konstantin Belousov = wrote: >=20 > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: >>=20 >>=20 >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: >>>=20 >>> Tomoaki AOKI wrote on >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : >>>=20 >>>> On Thu, 21 Dec 2023 14:22:14 +0100 >>>> Dimitry Andric wrote: >>>>=20 >>>>> Yeah, my procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld procedure. >>>>>=20 >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the = same, at least for all UEFI systems. It is the default layout when you = do a regular install with recent installer onto a UEFI system, but some = users may use completely different mount points. So you should still = have some way of configuring the default location for loader = installation. >>>>>=20 >>>>> Also, on default installations a fallback entry named = /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of = loader.efi but with a different name. Namely, the default name that UEFI = (on x86_64 at least) searches for, if it doesn't know anything else. = I.e. if it isn't configured via efibootmgr(8), or the EFI variables have = been junked for some reason. It might make sense to also update that = file. >>>>>=20 >>>>> -Dimitry >>>>=20 >>>> Just an idea. >>>>=20 >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could = pass >>>> "where am I placed?" info, maybe via kenv. >>>>=20 >>>> Would need boot1.efi to pass something (ideally, "where am I booted >>>> from?", but "boot1_used=3D1" is sufficient). >>>>=20 >>>> To do so, loader.efi can confirm whether it was loaded via = boot1.efi or >>>> directly from UEFI firmware. If nothing is passed to it, it can = probe >>>> "where it is?" using UEFI call and set it, otherwise, it should >>>> be /boot/loader.efi, so nothing is needed to do. >>>=20 >>> To my knowledge aarch64 and armv7 never use the copy in >>> /boot/loader.efi during a boot. It has to have been copied >>> into the appropriate msdosfs such that it has an >>> appropriate path and name there. That is what is found >>> and used during the boot. >>=20 >>=20 >> All UEFI systems start from ESP (EFI System Partition). The only good = reason to install boot1.efi there is when you have very small ESP and = need to save that space - and in that case the boot1.esp will search and = execute /boot/loader.efi. >>=20 > No, this is not the only good reason, or even the least important = reason. >=20 > boot1.efi is extremely convenient for the normal (*) configuration = where > machine is dedicated for a single FreeBSD system. It finds and = chain-load > real loader.efi from the first UFS GPT partition which I always assign = to > the root. This means that I do not need to care about updating = loader.efi > at all, it is done during normal installworld. >=20 > * at least for me >=20 > I use this setup for >5 years on all my disk-booting machines. Yes, that one is also [good] reason, however, I personally do consider = it missing feature of bectl/beadm activate;) rgds, toomas >=20 >> The problem about boot1.efi (or any other UEFI chainload) is that = loading file and executing it will not replace current program in = memory, but will add new one, this may be problem with systems with = minimal memory configurations. And yes, boot1.efi is not really platform = specific - it is just another EFI application - one can build and use it = on arm (or any other) systems and then it will load and start = /boot/loader.efi. >>=20 >> starting loader directly from ESP has few advantages =E2=80=94 you = wont waste memory for boot1.efi, you save a bit of boot time, you can = use auxiliary files from ESP to pass some information to loader.efi (for = example to tell where your rootfs is in case of multiboot setups). >>=20 >> the boot1.efi could be a bit more appealing if it would be able to = load and start kernel directly, allowing to build very memory limited = setups, but then again, it does sound like very specific corner case. >>=20 >> rgds, >> toomas >>=20 >>=20 >>>=20 >>>> If no related kenv is set and freebsd-boot partition exists, it = should >>>> be booted with legacy (BIOS) boot. >>>=20 >>> If there even is a "legacy (BIOS) boot" is a platform >>> specific issue as far as I know. >>>=20 >>>> The easiest to be set by loader.efi and/or boot1.efi would be raw = UEFI >>>> device path. So would need analyzing where actually is on booted >>>> FreeBBSD environment. >>>=20 >>> See the earlier point about aarch64 and armv7 not using >>> /boot/* files while loading the FreeBSD loader: the >>> FreeBSD loader variant used is the first stage able to >>> look inside UFS or ZFS file systems. Loading and >>> starting the FreeBSD loader happens before that stage >>> in those types of contexts. >>>=20 >>>> . . . >>>=20 >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and >>> powerpc64le do not involve any variant of loader.efi or >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. >>> Again: more platform specific rather than generic. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com --Apple-Mail=_5A2DCD88-A445-469A-B59B-FB51C305F959 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 22. Dec 2023, at 16:07, Konstantin Belousov = <kostikbel@gmail.com> wrote:

On Fri, Dec 22, 2023 at = 11:36:24AM +0200, Toomas Soome wrote:


On 22. Dec = 2023, at 11:09, Mark Millard <marklmi@yahoo.com> = wrote:

Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote = on
Date: Thu, 21 Dec 2023 23:21:00 UTC :

On Thu, 21 Dec 2023 14:22:14 +0100
Dimitry Andric = <dim@FreeBSD.org> wrote:

Yeah, my = procedure is the same as yours: I first copy = /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to = /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why = this could not be just another step in the installworld = procedure.

That said, I am unsure if the pathname /boot/efi/efi = is always the same, at least for all UEFI systems. It is the default = layout when you do a regular install with recent installer onto a UEFI = system, but some users may use completely different mount points. So you = should still have some way of configuring the default location for = loader installation.

Also, on default installations a fallback = entry named /boot/efi/efi/boot/bootx64.efi is made, essentially another = copy of loader.efi but with a different name. Namely, the default name = that UEFI (on x86_64 at least) searches for, if it doesn't know anything = else. I.e. if it isn't configured via efibootmgr(8), or the EFI = variables have been junked for some reason. It might make sense to also = update that file.

-Dimitry

Just an = idea.

It would be nice if loader.efi (hopefully, boot1.efi,too) = could pass
"where am I placed?" info, maybe via kenv.

Would = need boot1.efi to pass something (ideally, "where am I booted
from?", = but "boot1_used=3D1" is sufficient).

To do so, loader.efi can = confirm whether it was loaded via boot1.efi or
directly from UEFI = firmware. If nothing is passed to it, it can probe
"where it is?" = using UEFI call and set it, otherwise, it should
be /boot/loader.efi, = so nothing is needed to do.

To my knowledge aarch64 = and armv7 never use the copy in
/boot/loader.efi during a boot. It = has to have been copied
into the appropriate msdosfs such that it has = an
appropriate path and name there. That is what is found
and used = during the boot.


All UEFI systems start from ESP = (EFI System Partition). The only good reason to install boot1.efi there = is when you have very small ESP and need to save that space - and in = that case the boot1.esp will search and execute = /boot/loader.efi.

No, = this is not the only good reason, or even the least important = reason.

boot1.efi is extremely = convenient for the normal (*) configuration where
machine is dedicated for = a single FreeBSD system.  It finds and chain-load
real loader.efi from the = first UFS GPT partition which I always assign to
the root.  This = means that I do not need to care about updating loader.efi
at all, it is done = during normal installworld.

* at = least for me

I use this setup for = >5 years on all my disk-booting machines.

Yes, that one is also = [good] reason, however, I personally do consider it missing feature of = bectl/beadm = activate;)

rgds,
toomas

<= /div>

The problem about boot1.efi (or any other UEFI = chainload) is that loading file and executing it will not replace = current program in memory, but will add new one, this may be problem = with systems with minimal memory configurations. And yes, boot1.efi is = not really platform specific - it is just another EFI application - one = can build and use it on arm (or any other) systems and then it will load = and start /boot/loader.efi.

starting loader directly from ESP has = few advantages =E2=80=94 you wont waste memory for boot1.efi, you save a = bit of boot time, you can use auxiliary files from ESP to pass some = information to loader.efi (for example to tell where your rootfs is in = case of multiboot setups).

the boot1.efi could be a bit more = appealing if it would be able to load and start kernel directly, = allowing to build very memory limited setups, but then again, it does = sound like very specific corner = case.

rgds,
toomas



If no related kenv is set = and freebsd-boot partition exists, it should
be booted with legacy = (BIOS) boot.

If there even is a "legacy (BIOS) boot" = is a platform
specific issue as far as I know.

The easiest to be set by loader.efi and/or boot1.efi would = be raw UEFI
device path. So would need analyzing where actually is on = booted
FreeBBSD environment.

See the earlier = point about aarch64 and armv7 not using
/boot/* files while loading = the FreeBSD loader: the
FreeBSD loader variant used is the first = stage able to
look inside UFS or ZFS file systems. Loading = and
starting the FreeBSD loader happens before that stage
in those = types of contexts.

. . = .

Also, to my knowledge, powerpc (32-bit), = powerpc64, and
powerpc64le do not involve any variant of loader.efi = or
UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces.
Again: = more platform specific rather than generic.

=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_5A2DCD88-A445-469A-B59B-FB51C305F959-- From nobody Fri Dec 22 15:00:15 2023 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 4SxVpY56cMz55K3t for ; Fri, 22 Dec 2023 15:00:21 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxVpY0xGWz3K8Q for ; Fri, 22 Dec 2023 15:00:20 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 3BMF0Fvg054933; Sat, 23 Dec 2023 00:00:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 23 Dec 2023 00:00:15 +0900 From: Tomoaki AOKI To: Toomas Soome Cc: Mark Millard , Current FreeBSD Subject: Re: symlink to /boot/loader.efi Message-Id: <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp> In-Reply-To: <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxVpY0xGWz3K8Q On Fri, 22 Dec 2023 12:02:54 +0200 Toomas Soome wrote: > > On 22. Dec 2023, at 11:54, Mark Millard wrote: > > > > On Dec 22, 2023, at 01:36, Toomas Soome wrote: > >> > >> > >> > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > >>> > >>> Tomoaki AOKI wrote on > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : > >>> > >>>> On Thu, 21 Dec 2023 14:22:14 +0100 > >>>> Dimitry Andric wrote: > >>>> > >>>>> Yeah, my procedure is the same as yours: I first copy /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then copy the freshly built and installed /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this could not be just another step in the installworld procedure. > >>>>> > >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the same, at least for all UEFI systems. It is the default layout when you do a regular install with recent installer onto a UEFI system, but some users may use completely different mount points. So you should still have some way of configuring the default location for loader installation. > >>>>> > >>>>> Also, on default installations a fallback entry named /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of loader.efi but with a different name. Namely, the default name that UEFI (on x86_64 at least) searches for, if it doesn't know anything else. I.e. if it isn't configured via efibootmgr(8), or the EFI variables have been junked for some reason. It might make sense to also update that file. > >>>>> > >>>>> -Dimitry > >>>> > >>>> Just an idea. > >>>> > >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > >>>> "where am I placed?" info, maybe via kenv. > >>>> > >>>> Would need boot1.efi to pass something (ideally, "where am I booted > >>>> from?", but "boot1_used=1" is sufficient). > >>>> > >>>> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > >>>> directly from UEFI firmware. If nothing is passed to it, it can probe > >>>> "where it is?" using UEFI call and set it, otherwise, it should > >>>> be /boot/loader.efi, so nothing is needed to do. > >>> > >>> To my knowledge aarch64 and armv7 never use the copy in > >>> /boot/loader.efi during a boot. It has to have been copied > >>> into the appropriate msdosfs such that it has an > >>> appropriate path and name there. That is what is found > >>> and used during the boot. > >> > >> > >> All UEFI systems start from ESP (EFI System Partition). The only good reason to install boot1.efi there is when you have very small ESP and need to save that space - and in that case the boot1.esp will search and execute /boot/loader.efi. Or if you need the functionality the patch at Bug 207940 [1] provides, which is not yet implemented on loader.efi. ;-) [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 > > Yep. May be I misinterpreted what the text strongly tied to > > "it should be /boot/loader.efi" and so ended up not pointing > > out an actual distinction. Ah, sorry for mis-leading words. > >> The problem about boot1.efi (or any other UEFI chainload) is that loading file and executing it will not replace current program in memory, but will add new one, this may be problem with systems with minimal memory configurations. And yes, boot1.efi is not really platform specific - it is just another EFI application - one can build and use it on arm (or any other) systems > > > > Not powerpc (32-bit), powerpc64, or powerpc64le: these are > > not UEFI systems at all, if I understand right. > > > Yes, building EFI application implies platform with UEFI support. > > rgds, > toomas > > > > > Of course, if only tier 1 is documented, such would not be > > covered. But documentation that is limited to tier 1 should > > say so explicitly --but various examples have historically > > not done so. > > > >> and then it will load and start /boot/loader.efi. > >> > >> starting loader directly from ESP has few advantages — you wont waste memory for boot1.efi, you save a bit of boot time, you can use auxiliary files from ESP to pass some information to loader.efi (for example to tell where your rootfs is in case of multiboot setups). > >> > >> the boot1.efi could be a bit more appealing if it would be able to load and start kernel directly, allowing to build very memory limited setups, but then again, it does sound like very specific corner case. > > > > Thanks for the UEFi-context notes that go well beyond anything > > I referenced. Good stuff. > > > >> rgds, > >> toomas > >> > >> > >>> > >>>> If no related kenv is set and freebsd-boot partition exists, it should > >>>> be booted with legacy (BIOS) boot. > >>> > >>> If there even is a "legacy (BIOS) boot" is a platform > >>> specific issue as far as I know. And most constraints in resource. Not sure about pxeboot and uboot cases. But at the point of view from "automatically updating boot codes", pxeboot could be ommitted from concerns, as it should be done by server-side admins. Putting these cases aside, to automatically update bootcodes, appropreate Makefile or script should need to know *How is this computer booted? *If detected as UEFI boot, what was the boot code? loader.efi as EFI/freebsd/loader.efi? loader.efi as EFI/boot/boot[arch].efi? or boot1.efi instead? *If detected as UEFI-boot and RAID (raidz, graid, ...) configured, also entitle all ESP on disks containing RAID member to be updated. ESP on other disks should be untouched. *If not UEFI-booted, consider as legacy boot (cannot pass info as of resource constraints, or third party loader like grub. This case, if freebsd-boot type partition is detected on which disk root directory is placed is entitled to be updated. To achieve this, at least loader.efi and boot1.efi should somehow pass info about below. *I am "boot1.efi" or "loader.efi" *I've booted from which device path. For this purpose, IIUC, only kenv can be used. Right? Then finally, update need-to-update boot codes. > >>> > >>>> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI > >>>> device path. So would need analyzing where actually is on booted > >>>> FreeBBSD environment. > >>> > >>> See the earlier point about aarch64 and armv7 not using > >>> /boot/* files while loading the FreeBSD loader: the > >>> FreeBSD loader variant used is the first stage able to > >>> look inside UFS or ZFS file systems. Loading and > >>> starting the FreeBSD loader happens before that stage > >>> in those types of contexts. > >>> > >>>> . . . > >>> > >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and > >>> powerpc64le do not involve any variant of loader.efi or > >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > >>> Again: more platform specific rather than generic. > >>> > > > > > > === > > Mark Millard > > marklmi at yahoo.com -- Tomoaki AOKI From nobody Fri Dec 22 15:16:22 2023 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 4SxW973rFpz55KpK for ; Fri, 22 Dec 2023 15:16:27 +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 4SxW970sRcz3MC2 for ; Fri, 22 Dec 2023 15:16:25 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 3BMFGMLg058433; Sat, 23 Dec 2023 00:16:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 23 Dec 2023 00:16:22 +0900 From: Tomoaki AOKI To: Toomas Soome Cc: Konstantin Belousov , Mark Millard , Current FreeBSD Subject: Re: symlink to /boot/loader.efi Message-Id: <20231223001622.d65ce2b783ea9490273bf5ff@dec.sakura.ne.jp> In-Reply-To: <6276D9E8-D1D6-4ED5-96FB-BBF2875E079E@me.com> References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <6276D9E8-D1D6-4ED5-96FB-BBF2875E079E@me.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxW970sRcz3MC2 On Fri, 22 Dec 2023 16:15:42 +0200 Toomas Soome wrote: > > > > On 22. Dec 2023, at 16:07, Konstantin Belousov wrote: > > > > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: > >> > >> > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > >>> > >>> Tomoaki AOKI wrote on > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : > >>> > >>>> On Thu, 21 Dec 2023 14:22:14 +0100 > >>>> Dimitry Andric wrote: > >>>> > >>>>> Yeah, my procedure is the same as yours: I first copy /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then copy the freshly built and installed /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this could not be just another step in the installworld procedure. > >>>>> > >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the same, at least for all UEFI systems. It is the default layout when you do a regular install with recent installer onto a UEFI system, but some users may use completely different mount points. So you should still have some way of configuring the default location for loader installation. > >>>>> > >>>>> Also, on default installations a fallback entry named /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of loader.efi but with a different name. Namely, the default name that UEFI (on x86_64 at least) searches for, if it doesn't know anything else. I.e. if it isn't configured via efibootmgr(8), or the EFI variables have been junked for some reason. It might make sense to also update that file. > >>>>> > >>>>> -Dimitry > >>>> > >>>> Just an idea. > >>>> > >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > >>>> "where am I placed?" info, maybe via kenv. > >>>> > >>>> Would need boot1.efi to pass something (ideally, "where am I booted > >>>> from?", but "boot1_used=1" is sufficient). > >>>> > >>>> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > >>>> directly from UEFI firmware. If nothing is passed to it, it can probe > >>>> "where it is?" using UEFI call and set it, otherwise, it should > >>>> be /boot/loader.efi, so nothing is needed to do. > >>> > >>> To my knowledge aarch64 and armv7 never use the copy in > >>> /boot/loader.efi during a boot. It has to have been copied > >>> into the appropriate msdosfs such that it has an > >>> appropriate path and name there. That is what is found > >>> and used during the boot. > >> > >> > >> All UEFI systems start from ESP (EFI System Partition). The only good reason to install boot1.efi there is when you have very small ESP and need to save that space - and in that case the boot1.esp will search and execute /boot/loader.efi. > >> > > No, this is not the only good reason, or even the least important reason. > > > > boot1.efi is extremely convenient for the normal (*) configuration where > > machine is dedicated for a single FreeBSD system. It finds and chain-load > > real loader.efi from the first UFS GPT partition which I always assign to > > the root. This means that I do not need to care about updating loader.efi > > at all, it is done during normal installworld. > > > > * at least for me > > > > I use this setup for >5 years on all my disk-booting machines. > > Yes, that one is also [good] reason, however, I personally do consider it missing feature of bectl/beadm activate;) > > rgds, > toomas Additional note. boot1.efi looks for /boot/loader.efi with the order below. This is implemented when smh@ fixed the fatal issue which disallow booting from memstick when ESP alreay exixts among internal drives. *Prefer ZFS pool over UFS (first sniff ZFS pool, if not exixts, UFS) on each drives checked. *Look for the drive which boot1.efi itself is loaded from. *If none found both on ZFS pool nor UFS, try drives with the order UEFI firmware recognizes. This is also the way how the boot1.efi with the patch on Bug 207940 applied decides the default. > > > > > >> The problem about boot1.efi (or any other UEFI chainload) is that loading file and executing it will not replace current program in memory, but will add new one, this may be problem with systems with minimal memory configurations. And yes, boot1.efi is not really platform specific - it is just another EFI application - one can build and use it on arm (or any other) systems and then it will load and start /boot/loader.efi. > >> > >> starting loader directly from ESP has few advantages — you wont waste memory for boot1.efi, you save a bit of boot time, you can use auxiliary files from ESP to pass some information to loader.efi (for example to tell where your rootfs is in case of multiboot setups). > >> > >> the boot1.efi could be a bit more appealing if it would be able to load and start kernel directly, allowing to build very memory limited setups, but then again, it does sound like very specific corner case. > >> > >> rgds, > >> toomas > >> > >> > >>> > >>>> If no related kenv is set and freebsd-boot partition exists, it should > >>>> be booted with legacy (BIOS) boot. > >>> > >>> If there even is a "legacy (BIOS) boot" is a platform > >>> specific issue as far as I know. > >>> > >>>> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI > >>>> device path. So would need analyzing where actually is on booted > >>>> FreeBBSD environment. > >>> > >>> See the earlier point about aarch64 and armv7 not using > >>> /boot/* files while loading the FreeBSD loader: the > >>> FreeBSD loader variant used is the first stage able to > >>> look inside UFS or ZFS file systems. Loading and > >>> starting the FreeBSD loader happens before that stage > >>> in those types of contexts. > >>> > >>>> . . . > >>> > >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and > >>> powerpc64le do not involve any variant of loader.efi or > >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > >>> Again: more platform specific rather than generic. > >>> > >>> === > >>> Mark Millard > >>> marklmi at yahoo.com > -- Tomoaki AOKI From nobody Fri Dec 22 19:17:15 2023 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 4SxcWD72Pyz54MDM for ; Fri, 22 Dec 2023 19:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxcWD59Sxz4Fh5 for ; Fri, 22 Dec 2023 19:17:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-50e593c756dso2571762e87.2 for ; Fri, 22 Dec 2023 11:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703272647; x=1703877447; 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=GYYBiui7bena3o4tfbqmHOSRwEY7sWxa7A6wwc401No=; b=L9LA1dgH9AFiZRf57A1+uQ+Vq/R2xcDhqEcSi+riOk3Z6iFpxLgkmS9HPua65bPAme tle8LWZoqEoratOCvyKGAw645F772kGeCTEIZF8wpWGJ2ha6DQWYxZmdlEo6hC2nDlbS NL7ckfemSDkRgBzd8rp9ElGmudaqXuWU93JdAsoubkfnsICGpRCI9luIm0EiNs6yqZK6 6AuVNrDYZKpL9x3bCVI5vGg+XSEVj09mBwK1eKMVrconBjDzauS8DYq4axF7rRFUinBg ac0h5FDKNE8kOpNZ/v9OCGB260nBpuKsXKu14C5av4v+qZV5KY/BLNSTB4sEvDMHnwQz j3kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703272647; x=1703877447; 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=GYYBiui7bena3o4tfbqmHOSRwEY7sWxa7A6wwc401No=; b=BmzRGFVjg6bsLIDHI2Iq2cE5+FgWj+rYR381AAXCjUOlWGmGFNRqJ2LgrTibFp4FyD Dzio3DqsSKtB15dR2BB8wbnc7bfV9X5CaaPGI9WeRX4/ZXpwZlAV7jx96vu9Fdlb0rOf 8XdS1/wGe539NNnBFcxzo2e0OSmao4Uckj+Hs5IzOUoBti6zJHW3O8LcPKj9r5p/T3X4 p5Amjgk/9vgaPQILOjoDe2zsERr4x/wjnLAvi0WrMjpOy552+k1bhkEq1HiY/TENaNgK vKD0PyEC4QC4TgXZOuFo1raBdvx47XwCtj5iQ29zyu/nK1pjlsQWGEtXL5QNhtpyqAcA r7FA== X-Gm-Message-State: AOJu0Yw6j+nM/FCWL9GACIrus33WzUEZ6Qn3jAO4a71dIPQRfKY9drzb FmE7R56veM75Ce8TbV4IzifUb5zF2Zh+rG7Nkjs1/dCyztHV3KOp7It6rxw8XXg= X-Google-Smtp-Source: AGHT+IHPawSpWVfTZbtrSNT7DeN+BpYqefraDE0MEHwPxE49sOrlD1kbF21Mh4hzvHSbOuCa26XIok/Vt6b6gn8qOpQ= X-Received: by 2002:ac2:4907:0:b0:50c:4ea:64f4 with SMTP id n7-20020ac24907000000b0050c04ea64f4mr826006lfi.70.1703272646771; Fri, 22 Dec 2023 11:17: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: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> In-Reply-To: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> From: Warner Losh Date: Fri, 22 Dec 2023 12:17:15 -0700 Message-ID: Subject: Re: symlink to /boot/loader.efi To: Toomas Soome Cc: Mark Millard , Tomoaki AOKI , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000111da1060d1e11e6" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxcWD59Sxz4Fh5 --000000000000111da1060d1e11e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 22, 2023 at 2:36=E2=80=AFAM Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > Tomoaki AOKI wrote on > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > >> Dimitry Andric wrote: > >> > >>> Yeah, my procedure is the same as yours: I first copy > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, the= n > copy the freshly built and installed /boot/loader.efi to > /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this > could not be just another step in the installworld procedure. > >>> > >>> That said, I am unsure if the pathname /boot/efi/efi is always the > same, at least for all UEFI systems. It is the default layout when you do= a > regular install with recent installer onto a UEFI system, but some users > may use completely different mount points. So you should still have some > way of configuring the default location for loader installation. > >>> > >>> Also, on default installations a fallback entry named > /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > loader.efi but with a different name. Namely, the default name that UEFI > (on x86_64 at least) searches for, if it doesn't know anything else. I.e. > if it isn't configured via efibootmgr(8), or the EFI variables have been > junked for some reason. It might make sense to also update that file. > >>> > >>> -Dimitry > >> > >> Just an idea. > >> > >> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > >> "where am I placed?" info, maybe via kenv. > >> > >> Would need boot1.efi to pass something (ideally, "where am I booted > >> from?", but "boot1_used=3D1" is sufficient). > >> > >> To do so, loader.efi can confirm whether it was loaded via boot1.efi o= r > >> directly from UEFI firmware. If nothing is passed to it, it can probe > >> "where it is?" using UEFI call and set it, otherwise, it should > >> be /boot/loader.efi, so nothing is needed to do. > > > > To my knowledge aarch64 and armv7 never use the copy in > > /boot/loader.efi during a boot. It has to have been copied > > into the appropriate msdosfs such that it has an > > appropriate path and name there. That is what is found > > and used during the boot. > > > All UEFI systems start from ESP (EFI System Partition). The only good > reason to install boot1.efi there is when you have very small ESP and nee= d > to save that space - and in that case the boot1.esp will search and execu= te > /boot/loader.efi. > Yes. I consider this a legacy need only. Part of the problem with 'fixing' boot1.efi to include all the newest filesystems, crypto, etc means that it grows too large for this use case. > The problem about boot1.efi (or any other UEFI chainload) is that loading > file and executing it will not replace current program in memory, but wil= l > add new one, this may be problem with systems with minimal memory > configurations. And yes, boot1.efi is not really platform specific - it i= s > just another EFI application - one can build and use it on arm (or any > other) systems and then it will load and start /boot/loader.efi. > > starting loader directly from ESP has few advantages =E2=80=94 you wont w= aste > memory for boot1.efi, you save a bit of boot time, you can use auxiliary > files from ESP to pass some information to loader.efi (for example to tel= l > where your rootfs is in case of multiboot setups). > > the boot1.efi could be a bit more appealing if it would be able to load > and start kernel directly, allowing to build very memory limited setups, > but then again, it does sound like very specific corner case. > Yes. boot1.efi is a bit of a special case. It originally was done as a quick port of boot1 from powerpc and was quite small. However, as we expanded the supported boot paths, it grew. And growth isn't the only problem. boot1.efi uses its own drivers and filesystems that do leverage the base libsa stuff, but do it in slightly different ways that loader.efi does. It also largely duplicates loader.efi functionality, just to read loader.efi. And with all the ZFS, crypto, compression, it's too much. I get the appeal for having a boot1.efi that's super simple, but our system is a poor fit to that, especially with ZFS's high velocity. It's a big reason I've not merged things in. Warner > rgds, > toomas > > > > > >> If no related kenv is set and freebsd-boot partition exists, it should > >> be booted with legacy (BIOS) boot. > > > > If there even is a "legacy (BIOS) boot" is a platform > > specific issue as far as I know. > > > >> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI > >> device path. So would need analyzing where actually is on booted > >> FreeBBSD environment. > > > > See the earlier point about aarch64 and armv7 not using > > /boot/* files while loading the FreeBSD loader: the > > FreeBSD loader variant used is the first stage able to > > look inside UFS or ZFS file systems. Loading and > > starting the FreeBSD loader happens before that stage > > in those types of contexts. > > > >> . . . > > > > Also, to my knowledge, powerpc (32-bit), powerpc64, and > > powerpc64le do not involve any variant of loader.efi or > > UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > > Again: more platform specific rather than generic. > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > > > > > > --000000000000111da1060d1e11e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 22, 2023 at 2:36=E2=80=AF= AM Toomas Soome <tsoome@me.com> = wrote:


> On 22. Dec 2023, at 11:09, Mark Millard <marklmi@yahoo.com> wrote:
>
> Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrot= e on
> Date: Thu, 21 Dec 2023 23:21:00 UTC :
>
>> On Thu, 21 Dec 2023 14:22:14 +0100
>> Dimitry Andric <dim@FreeBSD.org> wrote:
>>
>>> Yeah, my procedure is the same as yours: I first copy /boot/ef= i/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then copy the= freshly built and installed /boot/loader.efi to /boot/efi/efi/freebsd/load= er.efi. I don't see a technical reason why this could not be just anoth= er step in the installworld procedure.
>>>
>>> That said, I am unsure if the pathname /boot/efi/efi is always= the same, at least for all UEFI systems. It is the default layout when you= do a regular install with recent installer onto a UEFI system, but some us= ers may use completely different mount points. So you should still have som= e way of configuring the default location for loader installation.
>>>
>>> Also, on default installations a fallback entry named /boot/ef= i/efi/boot/bootx64.efi is made, essentially another copy of loader.efi but = with a different name. Namely, the default name that UEFI (on x86_64 at lea= st) searches for, if it doesn't know anything else. I.e. if it isn'= t configured via efibootmgr(8), or the EFI variables have been junked for s= ome reason. It might make sense to also update that file.
>>>
>>> -Dimitry
>>
>> Just an idea.
>>
>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pa= ss
>> "where am I placed?" info, maybe via kenv.
>>
>> Would need boot1.efi to pass something (ideally, "where am I = booted
>> from?", but "boot1_used=3D1" is sufficient).
>>
>> To do so, loader.efi can confirm whether it was loaded via boot1.e= fi or
>> directly from UEFI firmware. If nothing is passed to it, it can pr= obe
>> "where it is?" using UEFI call and set it, otherwise, it= should
>> be /boot/loader.efi, so nothing is needed to do.
>
> To my knowledge aarch64 and armv7 never use the copy in
> /boot/loader.efi during a boot. It has to have been copied
> into the appropriate msdosfs such that it has an
> appropriate path and name there. That is what is found
> and used during the boot.


All UEFI systems start from ESP (EFI System Partition). The only good reaso= n to install boot1.efi there is when you have very small ESP and need to sa= ve that space - and in that case the boot1.esp will search and execute /boo= t/loader.efi.

Yes. I consider this a le= gacy need only. Part of the problem with 'fixing' boot1.efi to incl= ude all the newest filesystems, crypto, etc means that it grows too large f= or this use case.
=C2=A0
The problem about boot1.efi (or any other UEFI chainload) is that loading f= ile and executing it will not replace current program in memory, but will a= dd new one, this may be problem with systems with minimal memory configurat= ions. And yes, boot1.efi is not really platform specific - it is just anoth= er EFI application - one can build and use it on arm (or any other) systems= and then it will load and start /boot/loader.efi.

starting loader directly from ESP has few advantages =E2=80=94 you wont was= te memory for boot1.efi, you save a bit of boot time, you can use auxiliary= files from ESP to pass some information to loader.efi (for example to tell= where your rootfs is in case of multiboot setups).

the boot1.efi could be a bit more appealing if it would be able to load and= start kernel directly, allowing to build very memory limited setups, but t= hen again, it does sound like very specific corner case.

Yes. boot1.efi is a bit of a special case. It originally = was done as a quick port of boot1 from powerpc and was quite small. However= , as we expanded the supported boot paths, it grew.

And growth isn't the only problem. boot1.efi uses its own drivers and= filesystems that do leverage the base libsa stuff, but do it in slightly d= ifferent ways that loader.efi does. It also largely duplicates loader.efi f= unctionality, just to read loader.efi. And with all the ZFS, crypto, compre= ssion, it's too much.

I get the appeal for hav= ing a boot1.efi that's super simple, but our system is a poor fit to th= at, especially with ZFS's=C2=A0high=C2=A0velocity. It's a big reaso= n I've not merged things in.

Warner
= =C2=A0
rgds,
toomas


>
>> If no related kenv is set and freebsd-boot partition exists, it sh= ould
>> be booted with legacy (BIOS) boot.
>
> If there even is a "legacy (BIOS) boot" is a platform
> specific issue as far as I know.
>
>> The easiest to be set by loader.efi and/or boot1.efi would be raw = UEFI
>> device path. So would need analyzing where actually is on booted >> FreeBBSD environment.
>
> See the earlier point about aarch64 and armv7 not using
> /boot/* files while loading the FreeBSD loader: the
> FreeBSD loader variant used is the first stage able to
> look inside UFS or ZFS file systems. Loading and
> starting the FreeBSD loader happens before that stage
> in those types of contexts.
>
>> . . .
>
> Also, to my knowledge, powerpc (32-bit), powerpc64, and
> powerpc64le do not involve any variant of loader.efi or
> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces.
> Again: more platform specific rather than generic.
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>


--000000000000111da1060d1e11e6-- From nobody Fri Dec 22 21:03:56 2023 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 4SxftP1YZgz54TyX for ; Fri, 22 Dec 2023 21:04:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxftN6YTjz4RQG for ; Fri, 22 Dec 2023 21:04:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40c31f18274so26710565e9.0 for ; Fri, 22 Dec 2023 13:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703279048; x=1703883848; 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=hZpWUDG5eZzaOafIULGbx85Iie/zMaFfj0ivMN8EMiM=; b=kesHSKA6TgCa0mQyK80cugqG9V7x/qTFPJMDAADRL93CBliQNWSoLmF6vFaPOffrmi oALNdr4m4w/6GGEt8K7sFYzRf1/5dfwYdpgIcrr4RF6ZVyNowLy7stg32uV7wGHo1496 q6hKztrFE/1gXP87/mA5DUmM82ITV36aNX9W9b6aPLuYX11rPsWFDq6GkJJuFRBtbKtj qm55/PEHQjZnZbrmsvOClKFhQVJbY3hO0YjXTwNFYoN9HpY/nouqEizCB0ZswV0zrwRJ UY0xCF1/LAbtCU77ucHEPzPfyzSUdoEaC3VVKQFV4w307Ucsgb8dEfyfTor/5hslZmqI JQzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703279048; x=1703883848; 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=hZpWUDG5eZzaOafIULGbx85Iie/zMaFfj0ivMN8EMiM=; b=X8G/Fphwimao7hGDmL3d9hrB0d1pftehqAfpUQM0ok4aBTRmOHiJQuRbFBjrq/Dtba KFuRSofu2Suj1udtsgwmekKb6x5TazLWoElREcyAVw+yLpnUAl2jv/6ZFE1HwsdwzTVf 6pjwurkGYIe+qqwZf3TIeX5ET9Vc1Ch7Q2vosr0koYf3yhhhuDg+u8kIknQ798tQ2Auy mRXce+pLwk1rISHkWx2MfFtwgYQoX2vQpD8nivh6yxpsvH974fagSk5y9DkGPGX0kMRO j7+2Y5I6HwAgCZ28Jy2jwG5uPDQbJp/EW7mYGqpXTvkBCO5gxX6aqAgZB1wlOPyGsHH0 0rjA== X-Gm-Message-State: AOJu0YyntHgv7VJj/MzWATcTMVWaYbsEcaTXl+uXrsy9sqP6YdB4ayA+ Y+qQ1JP5hZ+tozfxmrP9kPKz/Uqe9Q9WFv8fzz95ToVDCcr1Pw== X-Google-Smtp-Source: AGHT+IGsjmHNRQZyW5hQ/AHHRsoguaMBENrsLWqWAswr1cSOOK9nHCHLib8okYXIl2KXWIRCI/jJnnO0BhmcBwXX3QQ= X-Received: by 2002:a05:600c:2342:b0:40c:532b:7a30 with SMTP id 2-20020a05600c234200b0040c532b7a30mr1027821wmq.202.1703279048125; Fri, 22 Dec 2023 13:04:08 -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: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp> In-Reply-To: <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp> From: Warner Losh Date: Fri, 22 Dec 2023 14:03:56 -0700 Message-ID: Subject: Re: symlink to /boot/loader.efi To: Tomoaki AOKI Cc: Toomas Soome , Mark Millard , Current FreeBSD Content-Type: multipart/alternative; boundary="0000000000009e019b060d1f8e2d" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxftN6YTjz4RQG --0000000000009e019b060d1f8e2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 22, 2023 at 8:00=E2=80=AFAM Tomoaki AOKI wrote: > On Fri, 22 Dec 2023 12:02:54 +0200 > Toomas Soome wrote: > > > > On 22. Dec 2023, at 11:54, Mark Millard wrote: > > > > > > On Dec 22, 2023, at 01:36, Toomas Soome wrote: > > >> > > >> > > >> > > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > > >>> > > >>> Tomoaki AOKI wrote on > > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : > > >>> > > >>>> On Thu, 21 Dec 2023 14:22:14 +0100 > > >>>> Dimitry Andric wrote: > > >>>> > > >>>>> Yeah, my procedure is the same as yours: I first copy > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, the= n > copy the freshly built and installed /boot/loader.efi to > /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this > could not be just another step in the installworld procedure. > > >>>>> > > >>>>> That said, I am unsure if the pathname /boot/efi/efi is always th= e > same, at least for all UEFI systems. It is the default layout when you do= a > regular install with recent installer onto a UEFI system, but some users > may use completely different mount points. So you should still have some > way of configuring the default location for loader installation. > > >>>>> > > >>>>> Also, on default installations a fallback entry named > /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > loader.efi but with a different name. Namely, the default name that UEFI > (on x86_64 at least) searches for, if it doesn't know anything else. I.e. > if it isn't configured via efibootmgr(8), or the EFI variables have been > junked for some reason. It might make sense to also update that file. > > >>>>> > > >>>>> -Dimitry > > >>>> > > >>>> Just an idea. > > >>>> > > >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pa= ss > > >>>> "where am I placed?" info, maybe via kenv. > > >>>> > > >>>> Would need boot1.efi to pass something (ideally, "where am I boote= d > > >>>> from?", but "boot1_used=3D1" is sufficient). > > >>>> > > >>>> To do so, loader.efi can confirm whether it was loaded via > boot1.efi or > > >>>> directly from UEFI firmware. If nothing is passed to it, it can > probe > > >>>> "where it is?" using UEFI call and set it, otherwise, it should > > >>>> be /boot/loader.efi, so nothing is needed to do. > > >>> > > >>> To my knowledge aarch64 and armv7 never use the copy in > > >>> /boot/loader.efi during a boot. It has to have been copied > > >>> into the appropriate msdosfs such that it has an > > >>> appropriate path and name there. That is what is found > > >>> and used during the boot. > > >> > > >> > > >> All UEFI systems start from ESP (EFI System Partition). The only goo= d > reason to install boot1.efi there is when you have very small ESP and nee= d > to save that space - and in that case the boot1.esp will search and execu= te > /boot/loader.efi. > > Or if you need the functionality the patch at Bug 207940 [1] provides, > which is not yet implemented on loader.efi. ;-) > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207940 > > > > > Yep. May be I misinterpreted what the text strongly tied to > > > "it should be /boot/loader.efi" and so ended up not pointing > > > out an actual distinction. > > Ah, sorry for mis-leading words. > > > > >> The problem about boot1.efi (or any other UEFI chainload) is that > loading file and executing it will not replace current program in memory, > but will add new one, this may be problem with systems with minimal memor= y > configurations. And yes, boot1.efi is not really platform specific - it i= s > just another EFI application - one can build and use it on arm (or any > other) systems > > > > > > Not powerpc (32-bit), powerpc64, or powerpc64le: these are > > > not UEFI systems at all, if I understand right. > > > > > > Yes, building EFI application implies platform with UEFI support. > > > > rgds, > > toomas > > > > > > > > Of course, if only tier 1 is documented, such would not be > > > covered. But documentation that is limited to tier 1 should > > > say so explicitly --but various examples have historically > > > not done so. > > > > > >> and then it will load and start /boot/loader.efi. > > >> > > >> starting loader directly from ESP has few advantages =E2=80=94 you w= ont waste > memory for boot1.efi, you save a bit of boot time, you can use auxiliary > files from ESP to pass some information to loader.efi (for example to tel= l > where your rootfs is in case of multiboot setups). > > >> > > >> the boot1.efi could be a bit more appealing if it would be able to > load and start kernel directly, allowing to build very memory limited > setups, but then again, it does sound like very specific corner case. > > > > > > Thanks for the UEFi-context notes that go well beyond anything > > > I referenced. Good stuff. > > > > > >> rgds, > > >> toomas > > >> > > >> > > >>> > > >>>> If no related kenv is set and freebsd-boot partition exists, it > should > > >>>> be booted with legacy (BIOS) boot. > > >>> > > >>> If there even is a "legacy (BIOS) boot" is a platform > > >>> specific issue as far as I know. > > And most constraints in resource. Not sure about pxeboot and uboot > cases. > > But at the point of view from "automatically updating boot codes", > pxeboot could be ommitted from concerns, as it should be done by > server-side admins. > > Putting these cases aside, to automatically update bootcodes, > appropreate Makefile or script should need to know > *How is this computer booted? > > *If detected as UEFI boot, what was the boot code? > loader.efi as EFI/freebsd/loader.efi? > loader.efi as EFI/boot/boot[arch].efi? > or boot1.efi instead? > > *If detected as UEFI-boot and RAID (raidz, graid, ...) configured, > also entitle all ESP on disks containing RAID member to be updated. > ESP on other disks should be untouched. > > *If not UEFI-booted, consider as legacy boot (cannot pass info as of > resource constraints, or third party loader like grub. > This case, if freebsd-boot type partition is detected on which disk > root directory is placed is entitled to be updated. > > To achieve this, at least loader.efi and boot1.efi should somehow pass > info about below. > *I am "boot1.efi" or "loader.efi" > *I've booted from which device path. > For this purpose, IIUC, only kenv can be used. Right? > > Then finally, update need-to-update boot codes. > Yes. I'd prefer to make this more parameterized, maybe with sanity checks. That is, there'd be a tool that would do the right thing, based on what you tell it to do. we'd set the defaults to be a default install. If you want something other than defaults, you'd need to set a make variable (or a command line arg if you ran the tool by hand. You can know what type of system you are on: if arm, arm64 or riscv64, then it's UEFI. If i386 then it's BIOS (though you can confirm this by looking at machdep.bootmethod to see if it is BIOS, UEFI or something else), with amd64, it's the same check as i386. If it's powerpc, then you someone with powerpc skills will have to fill in the blanks here. If it is BIOS, we can infer the boot disk from where / lives. This isn't always correct, so that needs to be overiden. kenv might be useful, but it exports loaddev/currdev in the Boot Loader's namespace (disk0, etc) which may or may not match up with anything on FreeBSD. If it's UEFI, then we can use efibootmgr to find what was booted (or at least locate the ESP). Once we have the ESP, we can look at other bits of the boot variables to know if it's /efi/boot/bootx64.efi or if it's /etc/freebsd/loader.efi to update (and optionally, we could to both). Then you also have 'automount vs. fail' if the ESP isn't mounted. I'd recommend against autodetecting boot1 vs loader, except maybe as a safety measure that can be overriden. It's another reason having boot1.efi around complicates things needlessly. This is the sort of thing I was hoping to code up. I got bogged down by including 'also update the primary loader (aka the freebsd-boot partition, the u-boot stuff that needs to be dd', etc), so I think we shouldn't do that until phase 2. So maybe we should write a man page for this tool, and maybe a paragraph for how it would hook into the build system if we wanted to have a 'make installboot' target that lives logically before installkernel. Comments? Warner > >>> > > >>>> The easiest to be set by loader.efi and/or boot1.efi would be raw > UEFI > > >>>> device path. So would need analyzing where actually is on booted > > >>>> FreeBBSD environment. > > >>> > > >>> See the earlier point about aarch64 and armv7 not using > > >>> /boot/* files while loading the FreeBSD loader: the > > >>> FreeBSD loader variant used is the first stage able to > > >>> look inside UFS or ZFS file systems. Loading and > > >>> starting the FreeBSD loader happens before that stage > > >>> in those types of contexts. > > >>> > > >>>> . . . > > >>> > > >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and > > >>> powerpc64le do not involve any variant of loader.efi or > > >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > > >>> Again: more platform specific rather than generic. > > >>> > > > > > > > > > =3D=3D=3D > > > Mark Millard > > > marklmi at yahoo.com > > > -- > Tomoaki AOKI > > --0000000000009e019b060d1f8e2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 22, 2023 at 8:00=E2=80=AF= AM Tomoaki AOKI <junchoon@d= ec.sakura.ne.jp> wrote:
On Fri, 22 Dec 2023 12:02:54 +0200
Toomas Soome <tsoome@= me.com> wrote:

> > On 22. Dec 2023, at 11:54, Mark Millard <marklmi@yahoo.com> wrote:
> >
> > On Dec 22, 2023, at 01:36, Toomas Soome <tsoome@me.com> wrote:
> >>
> >>
> >>
> >>> On 22. Dec 2023, at 11:09, Mark Millard <marklmi@yahoo.com> wrote:<= br> > >>>
> >>> Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote on
> >>> Date: Thu, 21 Dec 2023 23:21:00 UTC :
> >>>
> >>>> On Thu, 21 Dec 2023 14:22:14 +0100
> >>>> Dimitry Andric <dim@FreeBSD.org> wrote:
> >>>>
> >>>>> Yeah, my procedure is the same as yours: I first = copy /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, = then copy the freshly built and installed /boot/loader.efi to /boot/efi/efi= /freebsd/loader.efi. I don't see a technical reason why this could not = be just another step in the installworld procedure.
> >>>>>
> >>>>> That said, I am unsure if the pathname /boot/efi/= efi is always the same, at least for all UEFI systems. It is the default la= yout when you do a regular install with recent installer onto a UEFI system= , but some users may use completely different mount points. So you should s= till have some way of configuring the default location for loader installat= ion.
> >>>>>
> >>>>> Also, on default installations a fallback entry n= amed /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of lo= ader.efi but with a different name. Namely, the default name that UEFI (on = x86_64 at least) searches for, if it doesn't know anything else. I.e. i= f it isn't configured via efibootmgr(8), or the EFI variables have been= junked for some reason. It might make sense to also update that file.
> >>>>>
> >>>>> -Dimitry
> >>>>
> >>>> Just an idea.
> >>>>
> >>>> It would be nice if loader.efi (hopefully, boot1.efi,= too) could pass
> >>>> "where am I placed?" info, maybe via kenv.<= br> > >>>>
> >>>> Would need boot1.efi to pass something (ideally, &quo= t;where am I booted
> >>>> from?", but "boot1_used=3D1" is suffic= ient).
> >>>>
> >>>> To do so, loader.efi can confirm whether it was loade= d via boot1.efi or
> >>>> directly from UEFI firmware. If nothing is passed to = it, it can probe
> >>>> "where it is?" using UEFI call and set it, = otherwise, it should
> >>>> be /boot/loader.efi, so nothing is needed to do.
> >>>
> >>> To my knowledge aarch64 and armv7 never use the copy in > >>> /boot/loader.efi during a boot. It has to have been copie= d
> >>> into the appropriate msdosfs such that it has an
> >>> appropriate path and name there. That is what is found > >>> and used during the boot.
> >>
> >>
> >> All UEFI systems start from ESP (EFI System Partition). The o= nly good reason to install boot1.efi there is when you have very small ESP = and need to save that space - and in that case the boot1.esp will search an= d execute /boot/loader.efi.

Or if you need the functionality the patch at Bug 207940 [1] provides,
which is not yet implemented on loader.efi. ;-)

[1] https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D207940


> > Yep. May be I misinterpreted what the text strongly tied to
> > "it should be /boot/loader.efi" and so ended up not poi= nting
> > out an actual distinction.

Ah, sorry for mis-leading words.


> >> The problem about boot1.efi (or any other UEFI chainload) is = that loading file and executing it will not replace current program in memo= ry, but will add new one, this may be problem with systems with minimal mem= ory configurations. And yes, boot1.efi is not really platform specific - it= is just another EFI application - one can build and use it on arm (or any = other) systems
> >
> > Not powerpc (32-bit), powerpc64, or powerpc64le: these are
> > not UEFI systems at all, if I understand right.
>
>
> Yes, building EFI application implies platform with UEFI support.
>
> rgds,
> toomas
>
> >
> > Of course, if only tier 1 is documented, such would not be
> > covered. But documentation that is limited to tier 1 should
> > say so explicitly --but various examples have historically
> > not done so.
> >
> >> and then it will load and start /boot/loader.efi.
> >>
> >> starting loader directly from ESP has few advantages =E2=80= =94 you wont waste memory for boot1.efi, you save a bit of boot time, you c= an use auxiliary files from ESP to pass some information to loader.efi (for= example to tell where your rootfs is in case of multiboot setups).
> >>
> >> the boot1.efi could be a bit more appealing if it would be ab= le to load and start kernel directly, allowing to build very memory limited= setups, but then again, it does sound like very specific corner case.
> >
> > Thanks for the UEFi-context notes that go well beyond anything > > I referenced. Good stuff.
> >
> >> rgds,
> >> toomas
> >>
> >>
> >>>
> >>>> If no related kenv is set and freebsd-boot partition = exists, it should
> >>>> be booted with legacy (BIOS) boot.
> >>>
> >>> If there even is a "legacy (BIOS) boot" is a pl= atform
> >>> specific issue as far as I know.

And most constraints in resource. Not sure about pxeboot and uboot
cases.

But at the point of view from "automatically updating boot codes"= ,
pxeboot could be ommitted from concerns, as it should be done by
server-side admins.

Putting these cases aside, to automatically update bootcodes,
appropreate Makefile or script should need to know
=C2=A0 *How is this computer booted?

=C2=A0 *If detected as UEFI boot, what was the boot code?
=C2=A0 =C2=A0loader.efi as EFI/freebsd/loader.efi?
=C2=A0 =C2=A0loader.efi as EFI/boot/boot[arch].efi?
=C2=A0 =C2=A0or boot1.efi instead?

=C2=A0 *If detected as UEFI-boot and RAID (raidz, graid, ...) configured, =C2=A0 =C2=A0also entitle all ESP on disks containing RAID member to be upd= ated.
=C2=A0 =C2=A0ESP on other disks should be untouched.

=C2=A0 *If not UEFI-booted, consider as legacy boot (cannot pass info as of=
=C2=A0 =C2=A0resource constraints, or third party loader like grub.
=C2=A0 =C2=A0This case, if freebsd-boot type partition is detected on which= disk
=C2=A0 =C2=A0root directory is placed is entitled to be updated.

To achieve this, at least loader.efi and boot1.efi should somehow pass
info about below.
=C2=A0 *I am "boot1.efi" or "loader.efi"
=C2=A0 *I've booted from which device path.
For this purpose, IIUC, only kenv can be used. Right?

Then finally, update need-to-update boot codes.

Yes. I'd prefer to make this more parameterized, maybe with sa= nity checks.

That is, there'd be a tool that w= ould do the right thing, based on what you tell it to do. we'd set the = defaults to be a default install. If you want something other than defaults= , you'd need to set a make variable (or a command line arg if you ran t= he tool by hand.

You can know what type of system = you are on: if arm, arm64 or riscv64, then it's UEFI. If i386 then it&#= 39;s BIOS (though you can confirm this by looking at=C2=A0machdep.bootmetho= d to see if it is BIOS, UEFI or something else), with amd64, it's the s= ame check as i386. If it's powerpc, then you someone with powerpc skill= s will have to fill in the blanks here.

If it is B= IOS, we can infer the boot disk from where / lives. This isn't always c= orrect, so that needs to be overiden. kenv might be useful, but it exports = loaddev/currdev in the Boot Loader's namespace (disk0, etc) which may o= r may not match up with anything on FreeBSD.

If it= 's UEFI, then we can use efibootmgr to find what was booted (or at leas= t locate the ESP). Once we have the ESP, we can look at other bits of the b= oot variables to know if it's /efi/boot/bootx64.efi or if it's /etc= /freebsd/loader.efi to update (and optionally, we could to both). Then you = also have 'automount vs. fail' if the ESP isn't mounted.
<= div>
I'd recommend against autodetecting=C2=A0boot1 vs lo= ader, except maybe as a safety measure that can be overriden. It's anot= her reason having boot1.efi around complicates things needlessly.

This is the sort of thing I was hoping to code up. I got bo= gged down by including 'also update the primary loader (aka the freebsd= -boot partition, the u-boot stuff that needs to be dd', etc), so I thin= k we shouldn't do that until phase 2.

So maybe= we should write a man page for this tool, and maybe a paragraph for how it= would hook into the build system if we wanted to have a 'make installb= oot' target that lives logically before installkernel.

Comments?

Warner

> >>>
> >>>> The easiest to be set by loader.efi and/or boot1.efi = would be raw UEFI
> >>>> device path. So would need analyzing where actually i= s on booted
> >>>> FreeBBSD environment.
> >>>
> >>> See the earlier point about aarch64 and armv7 not using > >>> /boot/* files while loading the FreeBSD loader: the
> >>> FreeBSD loader variant used is the first stage able to > >>> look inside UFS or ZFS file systems. Loading and
> >>> starting the FreeBSD loader happens before that stage
> >>> in those types of contexts.
> >>>
> >>>> . . .
> >>>
> >>> Also, to my knowledge, powerpc (32-bit), powerpc64, and > >>> powerpc64le do not involve any variant of loader.efi or > >>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces.
> >>> Again: more platform specific rather than generic.
> >>>
> >
> >
> > =3D=3D=3D
> > Mark Millard
> > marklmi at yahoo.com


--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>

--0000000000009e019b060d1f8e2d-- From nobody Fri Dec 22 21:49:38 2023 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 4Sxgv80bMlz54XXD for ; Fri, 22 Dec 2023 21:49:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sxgv55rT2z4VHf for ; Fri, 22 Dec 2023 21:49:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 3BMLndqa027019; Fri, 22 Dec 2023 23:49:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3BMLndqa027019 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 3BMLncL6027018; Fri, 22 Dec 2023 23:49:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Dec 2023 23:49:38 +0200 From: Konstantin Belousov To: Warner Losh Cc: Tomoaki AOKI , Toomas Soome , Mark Millard , Current FreeBSD Subject: Re: symlink to /boot/loader.efi Message-ID: References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sxgv55rT2z4VHf On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote: > Yes. I'd prefer to make this more parameterized, maybe with sanity checks. > > That is, there'd be a tool that would do the right thing, based on what you > tell it to do. we'd set the defaults to be a default install. If you want > something other than defaults, you'd need to set a make variable (or a > command line arg if you ran the tool by hand. > > You can know what type of system you are on: if arm, arm64 or riscv64, then > it's UEFI. If i386 then it's BIOS (though you can confirm this by looking > at machdep.bootmethod to see if it is BIOS, UEFI or something else), with > amd64, it's the same check as i386. If it's powerpc, then you someone with > powerpc skills will have to fill in the blanks here. > > If it is BIOS, we can infer the boot disk from where / lives. This isn't > always correct, so that needs to be overiden. kenv might be useful, but it > exports loaddev/currdev in the Boot Loader's namespace (disk0, etc) which > may or may not match up with anything on FreeBSD. > > If it's UEFI, then we can use efibootmgr to find what was booted (or at > least locate the ESP). Once we have the ESP, we can look at other bits of > the boot variables to know if it's /efi/boot/bootx64.efi or if it's > /etc/freebsd/loader.efi to update (and optionally, we could to both). Then > you also have 'automount vs. fail' if the ESP isn't mounted. > > I'd recommend against autodetecting boot1 vs loader, except maybe as a > safety measure that can be overriden. It's another reason having boot1.efi > around complicates things needlessly. > > This is the sort of thing I was hoping to code up. I got bogged down by > including 'also update the primary loader (aka the freebsd-boot partition, > the u-boot stuff that needs to be dd', etc), so I think we shouldn't do > that until phase 2. > > So maybe we should write a man page for this tool, and maybe a paragraph > for how it would hook into the build system if we wanted to have a 'make > installboot' target that lives logically before installkernel. > > Comments? Can we remove boot1.efi from the picture of the updating tool at all? Lets make the boot1 explicitly limited for very simple configuration where it searches for first UFS GPT partition and loads loader.efi from there. The autoupdate tool would be not used at all in such config, by administrator choice. From nobody Fri Dec 22 23:01:14 2023 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 4SxjTl3vX6z54c4b for ; Fri, 22 Dec 2023 23:01:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4SxjTl1HKwz4bXk for ; Fri, 22 Dec 2023 23:01:30 +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=1703286088; bh=Sx7J1noqObzLLIWdvB9M4JZR4jSutwlrmmZZbbuTRzc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DaNoWfh50+nAGktUjZMgM4iz9nYHRZlXl05eUH7lUHt5P2gfv9nvoJ12b42PNuUcgeIFzWG6mhwChM4A1eMVnI5rgkKXLDadFXJm1ewKh95GCcJ3JeNAlB0DYtnyCitr/JuE2QpP4mJONsW2Z9sbDxhnKLgjx9TfEtXrJfuHqTgoVEzuppZKG1HrZb4P4yhATPehm+63X9oGJvFhiRvqNI38GtXXY/1gtigagYXUYxr1+GYTlAsvz07p7G/j2ah52O97hW75gWKeLoEHe0qbE5hsuaWTp907HX34RBXmWvMieOJHlUE3a+JknCaSW017t9imq2XyUdQP8gJMEHSXoA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703286088; bh=8If5TAw3UYBSIeHQZENg9O6I4Jd+Gzr4XoCGb2B/4Rf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qfiOs0pd9wcnFBzA1owFJp43aizRKwZ9lR+1XPrTCz+eei2JdYsUlFmAFh99vbtoKtIoPp4IUJeMRf+zUL1t5suKbO/eBuOEy7J2eB0N3Wte3S7gphAAOUcXyJ/IOPfPvIXfB93Zuvb1C4EaiEx/fMzBCwiLNuU1wf+H1z1TCQT8u6dTRMJaNEcKK1Em1mKbGhRbtl8mAi76NRJ6+pJ6vdU6figcBuw4aHh4y1pMeS7Vz2ATJo+7dhMDGCSrhf8EzWN9FOU4/kxwBTiUytbtb75ZAtpcvP6VsrcINMYAgJe30ptJ3ly0Be4s0Lo6AFaM08UCY/ISI6IVl7KUNeHulg== X-YMail-OSG: p4QcQ0MVM1mOZXMMyDonyiOZ.seVIcLUUoG9FaLHKFd9c3n_8S1DgUbAVanWABl S1e5NPBp4KfCXIoG6wU_e49oNECtGVmJbOYnfh.RKnQE5WuCigfpbhwxASGcTBqwOXSbG19dW304 bzfgBDbN.AZ0i35D5xVNqxTp2eKBSH0lVBkxiYgnMw_YuoCLNPSblGA5w0Jup5YJva0yJwkMd3m2 f7kKeq9yybCe3aBgpnAm4igW3m0GmY44R2gLotTqjiVXEJMjeF9MLL8toGxsrbyEPd4.bMwA3GWQ 5hbKrDcrD3TEGwo5EJi1fVFK8EKRyaPfvoUPXVsxBDejAi9TMzdP_qP8dHIeNPUpCHsm9ET8Tz7G Eab5K0eGOiATbP65RpPYQ7ROLRXmLFk_hMb8IVZFlu5g55kTBZN4JpxTjpZCBsRnmkvy9ufQL7RG Ggb8G3TguHsPBmG8Uk8XVzYUOBPz8RuTDI5GXRZ3773zXdcMEm6rA2y6nyQf4YzLGGxNqvHxpAJd LOP64dQDiQnuykeZ_ve7Q4rwFnCvsZnfJU3E7I6fUbkTke52W4go.GQM3T37ow7ugQQn4qjVkOKV v84oRpDTQnDaac3j.MCz5hyzCt_QyP88jylzmkwjeBFFA86tK7FJjHS.Yr9rIBSaYlVOlA0qXpoY ZWiMA0E.YDpEJZuM2vEMHjR6e8dgMg30rARp.ar5LHhEs4otynzoaIROCWp1cUH4R0TtKO8r0Mk6 ngDS9sgBoGW7kP4opxR9.ecrsBFoYuuNgdEa8_Rmj2Xo9oCwDJAaXL.s59ajQIbNvyd5yo75inOz FZNXT.LjY0G_43WAVzlpGdxQyrvrGUa51owpwSQ3WSXuLa4HxuSTCMtErApL55DOKvA4W9AKwQ8M UI1vVrr5ft3Z4xO1sPhHwokO_Q16fXkjfXRIk6_StYK0XSkOgk0YbsuUifiX7L9C5PA6ycGosW5N TX7AuM7OulpKLrJSQY_UwaCzQRLCH4FJj2m0BwaC_y4OgV6pgocuVR0LgWLTvCQxjZgCdTWsHSQP NNP2R1hk1pfaeWdQ9oqQwa1K3fTEhvA6zjGT2Wsg7asqadNe.oNr2ULdAv9vlZoc8Q7sUyNZP5I4 x6IveNNCe4hlFPXyn2N9zF3SN7G1RBx4XfzJ6G1KK9Vt.OCAJ9Gz059NgM5SqlCE4USeqJ3HteAb Y8pgna90kRR4C2TprQAv7aqTtmxyodd_kB7EjibjmTR179jkJvlkKcB1dF40n3.0Qs4ONhhgZv4E BwYTKphXIBl8qqDqtiSNssjOag6ldDBQzZIjYUfVgl25gilu8HUZYbEKp27vRpNrEUkFVMUgMb5P CR6d_ZuW88uoiKy8aLTv3wBlFSb0XFkuKRNTGWPpgCJDkqPOaO6ocDMiBHkobIxGzqFzPmYqa4V1 pMpGlqNIorWpG57FcGv8uIlv9FeUsWw7X0pFhJ3caZZ1jSc65B_8RBbjUiSeXEJNyIr0QuFo055o 9himK6xj3DN2t_1eYlwBJUJi3UZ9bYnxrMpeNz3WGlC0lqBgu4KVFmgWKoUtSts8nJayeXhCiQV8 DJCrz6s948_YwpGWMdWONB8l9opLgmY6dwXip0D_4Ek.Ebp8QmtnasTqRfEEPm.dMBwwPbSGtuoD vDer3swmtSsyWAVZdELJgMXzLCieJn3c6YCWTFleRW9tTrHEgXTMLayp8jTqIumhHen46uENtIjr k1WPL_66lNCJew3YN2NhbDyGDGPYCejVimfwAHT7U_Ldvz4JUbecAcRVHJ4mnLd4bDcFtncNzhdt .n6hrea_Aw1R9G0QiKWKgCajfJfjCGQ0P2nMCuX3a9sYYGVO0mZS5m5te2l_ozSAZzn4tSldDaxG QGBcRTUSfBPRspWyC21KZ5x5o.S1zr36bkWmWJIpViVyEy5Rwkk5FOSOoXs77ROSUS1CdGUfTjgt 7FepraHffRp8CAaqo578UWac5fyKxyoku0W33WjGr3FZyWGEYXsfJnKOE5rNCo7uk_Y00KWOEac2 52ZBNtZGCpH7jjFyrPW2wqAGCjCvBp1vuTAktU13brdZvbBsLNaAqmWiHXCttQYmhBdudBa4nHUG V4RZgyB69wdr4xsFsxUGBeDly1lFLBWFEkUZkhE6dVKTlwzd.gJikF8W_YJ5f9ZIe.EQGneIOLif EvHs9W0ru8rVPYW8xCL5GFxrLCpy55Vf1NFEMp5itngXKqnIA6UNtw0zu_1M3Zlvy5Nl.hMeYLn9 Kkta0ax7oh5oSOu.wLLOybE8S3.0DgdGRnD9tqF3eznueTiETrIVdi.Lmlj4QPcxsL_tz0v9lqXs - X-Sonic-MF: X-Sonic-ID: 7653dfb6-ba04-489a-b1d1-2bb6d30cef40 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Dec 2023 23:01:28 +0000 Received: by hermes--production-gq1-6949d6d8f9-qkzts (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID efc014cdb74df0c48ce5a51ea0eae392; Fri, 22 Dec 2023 23:01:25 +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 \(3774.300.61.1.2\)) Subject: Re: symlink to /boot/loader.efi From: Mark Millard In-Reply-To: Date: Fri, 22 Dec 2023 15:01:14 -0800 Cc: Warner Losh , Tomoaki AOKI , Toomas Soome , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> <5879A778-0522-4E0F-A569-731E5EC85C18@yahoo.com> <8711C4A5-6329-4FB2-9D7A-4C7215595110@me.com> <20231223000015.766b94fe0e3a3b742fd386c5@dec.sakura.ne.jp> To: Konstantin Belousov X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxjTl1HKwz4bXk On Dec 22, 2023, at 13:49, Konstantin Belousov = wrote: > On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote: >> Yes. I'd prefer to make this more parameterized, maybe with sanity = checks. >>=20 >> That is, there'd be a tool that would do the right thing, based on = what you >> tell it to do. we'd set the defaults to be a default install. If you = want >> something other than defaults, you'd need to set a make variable (or = a >> command line arg if you ran the tool by hand. >>=20 >> You can know what type of system you are on: if arm, arm64 or = riscv64, then >> it's UEFI. If i386 then it's BIOS (though you can confirm this by = looking >> at machdep.bootmethod to see if it is BIOS, UEFI or something else), = with >> amd64, it's the same check as i386. If it's powerpc, then you someone = with >> powerpc skills will have to fill in the blanks here. >>=20 >> If it is BIOS, we can infer the boot disk from where / lives. This = isn't >> always correct, so that needs to be overiden. kenv might be useful, = but it >> exports loaddev/currdev in the Boot Loader's namespace (disk0, etc) = which >> may or may not match up with anything on FreeBSD. >>=20 >> If it's UEFI, then we can use efibootmgr to find what was booted (or = at >> least locate the ESP). Once we have the ESP, we can look at other = bits of >> the boot variables to know if it's /efi/boot/bootx64.efi or if it's >> /etc/freebsd/loader.efi to update (and optionally, we could to both). = Then >> you also have 'automount vs. fail' if the ESP isn't mounted. >>=20 >> I'd recommend against autodetecting boot1 vs loader, except maybe as = a >> safety measure that can be overriden. It's another reason having = boot1.efi >> around complicates things needlessly. >>=20 >> This is the sort of thing I was hoping to code up. I got bogged down = by >> including 'also update the primary loader (aka the freebsd-boot = partition, >> the u-boot stuff that needs to be dd', etc), so I think we shouldn't = do >> that until phase 2. >>=20 >> So maybe we should write a man page for this tool, and maybe a = paragraph >> for how it would hook into the build system if we wanted to have a = 'make >> installboot' target that lives logically before installkernel. >>=20 >> Comments? >=20 > Can we remove boot1.efi from the picture of the updating tool at all? >=20 > Lets make the boot1 explicitly limited for very simple configuration > where it searches for first UFS GPT partition and loads loader.efi > from there. The autoupdate tool would be not used at all in such > config, by administrator choice. If done, sounds like a good thing for aarch64 and armv7 small arm board snapshots to use. (Similarly if there ever is an analogous amd64 snapshot to dd to, say, USB media: something I'd use for testing activities with such official builds if they existed. I like to avoid submitting notes based on my personal builds if official builds show the behavior of interest. Setting up such an amd64 install the normal way is just busy work for this purpose. I do the same sort of thing for aarch64 and armv7, testing if I can avoid my personal builds that I normally use, including with the HoneyComb and MACCHIATObin Double Shot that are not small arm boards.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 23 04:33:02 2023 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 4SxrrX5LXHz54xPH for ; Sat, 23 Dec 2023 04:33:16 +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 4SxrrW6KY3z3Rv9 for ; Sat, 23 Dec 2023 04:33:15 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 3BN4X3jm016568; Sat, 23 Dec 2023 13:33:03 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 23 Dec 2023 13:33:02 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Toomas Soome , Mark Millard , Current FreeBSD Subject: Re: symlink to /boot/loader.efi Message-Id: <20231223133302.766172c194a0248069cff57b@dec.sakura.ne.jp> In-Reply-To: References: <94C108FE-3D2F-4116-B071-810F64DECEC4@me.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SxrrW6KY3z3Rv9 On Fri, 22 Dec 2023 12:17:15 -0700 Warner Losh wrote: > On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome wrote: > > > > > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > > > Tomoaki AOKI wrote on > > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > > >> Dimitry Andric wrote: > > >> > > >>> Yeah, my procedure is the same as yours: I first copy > > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then > > copy the freshly built and installed /boot/loader.efi to > > /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this > > could not be just another step in the installworld procedure. > > >>> > > >>> That said, I am unsure if the pathname /boot/efi/efi is always the > > same, at least for all UEFI systems. It is the default layout when you do a > > regular install with recent installer onto a UEFI system, but some users > > may use completely different mount points. So you should still have some > > way of configuring the default location for loader installation. > > >>> > > >>> Also, on default installations a fallback entry named > > /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > > loader.efi but with a different name. Namely, the default name that UEFI > > (on x86_64 at least) searches for, if it doesn't know anything else. I.e. > > if it isn't configured via efibootmgr(8), or the EFI variables have been > > junked for some reason. It might make sense to also update that file. > > >>> > > >>> -Dimitry > > >> > > >> Just an idea. > > >> > > >> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > > >> "where am I placed?" info, maybe via kenv. > > >> > > >> Would need boot1.efi to pass something (ideally, "where am I booted > > >> from?", but "boot1_used=1" is sufficient). > > >> > > >> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > > >> directly from UEFI firmware. If nothing is passed to it, it can probe > > >> "where it is?" using UEFI call and set it, otherwise, it should > > >> be /boot/loader.efi, so nothing is needed to do. > > > > > > To my knowledge aarch64 and armv7 never use the copy in > > > /boot/loader.efi during a boot. It has to have been copied > > > into the appropriate msdosfs such that it has an > > > appropriate path and name there. That is what is found > > > and used during the boot. > > > > > > All UEFI systems start from ESP (EFI System Partition). The only good > > reason to install boot1.efi there is when you have very small ESP and need > > to save that space - and in that case the boot1.esp will search and execute > > /boot/loader.efi. > > > > Yes. I consider this a legacy need only. Part of the problem with 'fixing' > boot1.efi to include all the newest filesystems, crypto, etc means that it > grows too large for this use case. > > > > The problem about boot1.efi (or any other UEFI chainload) is that loading > > file and executing it will not replace current program in memory, but will > > add new one, this may be problem with systems with minimal memory > > configurations. And yes, boot1.efi is not really platform specific - it is > > just another EFI application - one can build and use it on arm (or any > > other) systems and then it will load and start /boot/loader.efi. > > > > starting loader directly from ESP has few advantages — you wont waste > > memory for boot1.efi, you save a bit of boot time, you can use auxiliary > > files from ESP to pass some information to loader.efi (for example to tell > > where your rootfs is in case of multiboot setups). > > > > the boot1.efi could be a bit more appealing if it would be able to load > > and start kernel directly, allowing to build very memory limited setups, > > but then again, it does sound like very specific corner case. > > > > Yes. boot1.efi is a bit of a special case. It originally was done as a > quick port of boot1 from powerpc and was quite small. However, as we > expanded the supported boot paths, it grew. > > And growth isn't the only problem. boot1.efi uses its own drivers and > filesystems that do leverage the base libsa stuff, but do it in slightly > different ways that loader.efi does. It also largely duplicates loader.efi > functionality, just to read loader.efi. And with all the ZFS, crypto, > compression, it's too much. > > I get the appeal for having a boot1.efi that's super simple, but our system > is a poor fit to that, especially with ZFS's high velocity. It's a big > reason I've not merged things in. > > Warner Isn't gptboot.efi a "super simple boot1.efi"? It can kick only /boot/loader.efi on UFS. But until the functionality to select boot partition/pool is implemented on loader.efi, boot1.efi is worth keeping just for the patch on Bug 207940. Currently, I'm installing/running stable/14 and main on different physical drive, so I can coose which to boot via UEFI firmware menu on boot time. But if anyone constrained only single (but relatively large) physical drive installed wants to have both branch without using external drive should need the functionality. This should be (and actually have been) helpful for rescue purpose, too. (No need to worry about "where is my rescue memstick?!".) > > > > rgds, > > toomas > > > > > > > > > >> If no related kenv is set and freebsd-boot partition exists, it should > > >> be booted with legacy (BIOS) boot. > > > > > > If there even is a "legacy (BIOS) boot" is a platform > > > specific issue as far as I know. > > > > > >> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI > > >> device path. So would need analyzing where actually is on booted > > >> FreeBBSD environment. > > > > > > See the earlier point about aarch64 and armv7 not using > > > /boot/* files while loading the FreeBSD loader: the > > > FreeBSD loader variant used is the first stage able to > > > look inside UFS or ZFS file systems. Loading and > > > starting the FreeBSD loader happens before that stage > > > in those types of contexts. > > > > > >> . . . > > > > > > Also, to my knowledge, powerpc (32-bit), powerpc64, and > > > powerpc64le do not involve any variant of loader.efi or > > > UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces. > > > Again: more platform specific rather than generic. > > > > > > === > > > Mark Millard > > > marklmi at yahoo.com -- Tomoaki AOKI From nobody Sat Dec 23 07:18:23 2023 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 4SxwWG74D3z546jS for ; Sat, 23 Dec 2023 07:18:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SxwWF4LJvz3fqh for ; Sat, 23 Dec 2023 07:18:33 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=y07n header.b="bLKllo8/"; dkim=pass header.d=delphij.net header.s=w44o header.b=j8qIU1lc; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net; dmarc=pass (policy=reject) header.from=delphij.net DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=y07n; t=1703315904; h=message-id : date : mime-version : reply-to : to : from : subject : content-type : from; bh=eawqx7CkuFWMlQJfsotdyuv+lTcVsa4b/SVo7o2lKVg=; b=bLKllo8/W2H/AOaUzXzWrX9C85WAvk1F4iMkALQrJmQs9mLiMx2R7etMebq+rvYmKRztP 7p4iDcY2rwfXp0oDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=w44o; t=1703315904; h=message-id : date : mime-version : reply-to : to : from : subject : content-type : from; bh=eawqx7CkuFWMlQJfsotdyuv+lTcVsa4b/SVo7o2lKVg=; b=j8qIU1lch6R6rb515crowsRQCCNUYv/0WgQfHC2PoU4lYqfcEc9Kd5zKB/zZZzfTYfejH ci1E1UUBKV8ITfzjHqboqs3N3KgcP5I1H/jSOnhjhTWAu3AkqXxWmYOruBraO/xNjUtmYIJ 4Ev2xs7F4uX1twbjjB50hcY+fN2thlaNj8UU7a7U+tG3/Pf5fVabT4RI6FGSfkAj5OgfxjX tfLQWhVLJATYLnaq5ApZn/LYoIxlgBiYxbC8Mh8id9n2gTi4vzRtPfcHrB/4s4JiaOy5gEi 5OUOmlHzsJHAmWRN6+J088Tu/XinnMMr/r4XrRzVNerx/0HNp8ofWwzHOaVA== Received: from xins-laptop (unknown [IPv6:2601:646:8080:7daa:b5d1:2f3d:ea33:33c7]) by anubis.delphij.net (Postfix) with ESMTPSA id D816D212E6; Fri, 22 Dec 2023 23:18:24 -0800 (PST) Message-ID: Date: Fri, 22 Dec 2023 23:18:23 -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 Reply-To: d@delphij.net Content-Language: en-US To: freebsd-current@freebsd.org From: Xin Li Subject: Proposal: Disable compression of newsyslog by default Autocrypt: addr=delphij@delphij.net; keydata= xjMEZPbDoRYJKwYBBAHaRw8BAQdAsUNmxEWz6QiGdFbBrVVEpjNpgQV9FXjDWsLsY0UwRPvN HFhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD7ClgQTFgoAPhYhBLskk2pXNatsapeNzxED 4uuXWeTFBQJk9sRMAhsDBQkKBDXmBQsJCAcDBRUKCQgLBRYCAwEAAh4FAheAAAoJEBED4uuX WeTF6yIA/2Ls3Rb/qC8mQZ6D2S0UO5vblPghJfboFJLNJFw3i4GYAQCsTmQg3ahgbNEJu/vU xgtro2kTxa6kKnZ35IbqPqPcCc44BGT2w6ESCisGAQQBl1UBBQEBB0Cxji+sQgVPajLNA/Lw yHx0ogSalPQszdkfVgeg3iR3FAMBCAfCeAQYFgoAIBYhBLskk2pXNatsapeNzxED4uuXWeTF BQJk9sOhAhsMAAoJEBED4uuXWeTF3BQBAIx/gPCTFN2DPBrKLkE3oC/+j9EkmNLMUCGidlP/ Zb6HAP4nL1kStTsOldIGhi/3m1LvU7r3Kel3MnlIK8/9BlLPAg== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------I0L1m8DhHrhavZ3keVVGuAjy" X-Spamd-Result: default: False [-4.89 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; R_DKIM_ALLOW(-0.20)[delphij.net:s=y07n,delphij.net:s=w44o]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; ONCE_RECEIVED(0.10)[]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[delphij]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[d@delphij.net]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SxwWF4LJvz3fqh X-Spamd-Bar: ---- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------I0L1m8DhHrhavZ3keVVGuAjy Content-Type: multipart/mixed; boundary="------------v8IsehiScHKxdoUhfz0XiNRh"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: freebsd-current@freebsd.org Message-ID: Subject: Proposal: Disable compression of newsyslog by default --------------v8IsehiScHKxdoUhfz0XiNRh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGksDQoNCkluc3BpcmVkIGJ5IEQ0Mjk2MSwgSSBwcm9wb3NlIHRoYXQgd2UgbW92ZSBmb3J3 YXJkIHdpdGggZGlzYWJsaW5nIHRoZSANCmNvbXByZXNzaW9uIGJ5IGRlZmF1bHQgaW4gbmV3 c3lzbG9nLCBhcyBpbXBsZW1lbnRlZCBpbiANCmh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9y Zy9ENDMxNjkNCg0KSGlzdG9yaWNhbGx5LCBuZXdzeXNsb2cgaGFzIGNvbXByZXNzZWQgcm90 YXRlZCBsb2cgZmlsZXMgdG8gc2F2ZSBkaXNrIA0Kc3BhY2UuIFRoaXMgYXBwcm9hY2ggd2Fz IHZhbHVhYmxlIGluIHRoZSBlYXJseSBkYXlzIHdoZXJlIHN0b3JhZ2Ugc3BhY2UgDQp3YXMg bGltaXRlZC4gIEhvd2V2ZXIsIHRoZSBsYW5kc2NhcGUgaGFzIGNoYW5nZWQgc2lnbmlmaWNh bnRseS4gIE1vZGVybiANCmZpbGUgc3lzdGVtcywgc3VjaCBhcyBaRlMsIG5vdyBvZmZlciBu YXRpdmUgY29tcHJlc3Npb24gY2FwYWJpbGl0aWVzLiANCkFkZGl0aW9uYWxseSwgdGhlIHdp ZGVzcHJlYWQgYXZhaWxhYmlsaXR5IG9mIGxhcmdlciBoYXJkIGRyaXZlcyBoYXMgDQpkaW1p bmlzaGVkIHRoZSBuZWNlc3NpdHkgZm9yIGFkZGl0aW9uYWwgY29tcHJlc3Npb24uICBOb3Rh Ymx5LCB0aGUgbmVlZCANCnRvIGRlY29tcHJlc3MgbG9nIGZpbGVzIGZvciBwYXR0ZXJuIHNl YXJjaGVzIHBvc2VzIGEgc2lnbmlmaWNhbnQgDQppbmNvbnZlbmllbmNlLCBmdXJ0aGVyIHF1 ZXN0aW9uaW5nIHRoZSB1dGlsaXR5IG9mIHRoaXMgbGVnYWN5IGZlYXR1cmUuDQoNCkluIGNv bW1pdCA5MDY3NDhkMjA4ZDMsIGZsYWdzIEosIFgsIFksIFogY2FuIG5vdyBpbmRpY2F0ZSB0 aGF0IGEgbG9nIA0KZmlsZSBpcyBlbGlnaWJsZSBmb3IgY29tcHJlc3Npb24gcmF0aGVyIHRo YW4gZGlyZWN0bHkgZW5mb3JjaW5nIGl0LiBJdCANCmFsbG93cyBmb3IgYSBtb3JlIGZsZXhp YmxlIGFwcHJvYWNoLCB3aGVyZWluIHRoZSBhY3R1YWwgY29tcHJlc3Npb24gDQptZXRob2Qg Y2FuIGJlIHNldCB0byAibm9uZSIgb3Igc3BlY2lmaWVkIGFzIG9uZSBhbW9uZyBiemlwMiwg Z3ppcCwgeHosIA0Kb3IgenN0ZC4NCg0KVGhlcmVmb3JlIEkgd291bGQgcHJvcG9zZSB0aGF0 IHdlIGNoYW5nZSB0aGUgZGVmYXVsdCBjb21wcmVzc2lvbiBzZXR0aW5nIA0KdG8gIm5vbmUi IGluIEZyZWVCU0QgMTUuMC4gIFRoaXMgY2hhbmdlIHJlZmxlY3RzIG91ciBhZGFwdGF0aW9u IHRvIHRoZSANCmV2b2x2aW5nIHRlY2hub2xvZ2ljYWwgZW52aXJvbm1lbnQgYW5kIHVzZXIg bmVlZHMuICBJdCBhbHNvIGFsaWducyB3aXRoIA0KdGhlIGJyb2FkZXIgaW5pdGlhdGl2ZSB0 byBtb2Rlcm5pemUgb3VyIHN5c3RlbXMgd2hpbGUgbWFpbnRhaW5pbmcgDQpmbGV4aWJpbGl0 eSBhbmQgZWZmaWNpZW5jeS4NCg0KSSBsb29rIGZvcndhcmQgdG8geW91ciB0aG91Z2h0cyBh bmQgZmVlZGJhY2sgb24gdGhpcyBwcm9wb3NhbC4NCg0KQ2hlZXJzLA0K --------------v8IsehiScHKxdoUhfz0XiNRh-- --------------I0L1m8DhHrhavZ3keVVGuAjy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZYaJvwUDAAAAAAAKCRARA+Lrl1nkxUWf AP4j0YAoISaYv+CWoJ8wvZSFYmnb3gMgyt8boCTy51S6iwEAnk++tOv16LSoLoZdZolFmvfMdJCw T+clRt4bsHiI3Qo= =YV1u -----END PGP SIGNATURE----- --------------I0L1m8DhHrhavZ3keVVGuAjy-- From nobody Sat Dec 23 07:53:50 2023 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 4SxxJ15f8Pz549FS for ; Sat, 23 Dec 2023 07:53:53 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) (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 4SxxJ06zSZz4DrY for ; Sat, 23 Dec 2023 07:53:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.31.98) smtp.mailfrom=freebsd-listen@fabiankeil.de; dmarc=none Received: from [91.20.76.76] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.1) (envelope-from ) id 1rGwpR-00069E-0P for freebsd-current@freebsd.org; Sat, 23 Dec 2023 08:53:49 +0100 Date: Sat, 23 Dec 2023 08:53:50 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: Proposal: Disable compression of newsyslog by default Message-ID: <20231223085350.12691afe@fabiankeil.de> In-Reply-To: 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-Transfer-Encoding: 7bit X-Df-Sender: Nzc1MDY3 X-Spamd-Result: default: False [-2.01 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.906]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[80.67.31.98:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:8972, ipnet:80.67.16.0/20, country:DE]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[fabiankeil.de]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SxxJ06zSZz4DrY X-Spamd-Bar: -- Xin Li wrote on 2023-12-22 at 23:18:23: > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 [...] > Therefore I would propose that we change the default compression setting > to "none" in FreeBSD 15.0. This change reflects our adaptation to the > evolving technological environment and user needs. It also aligns with > the broader initiative to modernize our systems while maintaining > flexibility and efficiency. > > I look forward to your thoughts and feedback on this proposal. In ElectroBSD I simply removed the J flags in newsyslog.conf in 2021 [0]. I have no strong feelings about it, but it's unclear to me why newsyslog[8] itself needs to be changed. Fabian [0] From nobody Sat Dec 23 08:51:47 2023 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 4Sxyb31zT9z54CsY for ; Sat, 23 Dec 2023 08:51:59 +0000 (UTC) (envelope-from SRS0=2GHx=IC=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 4Sxyb25SJTz4KLg for ; Sat, 23 Dec 2023 08:51:58 +0000 (UTC) (envelope-from SRS0=2GHx=IC=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C0542D7887; Sat, 23 Dec 2023 09:51:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1703321509; bh=E5cgzB0MouO+lQusdpYucicErzQsk75n/j+VFS0C/rY=; h=Date:Subject:To:References:From:In-Reply-To; b=17eBae6RReNNvZuzgIs0DwuuxTGSxZYt9H0Aln8N0qN/qProvS5VsxZ29lX7lUPOc 1QNLVasVrrVDhRLAnDrkMJIIVg16IH+eDgblHXz0ByXEahMspWYbMlntr4FvV0KZdx z6fjb+JQOgTysPHCyneAMJOKkQ/je0obO8QjzJDw= 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 45B48D7884; Sat, 23 Dec 2023 09:51:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1703321508; bh=E5cgzB0MouO+lQusdpYucicErzQsk75n/j+VFS0C/rY=; h=Date:Subject:To:References:From:In-Reply-To; b=nwnkOhiZzaAGxA2VVVLbn1P+uss3t8o/YlIbCn7u9u61OwwvLMuUyW8vtHtF722wy C5Mmr7uC3+1ciF2itH3AJor6XvqrQVRcoMGB/7YaNbWU/tjMcAm/sn2tuMg/COkdwa n7QFvLzPPnd71gXLT3krygYusNzqfzKw6K9tZcBI= Message-ID: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> Date: Sat, 23 Dec 2023 09:51:47 +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: Proposal: Disable compression of newsyslog by default To: d@delphij.net, freebsd-current@freebsd.org References: Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sxyb25SJTz4KLg On 23/12/2023 08:18, Xin Li wrote: > Hi, > > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 > > Historically, newsyslog has compressed rotated log files to save disk > space. This approach was valuable in the early days where storage space > was limited.  However, the landscape has changed significantly.  Modern > file systems, such as ZFS, now offer native compression capabilities. > Additionally, the widespread availability of larger hard drives has > diminished the necessity for additional compression.  Notably, the need > to decompress log files for pattern searches poses a significant > inconvenience, further questioning the utility of this legacy feature. > > In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log > file is eligible for compression rather than directly enforcing it. It > allows for a more flexible approach, wherein the actual compression > method can be set to "none" or specified as one among bzip2, gzip, xz, > or zstd. > > Therefore I would propose that we change the default compression setting > to "none" in FreeBSD 15.0.  This change reflects our adaptation to the > evolving technological environment and user needs.  It also aligns with > the broader initiative to modernize our systems while maintaining > flexibility and efficiency. > > I look forward to your thoughts and feedback on this proposal. I don't think anything needs to be changed on newsyslog. Those who want to disable compression can do so in the "default" newsyslog.conf file. Why force this change in the newsyslog code? I also don't think that the log file should not be compressed even on a compressed filesystem. Compressed log files can be handled by tools like zcat, zless, zgrep, etc. without first decompressing the log file. Text log files can still grow to large sizes, and if you have a daily backup job over a long distance network, if you use a protocol without own compression, it is still better to have compressed log files than uncompressed on a compressed filesystem. To me, it's the same as compressing large database dumps and not relying on filesystem compression. YMMV, but I really don't see any benefit of changing the newsyslog code, just change defaults in newsyslog.conf. Kind regards Miroslav Lachman From nobody Sat Dec 23 12:00:44 2023 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 4Sy2nD52hZz54QHv for ; Sat, 23 Dec 2023 12:01:04 +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 RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sy2n95Zk9z4WVX for ; Sat, 23 Dec 2023 12:01:01 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=VThSh9eT; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl Received: from [IPV6:2a02:22e0:cf00:1ff:46f7:5375:dd57:c63f] (mzar@[IPv6:2a02:22e0:cf00:1ff:46f7:5375:dd57:c63f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.2/8.17.2) with ESMTPSA id 3BNC0iTu080402 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 23 Dec 2023 13:00:48 +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=1703332848; bh=3UEV4eALbJigKtIs5AkDuhwhURennbDz6TX/QRwb4ck=; h=Date:Subject:To:References:From:In-Reply-To; b=VThSh9eT66HGEYsrKjDDIbKYgeJ5OWVelORBi/gys9FptWrTUVK+e0+8N5t7Q9WeJ hPJ02d1Bkgk0gWdwjZ0e/eTXX/MPgCsNcVjX5NLQcNlB2zXBEIsNhLY3XsTkb3K41A y9gyFSvQpsmDQeBMOlDwkdm6gukqCuZx3DvJEGyca15+HeB6KNFYS2vu/IMt85FFPj W6cViSAcxYBZ7NvRWH4Sjmm2vvseociVgPB04ycS0DjjfEw5ckhAHIvPfgcY1GV0kt 54sSn6LUYdCTF/vNt8FXVW1qKGh6Oj6xH+Eqpm6unEkuGjcnV0e9rMpgSeyPhK6Du8 Ro2LphppGWBYA== Message-ID: <3c13fd10-997e-40a7-823e-e37a4d481739@plan-b.pwste.edu.pl> Date: Sat, 23 Dec 2023 13:00:44 +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: Proposal: Disable compression of newsyslog by default To: freebsd-current@freebsd.org References: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> 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: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; R_SPF_NA(0.00)[no SPF record]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4Sy2n95Zk9z4WVX X-Spamd-Bar: --- W dniu 23.12.2023 o 09:51, Miroslav Lachman pisze: > On 23/12/2023 08:18, Xin Li wrote: >> Hi, >> >> Inspired by D42961, I propose that we move forward with disabling the >> compression by default in newsyslog, as implemented in >> https://reviews.freebsd.org/D43169 >> >> Historically, newsyslog has compressed rotated log files to save disk >> space. This approach was valuable in the early days where storage >> space was limited.  However, the landscape has changed >> significantly.  Modern file systems, such as ZFS, now offer native >> compression capabilities. Additionally, the widespread availability >> of larger hard drives has diminished the necessity for additional >> compression.  Notably, the need to decompress log files for pattern >> searches poses a significant inconvenience, further questioning the >> utility of this legacy feature. >> >> In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log >> file is eligible for compression rather than directly enforcing it. >> It allows for a more flexible approach, wherein the actual >> compression method can be set to "none" or specified as one among >> bzip2, gzip, xz, or zstd. >> >> Therefore I would propose that we change the default compression >> setting to "none" in FreeBSD 15.0.  This change reflects our >> adaptation to the evolving technological environment and user needs.  >> It also aligns with the broader initiative to modernize our systems >> while maintaining flexibility and efficiency. >> >> I look forward to your thoughts and feedback on this proposal. Thank you for this change and future MFCs. Log files and an urge to process them differ a lot between setups. I guess some people would back completely disabling compression, and some would be against this proposal. There are also small VMs with limited storage formatted with UFS where current defaults: "-c legacy" and using bzip2 (J from newsyslog.conf) to compress logs seems to be perfectly suited. > > I don't think anything needs to be changed on newsyslog. Those who > want to disable compression can do so in the "default" newsyslog.conf > file. Why force this change in the newsyslog code? > I also don't think that the log file should not be compressed even on > a compressed filesystem. Compressed log files can be handled by tools > like zcat, zless, zgrep, etc. without first decompressing the log file. When newsyslog has to deal only with small/medium files and logs are just stored, if processed then very rarely, the compression method is not very relevant, but the situation changes if you have to deal with larger log files, which have to be processed after rotation. While testing this change, I have done a very simple benchmark with the largest log file which I have to rotate daily. It looks to me that having a compressed log file sometimes makes sense even if you have to process these logs in place. Please take a look at the result of running zcat over the compressed file and the timings for the original, uncompressed one. All the files are stored on ZFS lz4 compressed dataset lying on mirrored, not so fast, SSD drives. [r-b] /tmp# /usr/bin/time zcat flowd.0.zst > /dev/null         3.22 real         3.03 user         0.18 sys [r-b] /tmp# /usr/bin/time zcat flowd.0.zst.orig  > /dev/null         3.40 real         3.24 user         0.15 sys [r-b] /tmp# /usr/bin/time zcat flowd.0.gz > /dev/null         6.58 real         6.46 user         0.12 sys [r-b] /tmp# /usr/bin/time zcat flowd.0.xz > /dev/null        18.15 real        16.97 user         1.18 sys [r-b] /tmp# /usr/bin/time zcat flowd.0.bz2 > /dev/null        45.47 real        45.33 user         0.12 sys [r-b] /tmp# /usr/bin/time cat flowd.0 > /dev/null         3.35 real         0.25 user         3.10 sys [r-b] /tmp# ls -l flowd.0* -rw-------  1 root wheel 3823756280 Dec 23 09:56 flowd.0 -rw-------  1 root wheel  195036235 Dec 23 09:56 flowd.0.bz2 -rw-------  1 root wheel  305250854 Dec 23 09:56 flowd.0.gz -rw-------  1 root wheel  180642412 Dec 23 09:56 flowd.0.xz -rw-------  1 root wheel  252470186 Dec 23 09:56 flowd.0.zst (zstd with --long --adapt -T0) -rw-------  1 root wheel  297184160 Dec 23 09:56 flowd.0.zst.orig (pre 906748d208d3 zstd options) > Text log files can still grow to large sizes, and if you have a daily > backup job over a long distance network, if you use a protocol without > own compression, it is still better to have compressed log files than > uncompressed on a compressed filesystem. To me, it's the same as > compressing large database dumps and not relying on filesystem > compression. > YMMV, but I really don't see any benefit of changing the newsyslog > code, just change defaults in newsyslog.conf. > There is a clear benefit for me, users who don't want their logs to be compressed, will have just to alter one line in /etc/crontab: # Rotate log files every hour, if necessary. 0    *    *    *    *    root    newsyslog -c none instead of changing /etc/newsyslog.conf line by line. Thank you for the new newsyslog(8) -c option providing this feature ! With kind regards -- Marek Zarychta From nobody Sat Dec 23 14:52:47 2023 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 4Sy6bn39j7z54bsj for ; Sat, 23 Dec 2023 14:53:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sy6bm3tzpz3FgS for ; Sat, 23 Dec 2023 14:53:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 3BNEqlxa080503; Sat, 23 Dec 2023 16:52:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3BNEqlxa080503 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 3BNEqlaq080502; Sat, 23 Dec 2023 16:52:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Dec 2023 16:52:47 +0200 From: Konstantin Belousov To: d@delphij.net Cc: freebsd-current@freebsd.org Subject: Re: Proposal: Disable compression of newsyslog by default Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sy6bm3tzpz3FgS On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote: > Hi, > > Inspired by D42961, I propose that we move forward with disabling the > compression by default in newsyslog, as implemented in > https://reviews.freebsd.org/D43169 > > Historically, newsyslog has compressed rotated log files to save disk space. > This approach was valuable in the early days where storage space was > limited. However, the landscape has changed significantly. Modern file > systems, such as ZFS, now offer native compression capabilities. > Additionally, the widespread availability of larger hard drives has > diminished the necessity for additional compression. Notably, the need to > decompress log files for pattern searches poses a significant inconvenience, > further questioning the utility of this legacy feature. > > In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is > eligible for compression rather than directly enforcing it. It allows for a > more flexible approach, wherein the actual compression method can be set to > "none" or specified as one among bzip2, gzip, xz, or zstd. > > Therefore I would propose that we change the default compression setting to > "none" in FreeBSD 15.0. This change reflects our adaptation to the evolving > technological environment and user needs. It also aligns with the broader > initiative to modernize our systems while maintaining flexibility and > efficiency. > > I look forward to your thoughts and feedback on this proposal. This is strange change at best. I have no opinion about the disabling of compression of the rotated logs by default, but we already have knobs to do that. Adding a knob that disables (or enables) other knobs to work is weird. If you want to change the compression, update the default configuration file. From nobody Sat Dec 23 15:09:56 2023 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 4Sy6zQ4Fg1z54cTx for ; Sat, 23 Dec 2023 15:10:10 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sy6zQ2b3Dz3HP1 for ; Sat, 23 Dec 2023 15:10:10 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-5cdfbd4e8caso841644a12.0 for ; Sat, 23 Dec 2023 07:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703344208; x=1703949008; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=VdFL6kDduoA20p2T6TzjFJ3zD9CiRel328mjBjz/WyA=; b=ZQ8Q9qEkhpZrXoeJZ8yfO2ntgLfv/yOy1/2Yvc/i/AX9OntFfCO8+91OuPr77u1Vat 9QPvYSwCKYtZqbcznyr2LmcQJIKvbGjb4hzf6xNq1tXM0WSojmv20ln++G/+h0wz0ccr BDKgVl7EyTTX3ftGamjShEHCDudWozjoeo2jPbYW2k0FwRrLN8JqRLhNxuz9lNaj6eQx nk9JLxVRRzNGC9Y+YNowFRGXGAGzh7YctTrO3jw2J+gEHabkSqi8jsaPU+E+7wH0WKOb xoAPsvUSiyxuF+D+gmOuYQtZXsxMBPk6KtPO8bmLve+KHThc+bu4VC94o7VFHxCpi5I3 i+Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703344208; x=1703949008; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VdFL6kDduoA20p2T6TzjFJ3zD9CiRel328mjBjz/WyA=; b=nZSsCE3gtRHMuH5pmY15DYQu6qQWFY0HMfyILUU+ejjVgmEiYuQNQ5Tsvnm0Z3JB+8 y7aEWp4FHDy3MBRTGcYwKgzXrkQkSvhacqneWbYKayPiBbeyXkX5gwNwdmCOlm2ZN/Vk hGqgTf74bgJe/YRYRQkLvVHNz2PDNFHYNyi1pugP0LBhjwjrdoozzB771bSRYF5KYl67 YY990xmg07ALSSb2ij/bULOClxJa7Qq8xD4UzzSQCBTtos/cl2FWZkXzXSLFRkSmTMGG eEnLtKhzcbCI/QDJT3nCPi4SdXoBiiBw9C5B9eAU12HvTJbY+o2Vo/1w18S0Iwy7JhjB wneg== X-Gm-Message-State: AOJu0Yx74io2X1Sy0Dler38Yf59TrkBTP76kWkODMknCBamY3j+9l6wu VW23CMj9Xbx2qFIpgC4LA+wXMKyIfQhkzg== X-Google-Smtp-Source: AGHT+IFxVJw9Pt1OfWKOWDHljIIxr64IGfH25jdT8yRo84tiwvQb6vuf87Dbws8g0mwyztuec5HELg== X-Received: by 2002:a17:903:191:b0:1d4:4768:41 with SMTP id z17-20020a170903019100b001d447680041mr140701plg.47.1703344207942; Sat, 23 Dec 2023 07:10:07 -0800 (PST) Received: from smtpclient.apple (c-24-19-32-101.hsd1.wa.comcast.net. [24.19.32.101]) by smtp.gmail.com with ESMTPSA id f6-20020a170902ce8600b001d3aa3b8309sm5219830plg.178.2023.12.23.07.10.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Dec 2023 07:10:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Enji Cooper 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: Proposal: Disable compression of newsyslog by default Date: Sat, 23 Dec 2023 07:09:56 -0800 Message-Id: References: Cc: freebsd-current@freebsd.org In-Reply-To: To: d@delphij.net X-Mailer: iPhone Mail (21B101) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sy6zQ2b3Dz3HP1 > On Dec 22, 2023, at 23:18, Xin Li wrote: >=20 > =EF=BB=BFHi, >=20 > Inspired by D42961, I propose that we move forward with disabling the comp= ression by default in newsyslog, as implemented in https://reviews.freebsd.o= rg/D43169 >=20 > Historically, newsyslog has compressed rotated log files to save disk spac= e. This approach was valuable in the early days where storage space was limi= ted. However, the landscape has changed significantly. Modern file systems= , such as ZFS, now offer native compression capabilities. Additionally, the w= idespread availability of larger hard drives has diminished the necessity fo= r additional compression. Notably, the need to decompress log files for pat= tern searches poses a significant inconvenience, further questioning the uti= lity of this legacy feature. >=20 > In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file i= s eligible for compression rather than directly enforcing it. It allows for a= more flexible approach, wherein the actual compression method can be set to= "none" or specified as one among bzip2, gzip, xz, or zstd. >=20 > Therefore I would propose that we change the default compression setting t= o "none" in FreeBSD 15.0. This change reflects our adaptation to the evolvi= ng technological environment and user needs. It also aligns with the broade= r initiative to modernize our systems while maintaining flexibility and effi= ciency. >=20 > I look forward to your thoughts and feedback on this proposal. This impacts embedded systems or jails which use UFS as the default /var/log= backed device. There are quite a few larger consumers of FreeBSD out there t= hat still use UFS instead of ZFS. Adding this instead into bsdinstall and the documentation as a suggested kno= b seems like a good way to go. Just something to keep in mind when making this change. Cheers, -Enji= From nobody Sat Dec 23 15:13:17 2023 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 4Sy73F57zSz54cpD for ; Sat, 23 Dec 2023 15:13:29 +0000 (UTC) (envelope-from freebsd@grem.de) 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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sy73F1hYRz3JMR for ; Sat, 23 Dec 2023 15:13:29 +0000 (UTC) (envelope-from freebsd@grem.de) Authentication-Results: mx1.freebsd.org; none Received: by mail.evolve.de (OpenSMTPD) with ESMTP id bb7a3f0f; Sat, 23 Dec 2023 15:13:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=AZJMAhFGc1vKNh WIpiPYj4ZtPb8=; b=hkMqatzmS0yYKrTUzQpFLfuDJ15rOC1gmPikX2PIcOUYit eYV8fk+PShjlvxLW16k7DNNjwKCiuF3O36PFEP67JH7tr9TOlTKJ96O0xKKwN6Bh WIOFMd6EiiJ7u/2EFIyerlVPk1G3uAyBb9ViLmK+OJ/jgKHgDyD3TpmQIXh58ZZ0 MSKXRXIXIXkLnNcLxdORUCVAoioNEbt9vbuCumh1DQe6ll/NsrWE7ooyb6ilFDUI pm3sFpvWN6q2x+MZEElfpfKDvX/qcMYs1CyInaAuEIOtnc7+pUmTtTd4NvKnzObp +k0IuXaXnWt1Gs/ubtCXhFHyoZGssAOfTU9dc+HQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=P/6rkEnH rI7Rdyo6oH/yXt593kxTRTn5qQAJCm5lqFcptePHPPrQqM1xB0EKt2XoqAfDmo6W Emj6dVk/E39iHnl5BOiycybBP7KsrNeQaLeB+f50mCrPX8ZRTkb1WB59CdEYYd0z im2GpalXzfiviy2+tmMouAKh8LSe/Zrmo8U8FvzZ2X8v6RRVwFxZc+y1Fl6sqNpK oAJuexzAyo/B5nIL8BtHxPcIQaKB4xycZyRDeN6872vgvG1j9eeCeK2C/qR/y6LF NUr8vdv/+z8qdPes7rOMc9QoRBEvhA2WhJmWSEmzEPgJnWGDqwYDSUfzkj+e7pL9 wSf12gb3769Ucg== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 997393f1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 23 Dec 2023 15:13:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Proposal: Disable compression of newsyslog by default From: Michael Gmelin In-Reply-To: Date: Sat, 23 Dec 2023 16:13:17 +0100 Cc: d@delphij.net, freebsd-current@freebsd.org Message-Id: <70FC144A-73DA-452E-9744-C05FF9B1257B@grem.de> References: To: Enji Cooper X-Mailer: iPhone Mail (20H240) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sy73F1hYRz3JMR > On 23. Dec 2023, at 16:10, Enji Cooper wrote: >=20 > =EF=BB=BF >> On Dec 22, 2023, at 23:18, Xin Li wrote: >>=20 >> =EF=BB=BFHi, >>=20 >> Inspired by D42961, I propose that we move forward with disabling the com= pression by default in newsyslog, as implemented in https://reviews.freebsd.= org/D43169 >>=20 >> Historically, newsyslog has compressed rotated log files to save disk spa= ce. This approach was valuable in the early days where storage space was lim= ited. However, the landscape has changed significantly. Modern file system= s, such as ZFS, now offer native compression capabilities. Additionally, the= widespread availability of larger hard drives has diminished the necessity f= or additional compression. Notably, the need to decompress log files for pa= ttern searches poses a significant inconvenience, further questioning the ut= ility of this legacy feature. >>=20 >> In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file= is eligible for compression rather than directly enforcing it. It allows fo= r a more flexible approach, wherein the actual compression method can be set= to "none" or specified as one among bzip2, gzip, xz, or zstd. >>=20 >> Therefore I would propose that we change the default compression setting t= o "none" in FreeBSD 15.0. This change reflects our adaptation to the evolvi= ng technological environment and user needs. It also aligns with the broade= r initiative to modernize our systems while maintaining flexibility and effi= ciency. >>=20 >> I look forward to your thoughts and feedback on this proposal. >=20 > This impacts embedded systems or jails which use UFS as the default /var/l= og backed device. There are quite a few larger consumers of FreeBSD out ther= e that still use UFS instead of ZFS. >=20 > Adding this instead into bsdinstall and the documentation as a suggested k= nob seems like a good way to go. >=20 > Just something to keep in mind when making this change. I would not change the default behavior (POLA violation), but adding an easy= to change knob to disable compression sounds like a reasonable approach. -m From nobody Sat Dec 23 19:13:23 2023 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 4SyDNF2gSnz54tMB for ; Sat, 23 Dec 2023 19:13:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyDNF03dnz3dyZ for ; Sat, 23 Dec 2023 19:13:33 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=y07n; t=1703358804; h=message-id : date : mime-version : reply-to : subject : to : references : from : in-reply-to : content-type : from; bh=gaRlyldmhkjOdwG07T9gcfAi4vsOO0q24sCvYW6HBKs=; b=sPMp5i2Hzsq89pitDXJuT06R64keKyW19SuPoVHm0hJPxYQTmqqMdPvqXAiCVVO1aixww d3M1JTqRXfaQFrCBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=w44o; t=1703358804; h=message-id : date : mime-version : reply-to : subject : to : references : from : in-reply-to : content-type : from; bh=gaRlyldmhkjOdwG07T9gcfAi4vsOO0q24sCvYW6HBKs=; b=hf+/HOnssu2XlvdYwU2XWNOx6UWm32S+WQuffN1kT/f5D5le6SijdlDjwo9OA4zu0Ao9c NUTC4pxxQePDcuzZhGZUjJi/ZQr+Hf6y/fL/NqvULkIM5Yq2HiXKHKa95S5WjZjYiltZzEy OLY+t96mfFi0l/0OJj+YXsbDGtxki3guwc7AWgVMF2YyXexq18kNd9CUd8x9dQoIAe6W1Uq dWqZKaPet7mAVtWKXNwNh2NWhkgiAT1ZzLL9lqgt3GnfTSi2BdHNxHuyOEVywxjB6AVzN0r Lzi1/CGc+NxF5lPj+6446hae6PnAgwTgusDEfIpZ/4Up5HQGx4QJIcTnYq/Q== Received: from xins-laptop (unknown [IPv6:2601:646:8080:7daa:957e:26ce:35b4:c915]) by anubis.delphij.net (Postfix) with ESMTPSA id B19EE21A22; Sat, 23 Dec 2023 11:13:24 -0800 (PST) Message-ID: Date: Sat, 23 Dec 2023 11:13:23 -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 Reply-To: d@delphij.net Subject: Re: Proposal: Disable compression of newsyslog by default Content-Language: en-US To: Miroslav Lachman <000.fbsd@quip.cz>, d@delphij.net, freebsd-current@freebsd.org References: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= xjMEZPbDoRYJKwYBBAHaRw8BAQdAsUNmxEWz6QiGdFbBrVVEpjNpgQV9FXjDWsLsY0UwRPvN HFhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD7ClgQTFgoAPhYhBLskk2pXNatsapeNzxED 4uuXWeTFBQJk9sRMAhsDBQkKBDXmBQsJCAcDBRUKCQgLBRYCAwEAAh4FAheAAAoJEBED4uuX WeTF6yIA/2Ls3Rb/qC8mQZ6D2S0UO5vblPghJfboFJLNJFw3i4GYAQCsTmQg3ahgbNEJu/vU xgtro2kTxa6kKnZ35IbqPqPcCc44BGT2w6ESCisGAQQBl1UBBQEBB0Cxji+sQgVPajLNA/Lw yHx0ogSalPQszdkfVgeg3iR3FAMBCAfCeAQYFgoAIBYhBLskk2pXNatsapeNzxED4uuXWeTF BQJk9sOhAhsMAAoJEBED4uuXWeTF3BQBAIx/gPCTFN2DPBrKLkE3oC/+j9EkmNLMUCGidlP/ Zb6HAP4nL1kStTsOldIGhi/3m1LvU7r3Kel3MnlIK8/9BlLPAg== In-Reply-To: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------NlIAKI4MgWxDQkdR83jB04wm" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyDNF03dnz3dyZ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------NlIAKI4MgWxDQkdR83jB04wm Content-Type: multipart/mixed; boundary="------------Lw3flNpaeKmGcAto1dfDbj0E"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Miroslav Lachman <000.fbsd@quip.cz>, d@delphij.net, freebsd-current@freebsd.org Message-ID: Subject: Re: Proposal: Disable compression of newsyslog by default References: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> In-Reply-To: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> --------------Lw3flNpaeKmGcAto1dfDbj0E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0xMi0yMyAwMDo1MSwgTWlyb3NsYXYgTGFjaG1hbiB3cm90ZToNCj4gT24gMjMv MTIvMjAyMyAwODoxOCwgWGluIExpIHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4gSW5zcGlyZWQg YnkgRDQyOTYxLCBJIHByb3Bvc2UgdGhhdCB3ZSBtb3ZlIGZvcndhcmQgd2l0aCBkaXNhYmxp bmcgdGhlIA0KPj4gY29tcHJlc3Npb24gYnkgZGVmYXVsdCBpbiBuZXdzeXNsb2csIGFzIGlt cGxlbWVudGVkIGluIA0KPj4gaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q0MzE2OQ0K Pj4NCj4+IEhpc3RvcmljYWxseSwgbmV3c3lzbG9nIGhhcyBjb21wcmVzc2VkIHJvdGF0ZWQg bG9nIGZpbGVzIHRvIHNhdmUgZGlzayANCj4+IHNwYWNlLiBUaGlzIGFwcHJvYWNoIHdhcyB2 YWx1YWJsZSBpbiB0aGUgZWFybHkgZGF5cyB3aGVyZSBzdG9yYWdlIA0KPj4gc3BhY2Ugd2Fz IGxpbWl0ZWQuwqAgSG93ZXZlciwgdGhlIGxhbmRzY2FwZSBoYXMgY2hhbmdlZCBzaWduaWZp Y2FudGx5LiAgDQo+PiBNb2Rlcm4gZmlsZSBzeXN0ZW1zLCBzdWNoIGFzIFpGUywgbm93IG9m ZmVyIG5hdGl2ZSBjb21wcmVzc2lvbiANCj4+IGNhcGFiaWxpdGllcy4gQWRkaXRpb25hbGx5 LCB0aGUgd2lkZXNwcmVhZCBhdmFpbGFiaWxpdHkgb2YgbGFyZ2VyIGhhcmQgDQo+PiBkcml2 ZXMgaGFzIGRpbWluaXNoZWQgdGhlIG5lY2Vzc2l0eSBmb3IgYWRkaXRpb25hbCBjb21wcmVz c2lvbi4gIA0KPj4gTm90YWJseSwgdGhlIG5lZWQgdG8gZGVjb21wcmVzcyBsb2cgZmlsZXMg Zm9yIHBhdHRlcm4gc2VhcmNoZXMgcG9zZXMgYSANCj4+IHNpZ25pZmljYW50IGluY29udmVu aWVuY2UsIGZ1cnRoZXIgcXVlc3Rpb25pbmcgdGhlIHV0aWxpdHkgb2YgdGhpcyANCj4+IGxl Z2FjeSBmZWF0dXJlLg0KPj4NCj4+IEluIGNvbW1pdCA5MDY3NDhkMjA4ZDMsIGZsYWdzIEos IFgsIFksIFogY2FuIG5vdyBpbmRpY2F0ZSB0aGF0IGEgbG9nIA0KPj4gZmlsZSBpcyBlbGln aWJsZSBmb3IgY29tcHJlc3Npb24gcmF0aGVyIHRoYW4gZGlyZWN0bHkgZW5mb3JjaW5nIGl0 LiBJdCANCj4+IGFsbG93cyBmb3IgYSBtb3JlIGZsZXhpYmxlIGFwcHJvYWNoLCB3aGVyZWlu IHRoZSBhY3R1YWwgY29tcHJlc3Npb24gDQo+PiBtZXRob2QgY2FuIGJlIHNldCB0byAibm9u ZSIgb3Igc3BlY2lmaWVkIGFzIG9uZSBhbW9uZyBiemlwMiwgZ3ppcCwgeHosIA0KPj4gb3Ig enN0ZC4NCj4+DQo+PiBUaGVyZWZvcmUgSSB3b3VsZCBwcm9wb3NlIHRoYXQgd2UgY2hhbmdl IHRoZSBkZWZhdWx0IGNvbXByZXNzaW9uIA0KPj4gc2V0dGluZyB0byAibm9uZSIgaW4gRnJl ZUJTRCAxNS4wLsKgIFRoaXMgY2hhbmdlIHJlZmxlY3RzIG91ciANCj4+IGFkYXB0YXRpb24g dG8gdGhlIGV2b2x2aW5nIHRlY2hub2xvZ2ljYWwgZW52aXJvbm1lbnQgYW5kIHVzZXIgbmVl ZHMuICANCj4+IEl0IGFsc28gYWxpZ25zIHdpdGggdGhlIGJyb2FkZXIgaW5pdGlhdGl2ZSB0 byBtb2Rlcm5pemUgb3VyIHN5c3RlbXMgDQo+PiB3aGlsZSBtYWludGFpbmluZyBmbGV4aWJp bGl0eSBhbmQgZWZmaWNpZW5jeS4NCj4+DQo+PiBJIGxvb2sgZm9yd2FyZCB0byB5b3VyIHRo b3VnaHRzIGFuZCBmZWVkYmFjayBvbiB0aGlzIHByb3Bvc2FsLg0KPiANCj4gSSBkb24ndCB0 aGluayBhbnl0aGluZyBuZWVkcyB0byBiZSBjaGFuZ2VkIG9uIG5ld3N5c2xvZy4gVGhvc2Ug d2hvIHdhbnQgDQo+IHRvIGRpc2FibGUgY29tcHJlc3Npb24gY2FuIGRvIHNvIGluIHRoZSAi ZGVmYXVsdCIgbmV3c3lzbG9nLmNvbmYgZmlsZS4gDQo+IFdoeSBmb3JjZSB0aGlzIGNoYW5n ZSBpbiB0aGUgbmV3c3lzbG9nIGNvZGU/DQo+IEkgYWxzbyBkb24ndCB0aGluayB0aGF0IHRo ZSBsb2cgZmlsZSBzaG91bGQgbm90IGJlIGNvbXByZXNzZWQgZXZlbiBvbiBhIA0KPiBjb21w cmVzc2VkIGZpbGVzeXN0ZW0uIENvbXByZXNzZWQgbG9nIGZpbGVzIGNhbiBiZSBoYW5kbGVk IGJ5IHRvb2xzIGxpa2UgDQo+IHpjYXQsIHpsZXNzLCB6Z3JlcCwgZXRjLiB3aXRob3V0IGZp cnN0IGRlY29tcHJlc3NpbmcgdGhlIGxvZyBmaWxlLiBUZXh0IA0KPiBsb2cgZmlsZXMgY2Fu IHN0aWxsIGdyb3cgdG8gbGFyZ2Ugc2l6ZXMsIGFuZCBpZiB5b3UgaGF2ZSBhIGRhaWx5IGJh Y2t1cCANCj4gam9iIG92ZXIgYSBsb25nIGRpc3RhbmNlIG5ldHdvcmssIGlmIHlvdSB1c2Ug YSBwcm90b2NvbCB3aXRob3V0IG93biANCj4gY29tcHJlc3Npb24sIGl0IGlzIHN0aWxsIGJl dHRlciB0byBoYXZlIGNvbXByZXNzZWQgbG9nIGZpbGVzIHRoYW4gDQo+IHVuY29tcHJlc3Nl ZCBvbiBhIGNvbXByZXNzZWQgZmlsZXN5c3RlbS4gVG8gbWUsIGl0J3MgdGhlIHNhbWUgYXMg DQo+IGNvbXByZXNzaW5nIGxhcmdlIGRhdGFiYXNlIGR1bXBzIGFuZCBub3QgcmVseWluZyBv biBmaWxlc3lzdGVtIGNvbXByZXNzaW9uLg0KPiBZTU1WLCBidXQgSSByZWFsbHkgZG9uJ3Qg c2VlIGFueSBiZW5lZml0IG9mIGNoYW5naW5nIHRoZSBuZXdzeXNsb2cgY29kZSwgDQo+IGp1 c3QgY2hhbmdlIGRlZmF1bHRzIGluIG5ld3N5c2xvZy5jb25mLg0KDQpJIGFwcHJlY2lhdGUg eW91ciBwZXJzcGVjdGl2ZSBvbiB0aGlzIGlzc3VlLiBIb3dldmVyLCBJIGJlbGlldmUgdGhl cmUgDQphcmUgYWRkaXRpb25hbCBiZW5lZml0cyB0byBtb2RpZnlpbmcgdGhlIG5ld3N5c2xv ZyBjb2RlICh3aGljaCBpcyANCmFscmVhZHkgZG9uZSBpbiBjb21taXQgOTA2NzQ4ZDIwOGQz LCBieSB0aGUgd2F5KSBiZXlvbmQgd2hhdCBjYW4gYmUgDQphY2hpZXZlZCBieSBzaW1wbHkg YWRqdXN0aW5nIHRoZSBkZWZhdWx0cyBpbiBuZXdzeXNsb2cuY29uZi4NCg0KRmlyc3RseSwg dXBkYXRpbmcgdGhlIG5ld3N5c2xvZyBjb2RlIHByb3ZpZGVzIHVzIHdpdGggZ3JlYXRlciAN CmZsZXhpYmlsaXR5IHdoZW4gaW50cm9kdWNpbmcgbmV3IGNvbXByZXNzaW9uIG1vZGVzLCBz dWNoIGFzICd4eiAtOWUnLCBvciANCmluIHN1cHBvcnRpbmcgb3RoZXIgY29tcHJlc3NvcnMu IFRoaXMgYXBwcm9hY2ggaXMgbW9yZSBlZmZpY2llbnQgdGhhbiANCmNvbnRpbnVhbGx5IGFk ZGluZyBuZXcgbGV0dGVycyB0byByZXByZXNlbnQgZWFjaCBjb21wcmVzc2lvbiBtZXRob2Qg aW4gDQp0aGUgY29uZmlndXJhdGlvbiBmaWxlLiBJdCBzaW1wbGlmaWVzIHRoZSBwcm9jZXNz IGFuZCBhdm9pZHMgdW5uZWNlc3NhcnkgDQpjb21wbGV4aXR5Lg0KDQpGdXJ0aGVybW9yZSwg dGhlIHByZXZpb3VzIG1ldGhvZCBvZiByZXByZXNlbnRpbmcgY29tcHJlc3Npb24gbWV0aG9k cyBpbiANCnRoZSBjb25maWd1cmF0aW9uIGZpbGUgY2FuIGJlIGN1bWJlcnNvbWUgZm9yIHVz ZXJzIHdobyBoYXZlIGRpc2FibGVkIG9yIA0KYWx0ZXJlZCB0aGVpciBjb21wcmVzc2lvbiBj b25maWd1cmF0aW9uLiAgRWFjaCB0aW1lIHRoZXJlIGlzIGEgY2hhbmdlIGluIA0KbmV3c3lz bG9nLmNvbmYsIHRoZXNlIHVzZXJzIGZhY2UgcG90ZW50aWFsIGNvbmZsaWN0cyB0aGF0IHJl cXVpcmUgbWFudWFsIA0KcmVzb2x1dGlvbi4gIFVwZGF0aW5nIHRoZSBjb2RlIHdvdWxkIG1h a2UgdGhlIGNvbmZpZ3VyYXRpb24gaW4gb25lIA0KY2VudHJhbCBwbGFjZSAoL2V0Yy9jcm9u dGFiKSB0aGVyZWZvcmUgc2ltcGxpZnlpbmcgbWFpbnRlbmFuY2UgZm9yIHVzZXJzIA0KYW5k IGFkbWluaXN0cmF0b3JzIGFsaWtlLg0KDQpXaGlsZSBJIGFja25vd2xlZGdlIHlvdXIgcG9p bnRzIHJlZ2FyZGluZyB0aGUgdXRpbGl0eSBvZiBjb21wcmVzc2VkIGxvZyANCmZpbGVzLCBl c3BlY2lhbGx5IGluIHNjZW5hcmlvcyBpbnZvbHZpbmcgZGFpbHkgYmFja3VwcyBvdmVyIA0K bG9uZy1kaXN0YW5jZSBuZXR3b3JrcywgSSBiZWxpZXZlIHRoZSBmbGV4aWJpbGl0eSBhbmQg ZWFzZSBvZiANCm1haW50ZW5hbmNlIG9mZmVyZWQgYnkgdXBkYXRpbmcgdGhlIGNvZGUgd291 bGQgYmUgYSBzaWduaWZpY2FudCANCmltcHJvdmVtZW50IGZvciBtYW55IHVzZXJzLg0KDQpM b29raW5nIGZvcndhcmQgdG8gZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoaXMuDQoNCkNoZWVy cywNCg== --------------Lw3flNpaeKmGcAto1dfDbj0E-- --------------NlIAKI4MgWxDQkdR83jB04wm Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZYcxUwUDAAAAAAAKCRARA+Lrl1nkxb0B AQD+smDe3BfMvugmrDQEtTRm46FmOiQiomC27/Jvp76mjAD/Zp1mqg6vo+Pe0nNsalwbLLGiwXXF t+PEiErjJlElAgs= =se03 -----END PGP SIGNATURE----- --------------NlIAKI4MgWxDQkdR83jB04wm-- From nobody Sat Dec 23 19:22:11 2023 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 4SyDZG1Tl5z54tjF for ; Sat, 23 Dec 2023 19:22:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyDZF60Bsz3gHj for ; Sat, 23 Dec 2023 19:22:13 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=y07n; t=1703359332; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=KpduY6w8XOR+Yzbw+Uv2pwkzNUBQMUFF9zZU8EmOwhE=; b=ADGfymtQZyomyjs/sAx4ZYV7nSoKmKta31M4D1TpKRSQ/ukJ0dJ2511BR5sHjnOgHi3LX mKTSeBkBUlv/KXkBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=w44o; t=1703359332; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=KpduY6w8XOR+Yzbw+Uv2pwkzNUBQMUFF9zZU8EmOwhE=; b=pmzhRErQe0gDNlK73cg7nzxfyYA9p/iD3fYD5p9A232aAb1t9Uyr3AdbTP+gi65CziFsx aQel5sXQ79+C3AdJ9P+g3DyTLs+JuA5RXAccunPHkSGsBhgobNDLx0vPyrSTX/7rtSQeLhL tHspUi/sDgf0tainRp3vR5bxNOq+Dprf454JtwSW1CN2l6SDTyxvQ+crEhJlEf47fWcBZqv wdJpC/kw2CkTC+OX9ONG6iOhW0yDGt2rT5LBgMiGhovpm+Zc5YY0inBCyb42ctdZQlmv7vH qX0PYt+5/pxxreJkRHLsbQKqzU/kkx858E4byNsghoqOqQMcNSL2Kp7bqaRA== Received: from xins-laptop (unknown [IPv6:2601:646:8080:7daa:957e:26ce:35b4:c915]) by anubis.delphij.net (Postfix) with ESMTPSA id 2FCD72165B; Sat, 23 Dec 2023 11:22:12 -0800 (PST) Message-ID: Date: Sat, 23 Dec 2023 11:22:11 -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 Reply-To: d@delphij.net Subject: Re: Proposal: Disable compression of newsyslog by default Content-Language: en-US To: Konstantin Belousov , d@delphij.net Cc: freebsd-current@freebsd.org References: From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= xjMEZPbDoRYJKwYBBAHaRw8BAQdAsUNmxEWz6QiGdFbBrVVEpjNpgQV9FXjDWsLsY0UwRPvN HFhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD7ClgQTFgoAPhYhBLskk2pXNatsapeNzxED 4uuXWeTFBQJk9sRMAhsDBQkKBDXmBQsJCAcDBRUKCQgLBRYCAwEAAh4FAheAAAoJEBED4uuX WeTF6yIA/2Ls3Rb/qC8mQZ6D2S0UO5vblPghJfboFJLNJFw3i4GYAQCsTmQg3ahgbNEJu/vU xgtro2kTxa6kKnZ35IbqPqPcCc44BGT2w6ESCisGAQQBl1UBBQEBB0Cxji+sQgVPajLNA/Lw yHx0ogSalPQszdkfVgeg3iR3FAMBCAfCeAQYFgoAIBYhBLskk2pXNatsapeNzxED4uuXWeTF BQJk9sOhAhsMAAoJEBED4uuXWeTF3BQBAIx/gPCTFN2DPBrKLkE3oC/+j9EkmNLMUCGidlP/ Zb6HAP4nL1kStTsOldIGhi/3m1LvU7r3Kel3MnlIK8/9BlLPAg== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------M1CBqgYh7ZbJ35MEVqjj0BQa" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyDZF60Bsz3gHj This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M1CBqgYh7ZbJ35MEVqjj0BQa Content-Type: multipart/mixed; boundary="------------jYFrbQMwsaTfQnaFGCAxtBcS"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Konstantin Belousov , d@delphij.net Cc: freebsd-current@freebsd.org Message-ID: Subject: Re: Proposal: Disable compression of newsyslog by default References: In-Reply-To: --------------jYFrbQMwsaTfQnaFGCAxtBcS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0xMi0yMyAwNjo1MiwgS29uc3RhbnRpbiBCZWxvdXNvdiB3cm90ZToNCj4gT24g RnJpLCBEZWMgMjIsIDIwMjMgYXQgMTE6MTg6MjNQTSAtMDgwMCwgWGluIExpIHdyb3RlOg0K Pj4gSGksDQo+Pg0KPj4gSW5zcGlyZWQgYnkgRDQyOTYxLCBJIHByb3Bvc2UgdGhhdCB3ZSBt b3ZlIGZvcndhcmQgd2l0aCBkaXNhYmxpbmcgdGhlDQo+PiBjb21wcmVzc2lvbiBieSBkZWZh dWx0IGluIG5ld3N5c2xvZywgYXMgaW1wbGVtZW50ZWQgaW4NCj4+IGh0dHBzOi8vcmV2aWV3 cy5mcmVlYnNkLm9yZy9ENDMxNjkNCj4+DQo+PiBIaXN0b3JpY2FsbHksIG5ld3N5c2xvZyBo YXMgY29tcHJlc3NlZCByb3RhdGVkIGxvZyBmaWxlcyB0byBzYXZlIGRpc2sgc3BhY2UuDQo+ PiBUaGlzIGFwcHJvYWNoIHdhcyB2YWx1YWJsZSBpbiB0aGUgZWFybHkgZGF5cyB3aGVyZSBz dG9yYWdlIHNwYWNlIHdhcw0KPj4gbGltaXRlZC4gIEhvd2V2ZXIsIHRoZSBsYW5kc2NhcGUg aGFzIGNoYW5nZWQgc2lnbmlmaWNhbnRseS4gIE1vZGVybiBmaWxlDQo+PiBzeXN0ZW1zLCBz dWNoIGFzIFpGUywgbm93IG9mZmVyIG5hdGl2ZSBjb21wcmVzc2lvbiBjYXBhYmlsaXRpZXMu DQo+PiBBZGRpdGlvbmFsbHksIHRoZSB3aWRlc3ByZWFkIGF2YWlsYWJpbGl0eSBvZiBsYXJn ZXIgaGFyZCBkcml2ZXMgaGFzDQo+PiBkaW1pbmlzaGVkIHRoZSBuZWNlc3NpdHkgZm9yIGFk ZGl0aW9uYWwgY29tcHJlc3Npb24uICBOb3RhYmx5LCB0aGUgbmVlZCB0bw0KPj4gZGVjb21w cmVzcyBsb2cgZmlsZXMgZm9yIHBhdHRlcm4gc2VhcmNoZXMgcG9zZXMgYSBzaWduaWZpY2Fu dCBpbmNvbnZlbmllbmNlLA0KPj4gZnVydGhlciBxdWVzdGlvbmluZyB0aGUgdXRpbGl0eSBv ZiB0aGlzIGxlZ2FjeSBmZWF0dXJlLg0KPj4NCj4+IEluIGNvbW1pdCA5MDY3NDhkMjA4ZDMs IGZsYWdzIEosIFgsIFksIFogY2FuIG5vdyBpbmRpY2F0ZSB0aGF0IGEgbG9nIGZpbGUgaXMN Cj4+IGVsaWdpYmxlIGZvciBjb21wcmVzc2lvbiByYXRoZXIgdGhhbiBkaXJlY3RseSBlbmZv cmNpbmcgaXQuIEl0IGFsbG93cyBmb3IgYQ0KPj4gbW9yZSBmbGV4aWJsZSBhcHByb2FjaCwg d2hlcmVpbiB0aGUgYWN0dWFsIGNvbXByZXNzaW9uIG1ldGhvZCBjYW4gYmUgc2V0IHRvDQo+ PiAibm9uZSIgb3Igc3BlY2lmaWVkIGFzIG9uZSBhbW9uZyBiemlwMiwgZ3ppcCwgeHosIG9y IHpzdGQuDQo+Pg0KPj4gVGhlcmVmb3JlIEkgd291bGQgcHJvcG9zZSB0aGF0IHdlIGNoYW5n ZSB0aGUgZGVmYXVsdCBjb21wcmVzc2lvbiBzZXR0aW5nIHRvDQo+PiAibm9uZSIgaW4gRnJl ZUJTRCAxNS4wLiAgVGhpcyBjaGFuZ2UgcmVmbGVjdHMgb3VyIGFkYXB0YXRpb24gdG8gdGhl IGV2b2x2aW5nDQo+PiB0ZWNobm9sb2dpY2FsIGVudmlyb25tZW50IGFuZCB1c2VyIG5lZWRz LiAgSXQgYWxzbyBhbGlnbnMgd2l0aCB0aGUgYnJvYWRlcg0KPj4gaW5pdGlhdGl2ZSB0byBt b2Rlcm5pemUgb3VyIHN5c3RlbXMgd2hpbGUgbWFpbnRhaW5pbmcgZmxleGliaWxpdHkgYW5k DQo+PiBlZmZpY2llbmN5Lg0KPj4NCj4+IEkgbG9vayBmb3J3YXJkIHRvIHlvdXIgdGhvdWdo dHMgYW5kIGZlZWRiYWNrIG9uIHRoaXMgcHJvcG9zYWwuDQo+IA0KPiBUaGlzIGlzIHN0cmFu Z2UgY2hhbmdlIGF0IGJlc3QuICBJIGhhdmUgbm8gb3BpbmlvbiBhYm91dCB0aGUgZGlzYWJs aW5nDQo+IG9mIGNvbXByZXNzaW9uIG9mIHRoZSByb3RhdGVkIGxvZ3MgYnkgZGVmYXVsdCwg YnV0IHdlIGFscmVhZHkgaGF2ZSBrbm9icw0KPiB0byBkbyB0aGF0LiAgQWRkaW5nIGEga25v YiB0aGF0IGRpc2FibGVzIChvciBlbmFibGVzKSBvdGhlciBrbm9icyB0byB3b3JrDQo+IGlz IHdlaXJkLg0KPiANCj4gSWYgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSBjb21wcmVzc2lvbiwg dXBkYXRlIHRoZSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gZmlsZS4NCg0KVGhlIHByaW1hcnkg aXNzdWUgd2l0aCBzaW1wbHkgdXBkYXRpbmcgdGhlIGRlZmF1bHQgY29uZmlndXJhdGlvbiBm aWxlIGlzIA0KdGhlIGluY3JlYXNlZCB3b3JrbG9hZCBpdCBpbXBvc2VzIGR1cmluZyBzeXN0 ZW0gdXBncmFkZXMuIFNpbmNlIHRoZSANCmNvbXByZXNzaW9uIG1ldGhvZCBmbGFnIGlzIGEg cGFydCBvZiBuZXdzeXNsb2cuY29uZiwgc3RhbmRhcmQgY29uZmxpY3QgDQpyZXNvbHV0aW9u IHRvb2xzIGxpa2UgZGlmZjMgc3RydWdnbGUgdG8gYXV0b21hdGljYWxseSByZXNvbHZlIGNo YW5nZXMgDQppbnZvbHZpbmcgdGhlc2UgZmxhZ3Mgd2l0aG91dCBtYW51YWwgaW50ZXJ2ZW50 aW9uLiBUaGlzIHNpdHVhdGlvbiANCm5lY2Vzc2l0YXRlcyB0aGF0IHVzZXJzIG1hbnVhbGx5 IHJlY29uY2lsZSB0aGVpciBjb25maWd1cmF0aW9uIHdpdGggDQpldmVyeSB1cGRhdGUgdG8g bmV3c3lzbG9nLmNvbmYsIGV2ZW4gZm9yIG1pbm9yIGFsdGVyYXRpb25zIGxpa2UgDQpzd2l0 Y2hpbmcgdGhlIGRlZmF1bHQgY29tcHJlc3Npb24gbWV0aG9kLg0KDQpUaGVyZWZvcmUsIHRo ZSBwcm9wb3NhbCBpc24ndCBhYm91dCBhZGRpbmcgYW5vdGhlciBrbm9iIHdpdGhpbiANCm5l d3N5c2xvZy5jb25mLiBSYXRoZXIsIGl0J3MgYWJvdXQgaW50cm9kdWNpbmcgYSBjb21tYW5k LWxpbmUgb3B0aW9uIGZvciANCm5ld3N5c2xvZyAodG8gYmUgdXNlZCBpbiAvZXRjL2Nyb250 YWIpIHRoYXQgc3BlY2lmaWVzIHRoZSBwcmVmZXJyZWQgDQpjb21wcmVzc2lvbiBtZXRob2Qs IG9yIHRoZSBjaG9pY2Ugbm90IHRvIGNvbXByZXNzIGF0IGFsbC4gVGhpcyBhcHByb2FjaCAN CmlzIG1vcmUgc2VsZi1jb250YWluZWQgY29tcGFyZWQgdG8gbW9kaWZ5aW5nIGVhY2ggbGlu ZSBpbiANCm5ld3N5c2xvZy5jb25mLiBJdCBvZmZlcnMgYSBzaW1wbGVyLCBtb3JlIHN0cmFp Z2h0Zm9yd2FyZCBzb2x1dGlvbiBmb3IgDQphZG1pbmlzdHJhdG9ycyB0byBtYW5hZ2UgdGhl aXIgY29tcHJlc3Npb24gc2V0dGluZ3MsIHJlZHVjaW5nIHRoZSANCmFkbWluaXN0cmF0aXZl IGJ1cmRlbiBkdXJpbmcgdXBncmFkZXMuDQoNCkkgaG9wZSB0aGlzIGNsYXJpZmllcyB0aGUg cmF0aW9uYWxlIGJlaGluZCB0aGUgcHJvcG9zZWQgY2hhbmdlcyBhbmQgDQp0aGVpciBwb3Rl bnRpYWwgYmVuZWZpdHMuDQo= --------------jYFrbQMwsaTfQnaFGCAxtBcS-- --------------M1CBqgYh7ZbJ35MEVqjj0BQa Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZYczYwUDAAAAAAAKCRARA+Lrl1nkxTGa AQDAwHFC+Wokf/qeAJvW3SWV8NqC3Cgbc+3u8n/0OTz4OwD/f7hLmbf3kvgT7sAXXABl+tvuEa4f Hw7VoqVENle8uQ8= =6MMx -----END PGP SIGNATURE----- --------------M1CBqgYh7ZbJ35MEVqjj0BQa-- From nobody Sat Dec 23 21:08:36 2023 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 4SyGxG2NxPz551Cy for ; Sat, 23 Dec 2023 21:08:50 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.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 4SyGxF6zlbz4Nbb for ; Sat, 23 Dec 2023 21:08:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 3BNL8aEa018921; Sat, 23 Dec 2023 13:08:36 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 3BNL8aNG018920; Sat, 23 Dec 2023 13:08:36 -0800 (PST) (envelope-from sgk) Date: Sat, 23 Dec 2023 13:08:36 -0800 From: Steve Kargl To: Xin Li Cc: Miroslav Lachman <000.fbsd@quip.cz>, d@delphij.net, freebsd-current@freebsd.org Subject: Re: Proposal: Disable compression of newsyslog by default Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> 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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyGxF6zlbz4Nbb On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote: > > I appreciate your perspective on this issue. However, I believe there are > additional benefits to modifying the newsyslog code (which is already done > in commit 906748d208d3, by the way) beyond what can be achieved by simply > adjusting the defaults in newsyslog.conf. Why ask for others opinions if you're simply going to commit the change? It seems the commit (23 Dec 2023 06:53:06 UTC) occurred before the initial post in the discussion here (23 Dec 2023 07:18:23 UTC). -- Steve From nobody Sat Dec 23 21:23:02 2023 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 4SyHFj1d9lz5529l for ; Sat, 23 Dec 2023 21:23:05 +0000 (UTC) (envelope-from leres@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyHFj17ltz4R8Q; Sat, 23 Dec 2023 21:23:05 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703366585; 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=UZTb30dbfwKPbGyV2xppFZ9wGfeb+cO2CRPTI9tOVKE=; b=NWpeuF2ywE8It1xR5w5UOx+aWfY/5KHKbyGVqIgE7UV6jWIn+ey9u2e67oSnjtQEqNSCvg lH+g6tIw+uimVHUD4DeRwzClVB4qDwM4WQLnBBIdJJQQsvc7IOVA/zvWlGH6Qn6HeY2vjr cOdpN6Co+D25w9HygviuQ0maPDCpwH7oCt/LWtO+65F54nHHDvDHpj9YHWJt+Y1D3+ksJG Zc/AdeKHGP8PtYVIJXGvsfW4iXTCaqlB5bE2tz+lS1QtxZGkd4ZAlkbkW9T6wvD8wkR8rk WDgWYIX5k+xSGIxZERXcKahMrFUzVaKC8238LwjthjkWo2RnZc9aVv7qLpqG/A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703366585; a=rsa-sha256; cv=none; b=rSmqDMQbQ85XcONCRLjMdaANkLKxNVMDJO9jMeEB5XfLd5t5ibO8ufqTI6cjFpBIYoud0v xdkoFraQDERlTC7nfKwR2Dai/8hYaXtW1ABdQ/FABhsPLFz5u5ChFdiPsGHzDmHEvv5rri gPvRK53633LA+ED/pvFntahGwf7OW+1W65RrNdnalp4k1H8VHOyKrZGOO2gA6J4dQHyM6J zAQet2t618Mrt7sjNTOYcc9EmlUZfj16EpaRbQDglUCleu3aeolKAtEfhVv+5Pe4XaxSJw GmN7odMHwrbfsLmvvqraWbbMn+A1LhZSVLG2SGid12BuY8ZHgeJaG0I2LUWqwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703366585; 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=UZTb30dbfwKPbGyV2xppFZ9wGfeb+cO2CRPTI9tOVKE=; b=BvnObzbwalyAC8sRfaRyBHLJWHIMW029yO5hRmXsAJSaKzn5GjLqilaW1/MsID+ZW26QKY jIKr/x4bXX06xQKj5b2C0GdX5RJ+JyWRNPkOE+Go/y53B1LmQaur+yGZnWQXWFIJdX2acF vfoYlDUmVbfNYQC4866PPvMdoPuDHBHvis5Vweumiirf1NFQwM6Oow+sxWACl+DFrlzxOt iqKo+FldRG3ZjCOfGdcyBxio6LfAKbnCUVawQq1aK7uBcSxYJ7AhZL31ahJc3+ltYbZ6lc 990xlXBmvipc9PziJbIIF/4PmHEK/aFYZnqgbTpHwatNwBu8B2hDOGUkKLPilA== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27]) (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: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SyHFh52Tcz1GCW; Sat, 23 Dec 2023 21:23:04 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: Date: Sat, 23 Dec 2023 13:23:02 -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: Proposal: Disable compression of newsyslog by default Content-Language: en-US To: Konstantin Belousov , d@delphij.net Cc: freebsd-current@freebsd.org References: From: Craig Leres In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/23/23 06:52, Konstantin Belousov wrote: > This is strange change at best. I have no opinion about the disabling > of compression of the rotated logs by default, but we already have knobs > to do that. Adding a knob that disables (or enables) other knobs to work > is weird. I totally agree. This moves the compression knob from the config file to the command line. And what if the user wants some but not all files to be compressed? Or wants to use different compression with different log files? > If you want to change the compression, update the default configuration file. I also think this is the best approach. Given the current freebsd-update workflow, users will get to deal with changes to the default newsyslog.conf via mergemaster. And having converted a number of systems from newsyslog compression to zfs compression, just changing the config file is not the only change needed, users will still need to compress/uncompress existing log files. Craig From nobody Sat Dec 23 22:17:31 2023 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 4SyJSf6Wkzz555Kt for ; Sat, 23 Dec 2023 22:17:38 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyJSf4H56z4WCh; Sat, 23 Dec 2023 22:17:38 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3BNMHWSP076511; Sat, 23 Dec 2023 16:17:32 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1703369852; bh=jg1xqSHV0OHDJHAeZsjQDXPmjT67Ig6FrdJVsTBDZ1s=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Mha/73yZ2ZrBqD4WS/PE/CFdB/Ja3LFfTzmFM3nujQZPNRMefXYHO0fFJznwXRbl4 3zYORH5+aJrkWsAuN0KatBwsI9eVUlO3RDb/9/jtupVMe2u5frGEf3hTz8iSMTDBJl abRNf0ucNo04efeTcfbM3jo0bjNPTaPoA8ThSWNr1lMaphcWHI0SAAZ4UgOIoaPO37 oJvrLSGHPvdEORVLYuSJDkS7jVIlabbFt85WpAd6xnbynIMfW7SwIe+yl17Lxl9Nc3 xSvNOdBmO6nP7zSmVR2vS+DSYtfWKZ5cslZfESux/4i6QoZ9RgDzlwJ7Qa1FpW3iF1 dCcUT5FkrreTg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id HUH5Hnxch2XdKgEAs/W3XQ (envelope-from ); Sat, 23 Dec 2023 16:17:32 -0600 From: Mike Karels To: Craig Leres Cc: Konstantin Belousov , d@delphij.net, freebsd-current@freebsd.org Subject: Re: Proposal: Disable compression of newsyslog by default Date: Sat, 23 Dec 2023 16:17:31 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <71C3C779-ACD1-4FF4-A213-5DBCD7707ED7@karels.net> In-Reply-To: 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 Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyJSf4H56z4WCh On 23 Dec 2023, at 15:23, Craig Leres wrote: > On 12/23/23 06:52, Konstantin Belousov wrote: >> This is strange change at best. I have no opinion about the disabling= >> of compression of the rotated logs by default, but we already have kno= bs >> to do that. Adding a knob that disables (or enables) other knobs to w= ork >> is weird. > > I totally agree. This moves the compression knob from the config file t= o the command line. And what if the user wants some but not all files to = be compressed? Or wants to use different compression with different log f= iles? Another possibility would be to introduce some simple form of variables i= n newsyslog.conf, replacing J by a variable reference, with the variable being set near the beginning. E.g. V=3Dzstd (or just V=3D for none?) ... $V ... $V Then there would be one global change, and much easier changing of the default. It would also be possible to add /etc/newsyslog.local.conf at t= he beginning, and set variables there, making changes to the default file le= ss painful in the future. >> If you want to change the compression, update the default configuratio= n file. > > I also think this is the best approach. > > Given the current freebsd-update workflow, users will get to deal with = changes to the default newsyslog.conf via mergemaster. > > And having converted a number of systems from newsyslog compression to = zfs compression, just changing the config file is not the only change nee= ded, users will still need to compress/uncompress existing log files. Good point. Although newsyslog could be smart enough to recognize altern= ate suffixes (or none), and rotate the files anyway. Short of that, this sug= gests that a new default config file should specify bzip2, but it would be easy= to localize. Mike From nobody Sat Dec 23 22:35:30 2023 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 4SyJsM23hRz556L4 for ; Sat, 23 Dec 2023 22:35:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyJsM099Pz4YlJ for ; Sat, 23 Dec 2023 22:35:35 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=y07n; t=1703370932; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=o37ByDmgGWqdRljZy5JoSFRR1hPJvMiY98GHDoR3mMc=; b=WbsaCr+q5xGMAd95taR7PoDqhtAt1iibkLJ+KE+dbbeHZ+zZGlBguEVybbHRM0Q/XCe61 664Gi7S8Cg8HXtgBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=w44o; t=1703370932; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=o37ByDmgGWqdRljZy5JoSFRR1hPJvMiY98GHDoR3mMc=; b=horEZ5p5PHl2mkWd5b+TS/bT7igqx/kSEc7Xhj6s2d1oHtby9yQ69IDd8JUnEeLUuhEnH Q34Ot3goBU887WuOw8ruQLmbpRSrzWhMHiWvLmiA5kdFslZR4XSRCA4Jc0h4ODMEF/Nk1G7 7aO2Zgd6vbm8bJCeJIlGV8KktYOhqYENuqI0aOQNIffUHQT5lCw+4DZCQaAUZ5SFDDsjt03 m8wxfy32LyrU3i0PxCcrB/VncPUoO7e8Rc5fMhGyXuGDXiqOfCyCJUyM8f9SIvYJAqkx92K P8rHHmzu+NTwJZgsH7C4gqaE1WcwuuCq5FXmpyrle0yyUxZMs1axss/ErM/w== Received: from xins-laptop (unknown [IPv6:2601:646:8080:7daa:957e:26ce:35b4:c915]) by anubis.delphij.net (Postfix) with ESMTPSA id F324321B02; Sat, 23 Dec 2023 14:35:31 -0800 (PST) Message-ID: <2bf66ded-910a-4902-b18f-4e11785f9208@delphij.net> Date: Sat, 23 Dec 2023 14:35:30 -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 Reply-To: d@delphij.net Subject: Re: Proposal: Disable compression of newsyslog by default Content-Language: en-US To: sgk@troutmask.apl.washington.edu Cc: Miroslav Lachman <000.fbsd@quip.cz>, d@delphij.net, freebsd-current@freebsd.org References: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= xjMEZPbDoRYJKwYBBAHaRw8BAQdAsUNmxEWz6QiGdFbBrVVEpjNpgQV9FXjDWsLsY0UwRPvN HFhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD7ClgQTFgoAPhYhBLskk2pXNatsapeNzxED 4uuXWeTFBQJk9sRMAhsDBQkKBDXmBQsJCAcDBRUKCQgLBRYCAwEAAh4FAheAAAoJEBED4uuX WeTF6yIA/2Ls3Rb/qC8mQZ6D2S0UO5vblPghJfboFJLNJFw3i4GYAQCsTmQg3ahgbNEJu/vU xgtro2kTxa6kKnZ35IbqPqPcCc44BGT2w6ESCisGAQQBl1UBBQEBB0Cxji+sQgVPajLNA/Lw yHx0ogSalPQszdkfVgeg3iR3FAMBCAfCeAQYFgoAIBYhBLskk2pXNatsapeNzxED4uuXWeTF BQJk9sOhAhsMAAoJEBED4uuXWeTF3BQBAIx/gPCTFN2DPBrKLkE3oC/+j9EkmNLMUCGidlP/ Zb6HAP4nL1kStTsOldIGhi/3m1LvU7r3Kel3MnlIK8/9BlLPAg== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------3mjFOuqwMvj3I7QWo5B0tqDC" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyJsM099Pz4YlJ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3mjFOuqwMvj3I7QWo5B0tqDC Content-Type: multipart/mixed; boundary="------------500r1jg8ZpbJiF9vovU0fONd"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: sgk@troutmask.apl.washington.edu Cc: Miroslav Lachman <000.fbsd@quip.cz>, d@delphij.net, freebsd-current@freebsd.org Message-ID: <2bf66ded-910a-4902-b18f-4e11785f9208@delphij.net> Subject: Re: Proposal: Disable compression of newsyslog by default References: <8a585a40-0e78-4dbd-9701-aa0926ccde19@quip.cz> In-Reply-To: --------------500r1jg8ZpbJiF9vovU0fONd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0xMi0yMyAxMzowOCwgU3RldmUgS2FyZ2wgd3JvdGU6DQo+IE9uIFNhdCwgRGVj IDIzLCAyMDIzIGF0IDExOjEzOjIzQU0gLTA4MDAsIFhpbiBMaSB3cm90ZToNCj4+DQo+PiBJ IGFwcHJlY2lhdGUgeW91ciBwZXJzcGVjdGl2ZSBvbiB0aGlzIGlzc3VlLiBIb3dldmVyLCBJ IGJlbGlldmUgdGhlcmUgYXJlDQo+PiBhZGRpdGlvbmFsIGJlbmVmaXRzIHRvIG1vZGlmeWlu ZyB0aGUgbmV3c3lzbG9nIGNvZGUgKHdoaWNoIGlzIGFscmVhZHkgZG9uZQ0KPj4gaW4gY29t bWl0IDkwNjc0OGQyMDhkMywgYnkgdGhlIHdheSkgYmV5b25kIHdoYXQgY2FuIGJlIGFjaGll dmVkIGJ5IHNpbXBseQ0KPj4gYWRqdXN0aW5nIHRoZSBkZWZhdWx0cyBpbiBuZXdzeXNsb2cu Y29uZi4NCj4gDQo+IFdoeSBhc2sgZm9yIG90aGVycyBvcGluaW9ucyBpZiB5b3UncmUgc2lt cGx5IGdvaW5nIHRvIGNvbW1pdA0KPiB0aGUgY2hhbmdlPyAgSXQgc2VlbXMgdGhlIGNvbW1p dCAoMjMgRGVjIDIwMjMgMDY6NTM6MDYgVVRDKQ0KPiBvY2N1cnJlZCBiZWZvcmUgdGhlIGlu aXRpYWwgcG9zdCBpbiB0aGUgZGlzY3Vzc2lvbiBoZXJlDQo+ICgyMyBEZWMgMjAyMyAwNzox ODoyMyBVVEMpLg0KDQpUaGlzIGNvbW1pdCBvbmx5IGFkZGVkIHRoZSBvcHRpb24gYW5kIGRv ZXMgbm90IGNoYW5nZSB0aGUgZXhpc3RpbmcgY29kZSANCmJlaGF2aW9yLg0KDQpDaGVlcnMs DQoNCg== --------------500r1jg8ZpbJiF9vovU0fONd-- --------------3mjFOuqwMvj3I7QWo5B0tqDC Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZYdgswUDAAAAAAAKCRARA+Lrl1nkxRtO APwJv3VWoja+2J2QYYLKsreaeXSn/NzsIAPZCNVQUWEgKQD/ZDOlQxqcFtTQ7DHq+AsKuGPrkXyv 0WGx45bUEmZJVAI= =9XS5 -----END PGP SIGNATURE----- --------------3mjFOuqwMvj3I7QWo5B0tqDC-- From nobody Sat Dec 23 22:48:04 2023 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 4SyK7q61LTz556dp for ; Sat, 23 Dec 2023 22:48:07 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyK7q0VyTz4bj1 for ; Sat, 23 Dec 2023 22:48:07 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=y07n header.b=pB9YjspK; dkim=pass header.d=delphij.net header.s=w44o header.b=sEv9pkMW; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net; dmarc=pass (policy=reject) header.from=delphij.net DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=y07n; t=1703371686; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=pmi9itQlA+VD3X7oxMpAYbr/u5sHYkRl6/xVblvIziA=; b=pB9YjspKcnlQhR4lApIawF9YL8toFlMYdTdfmWOGayw5VNMctUFdT6GMKN7eyOKImyEQN 5uHqyLGfdfjMJYHAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=w44o; t=1703371685; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=pmi9itQlA+VD3X7oxMpAYbr/u5sHYkRl6/xVblvIziA=; b=sEv9pkMW4suEjz4gYrXtdD1eX43tLgQrem3usM0rnkpg2K0WJ5fpTANih3ieGuq2awv/B MCcsLsffFmWeQzClNqdu0QD1p6C/LgnKjlYXM9nqyTn1DlkdowHkb2XrUpU9ulQIRz3kEto TAtWpW3UgoilJA5TaRWrYNw3+8Q9Nw/cBXoI5DTQQEWOv10TQ3h+VvIv/LHQldjHMbzHpvm HLi3tc56+dJJpyVi6TalCcrSkNbljH3DQCSQRT+pRtePkdfm3Ps69Tw55gppFR+ZCsj5Qvn VYg4aQQSltPHuNcVcwErMrXFwtCl7VeIkHtd40R5z5D1FD5uH/HVj9tDhc3A== Received: from xins-laptop (unknown [IPv6:2601:646:8080:7daa:957e:26ce:35b4:c915]) by anubis.delphij.net (Postfix) with ESMTPSA id D6FB221B06; Sat, 23 Dec 2023 14:48:05 -0800 (PST) Message-ID: Date: Sat, 23 Dec 2023 14:48:04 -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 Reply-To: d@delphij.net Subject: Re: Proposal: Disable compression of newsyslog by default Content-Language: en-US To: Ceri Davies , d@delphij.net Cc: freebsd-current@freebsd.org References: <8CA93D92-EAED-488E-BDBB-4E168AAEF78B@submonkey.net> From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= xjMEZPbDoRYJKwYBBAHaRw8BAQdAsUNmxEWz6QiGdFbBrVVEpjNpgQV9FXjDWsLsY0UwRPvN HFhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD7ClgQTFgoAPhYhBLskk2pXNatsapeNzxED 4uuXWeTFBQJk9sRMAhsDBQkKBDXmBQsJCAcDBRUKCQgLBRYCAwEAAh4FAheAAAoJEBED4uuX WeTF6yIA/2Ls3Rb/qC8mQZ6D2S0UO5vblPghJfboFJLNJFw3i4GYAQCsTmQg3ahgbNEJu/vU xgtro2kTxa6kKnZ35IbqPqPcCc44BGT2w6ESCisGAQQBl1UBBQEBB0Cxji+sQgVPajLNA/Lw yHx0ogSalPQszdkfVgeg3iR3FAMBCAfCeAQYFgoAIBYhBLskk2pXNatsapeNzxED4uuXWeTF BQJk9sOhAhsMAAoJEBED4uuXWeTF3BQBAIx/gPCTFN2DPBrKLkE3oC/+j9EkmNLMUCGidlP/ Zb6HAP4nL1kStTsOldIGhi/3m1LvU7r3Kel3MnlIK8/9BlLPAg== In-Reply-To: <8CA93D92-EAED-488E-BDBB-4E168AAEF78B@submonkey.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------w5B5A5e1mlIgzfLI0GZL2kSE" X-Spamd-Result: default: False [-5.89 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[delphij.net:s=y07n,delphij.net:s=w44o]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.10)[]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[delphij]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[d@delphij.net]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SyK7q0VyTz4bj1 X-Spamd-Bar: ----- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------w5B5A5e1mlIgzfLI0GZL2kSE Content-Type: multipart/mixed; boundary="------------IkHMoCtNRee0dwgeJolCRd16"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Ceri Davies , d@delphij.net Cc: freebsd-current@freebsd.org Message-ID: Subject: Re: Proposal: Disable compression of newsyslog by default References: <8CA93D92-EAED-488E-BDBB-4E168AAEF78B@submonkey.net> In-Reply-To: <8CA93D92-EAED-488E-BDBB-4E168AAEF78B@submonkey.net> --------------IkHMoCtNRee0dwgeJolCRd16 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0xMi0yMyAxMDoxNywgQ2VyaSBEYXZpZXMgd3JvdGU6DQo+IEkgcmVhbGx5IGRv buKAmXQgbGlrZSB0aGUgaWRlYSBvZiBhZGRpbmcgZmxhZ3MgdGhhdCBtYWtlIHRoZSBwcm9n cmFtIGlnbm9yZSBhIGNvbmZpZyBmaWxlLiAgSSBhbHNvIHRoaW5rIHRoaXMgaXMgcHJlbWF0 dXJlIHVudGlsIFpGUyBpbnN0YWxscyBhcmUgZGVmYXVsdCBvbiBhbGwgYXJjaGl0ZWN0dXJl cy4NCj4gDQo+IEhvd2V2ZXIsIGlmIHlvdSBtdXN0IChhbmQgSSBzZWUgeW91IGhhdmUpIGNo YW5nZSB0aGlzLCBwbGVhc2UgZG9u4oCZdCBjYWxsIHRoZSBvcHRpb24g4oCcbGVnYWN54oCd IGFzIHdlIHdpc2ggdG8gZGVwcmVjYXRlIG90aGVyIGJlaGF2aW91ciBpbiB0aGUgZnV0dXJl IG9yIGFkZCBhZGRpdGlvbmFsIGNvbXByZXNzaW9uIGFsZ29yaXRobXMuDQo+IFBlcmhhcHMg aXQgY291bGQgYmUgY2FsbGVkIOKAnHVzZWNvbmZpZ+KAnSBvciBzb21ldGhpbmcgdGhhdCBk ZXNjcmliZXMgd2hhdCBpdCBhY3R1YWxseSBkb2VzLg0KPiANCj4gQWxzbywgY291bGQgeW91 IHBsZWFzZSB1cGRhdGUgdGhlIG1hbmFnZSBjb21taXQgdG8gbm90ZSB0aGUgY2hhbmdlIGlu IDE1LjAgYmVjYXVzZSBub3QgZXZlcnlvbmUgcmVhZHMgY29tbWl0IGxvZ3MgYW5kIHdlIG1h eSBlbmQgdXAgdmlvbGF0aW5nIHRoZSBQb0xBIHR3aWNlIG90aGVyd2lzZS4NCg0KVGhhbmsg eW91IGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMgb24gdGhlIGNvbW1pdC4gSSB3YW50IHRv IGNsYXJpZnkgDQp0aGF0IG15IHJlY2VudCBjaGFuZ2UgZG9lcyBub3QgYWx0ZXIgdGhlIGV4 aXN0aW5nIGJlaGF2aW9yIG9mIHRoZSBjb2RlLiANCkluIGZhY3QsIHRoZSBjdXJyZW50IGxl Z2FjeSB0ZXN0IGNhc2VzIHN0aWxsIHBhc3Mgc3VjY2Vzc2Z1bGx5LiBUaGUgDQptb2RpZmlj YXRpb24gSSBpbnRyb2R1Y2VkIHByaW1hcmlseSBhZGRzIHRoZSBvcHRpb24gdG8gb3ZlcnJp ZGUgdGhlIA0KZGVmYXVsdCBjb21wcmVzc2lvbiBzZXR0aW5nLg0KDQpSZWdhcmRpbmcgeW91 ciBzdWdnZXN0aW9uIHRvIHJlbmFtZSB0aGUg4oCcbGVnYWN54oCdIG9wdGlvbiwgdGhlIHRl cm0gd2FzIA0KY2hvc2VuIHRvIHJlZmxlY3QgaXRzIHB1cnBvc2Ug4oCTIHRvIHByZXNlcnZl IGhpc3RvcmljYWwgYmVoYXZpb3Igd2hpbGUgDQphY2tub3dsZWRnaW5nIHRoYXQgaXQgbWF5 IGJlIHBoYXNlZCBvdXQgaW4gdGhlIGZ1dHVyZS4gQWRkaW5nIG5ldyANCmxldHRlcnMgdG8g dGhlIGNvbmZpZ3VyYXRpb24gZm9ybWF0IGlzbid0IHNjYWxhYmxlIGFuZCBsYWNrcyANCmZs ZXhpYmlsaXR5LiBFc3BlY2lhbGx5LCBjb25zaWRlciBhbiBhcHBsaWNhdGlvbiB0aGF0IGlu c3RhbGwgdGhlaXIgb3duIA0KbmV3c3lzbG9nLmNvbmYuZCBjb25maWd1cmF0aW9uLCBpbiB3 aGljaCBjYXNlIHRoZSBjb25maWd1cmF0aW9uIGlzIA0Kb3ZlcndyaXR0ZW4gZHVyaW5nIHVw Z3JhZGVzLCBvciBoYXMgdG8gaGF2ZSBzb21lIHdheSB0byBzb2x2ZSBtZXJnZSANCmNvbmZs aWN0cywgc2hvdWxkIHRoZXkgZGVjaWRlIHRvIGFkZCBuZXcgbG9nIGZpbGVzLCBldGMuICBU aGVyZSdzIG5vIA0KcHJhY3RpY2FsIHJlYXNvbiBmb3IgdXNlcnMgdG8gYWRoZXJlIHRvIGEg c3BlY2lmaWMgY29tcHJlc3Npb24gbWV0aG9kIA0KdGhhdCB0aGUgYXBwbGljYXRpb24gd3Jp dGVyIHRvbGQgdGhlbSwgYmVjYXVzZSB0aGUgYWRtaW5pc3RyYXRvciBoYXZlIA0KYmV0dGVy IGlkZWEgYWJvdXQgd2hhdCBjb21wcmVzc29yIGlzIG1vcmUgc3VpdGFibGUgZm9yIHRoZWly IHNpdHVhdGlvbi4NCg0KSSdsbCBhZGQgYSBub3RlIHRvIHRoZSByZWxlYXNlIG5vdGVzIGxh dGVyLCBidXQgcmVzdCBhc3N1cmVkIHRoYXQgdGhlcmUgDQppcyBubyBQb0xBIHZpb2xhdGlv biB5ZXQuDQoNCkNoZWVycywNCg0KDQo= --------------IkHMoCtNRee0dwgeJolCRd16-- --------------w5B5A5e1mlIgzfLI0GZL2kSE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZYdjpQUDAAAAAAAKCRARA+Lrl1nkxeOD AP9eyf/omw1AtC5nX3TEg/iZuHhyvoF9ESF3R6MwvKpp2AEA8okqufKQBsxeAWgYoGTG9XATWVKL hnLdxbuoXJZasgI= =aWr+ -----END PGP SIGNATURE----- --------------w5B5A5e1mlIgzfLI0GZL2kSE-- From nobody Sat Dec 23 23:14:20 2023 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 4SyKk70qgGz557yN for ; Sat, 23 Dec 2023 23:14:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyKk65XFmz4fYf for ; Sat, 23 Dec 2023 23:14:22 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=y07n; t=1703373261; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=NAl97QlA6yJADJbt6akJe+D3VTVq83FY6pJHSRDY9c4=; b=ZJrEFPI+nBFwjHnbvJPIwESEGb7aZaEV+cimuN8tuMx94/rI9/8cCvr5T7NsWFYc3luWR yAw7P7y1ImeXldtBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=delphij.net; i=@delphij.net; q=dns/txt; s=w44o; t=1703373261; h=message-id : date : mime-version : reply-to : subject : to : cc : references : from : in-reply-to : content-type : from; bh=NAl97QlA6yJADJbt6akJe+D3VTVq83FY6pJHSRDY9c4=; b=DXFVn82kPNfZPTNdWd+wjdCn/VR45q/Zd939KsNeStMMMgBbP+h2C3am6ih0cF1NNGVs8 rNn7ANF7g0bVcOwfaPC3BgHEBHew2ftkqi0K+k7Cnkte2HpRSFOtkhg0HrCRUgFcrCsaJwX WTQ1w2BiP1nDHXcD2LdWOqyd582RqWZJ1JPtkCJJHpefS0+buDCPfe9JyWVCVYQcH9xt4gB HXb2iqRggRTsn9CW4yQ6wy28xtnMstktykNGKfwIFNtirFelJax+C2rjiSlj0aZ2FHRWtye wInK9higQUpd2C2wiUYXXT4iGmyca95jBac2scGwXawtuhrNWqTWI6RC0eqA== Received: from xins-laptop (unknown [IPv6:2601:646:8080:7daa:957e:26ce:35b4:c915]) by anubis.delphij.net (Postfix) with ESMTPSA id 731A821A9B; Sat, 23 Dec 2023 15:14:21 -0800 (PST) Message-ID: Date: Sat, 23 Dec 2023 15:14: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 Reply-To: d@delphij.net Subject: Re: Proposal: Disable compression of newsyslog by default Content-Language: en-US To: Enji Cooper , d@delphij.net Cc: freebsd-current@freebsd.org References: From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= xjMEZPbDoRYJKwYBBAHaRw8BAQdAsUNmxEWz6QiGdFbBrVVEpjNpgQV9FXjDWsLsY0UwRPvN HFhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD7ClgQTFgoAPhYhBLskk2pXNatsapeNzxED 4uuXWeTFBQJk9sRMAhsDBQkKBDXmBQsJCAcDBRUKCQgLBRYCAwEAAh4FAheAAAoJEBED4uuX WeTF6yIA/2Ls3Rb/qC8mQZ6D2S0UO5vblPghJfboFJLNJFw3i4GYAQCsTmQg3ahgbNEJu/vU xgtro2kTxa6kKnZ35IbqPqPcCc44BGT2w6ESCisGAQQBl1UBBQEBB0Cxji+sQgVPajLNA/Lw yHx0ogSalPQszdkfVgeg3iR3FAMBCAfCeAQYFgoAIBYhBLskk2pXNatsapeNzxED4uuXWeTF BQJk9sOhAhsMAAoJEBED4uuXWeTF3BQBAIx/gPCTFN2DPBrKLkE3oC/+j9EkmNLMUCGidlP/ Zb6HAP4nL1kStTsOldIGhi/3m1LvU7r3Kel3MnlIK8/9BlLPAg== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6lRi4mdpTte28Q2hK2HyAy7b" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyKk65XFmz4fYf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6lRi4mdpTte28Q2hK2HyAy7b Content-Type: multipart/mixed; boundary="------------VOOdigIYZnCO0NCmSudelF0e"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Enji Cooper , d@delphij.net Cc: freebsd-current@freebsd.org Message-ID: Subject: Re: Proposal: Disable compression of newsyslog by default References: In-Reply-To: --------------VOOdigIYZnCO0NCmSudelF0e Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0xMi0yMyAwNzowOSwgRW5qaSBDb29wZXIgd3JvdGU6DQo+IFRoaXMgaW1wYWN0 cyBlbWJlZGRlZCBzeXN0ZW1zIG9yIGphaWxzIHdoaWNoIHVzZSBVRlMgYXMgdGhlIGRlZmF1 bHQNCj4gL3Zhci9sb2cgYmFja2VkIGRldmljZS4gVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGxh cmdlciBjb25zdW1lcnMgb2YNCj4gRnJlZUJTRCBvdXQgdGhlcmUgdGhhdCBzdGlsbCB1c2Ug VUZTIGluc3RlYWQgb2YgWkZTLg0KDQpJIGFwcHJlY2lhdGUgeW91ciBmZWVkYmFjayENCg0K VGhhbmsgeW91IGZvciBwb2ludGluZyBvdXQgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGlzIGNo YW5nZSBmb3IgZW1iZWRkZWQgDQpzeXN0ZW1zIGFuZCBqYWlscyB1c2luZyBVRlMuIEkgdW5k ZXJzdGFuZCB5b3VyIGNvbmNlcm5zLCBlc3BlY2lhbGx5IA0KcmVnYXJkaW5nIGxhcmdlciBG cmVlQlNEIGNvbnN1bWVycyB3aG8gbWlnaHQgc3RpbGwgcmVseSBvbiBVRlMgaW5zdGVhZCAN Cm9mIFpGUy4NCg0KTm90ZSB0aGF0IHRoZSBjb21taXR0ZWQgY2hhbmdlIHdhcyBkZXNpZ25l ZCB0byBzaW1wbGlmeSBjb2RlIA0KbWFpbnRlbmFuY2UsIHBhcnRpY3VsYXJseSBmb3IgZG93 bnN0cmVhbSBzb2Z0d2FyZSB2ZW5kb3JzLiAgQnkgcmVkdWNpbmcgDQp0aGUgbnVtYmVyIG9m IGNvbmZpZ3VyYXRpb24gbGluZXMgaW4gbmV3c3lzbG9nLmNvbmYgdG8gYSBzaW5nbGUgbGlu ZSBpbiANCi9ldGMvY3JvbnRhYiwgaXQgbWFrZXMgaXQgZWFzaWVyIGZvciBkb3duc3RyZWFt IG1haW50YWluZXJzIHRvIGZvbGxvdyANCnRoZSBsYXRlc3QgRnJlZUJTRCBjb2RlYmFzZSwg YmVjYXVzZSB0aGV5IGRvbid0IGhhdmUgdG8gbWFudWFsbHkgc29sdmUgDQptZXJnZSBjb25m bGljdHMgd2hlbiBzb21lb25lIGNoYW5nZXMgbmV3c3lzbG9nLmNvbmYgYW55bW9yZS4gIFRo aXMgDQpzaG91bGQgZWFzZSB0aGUgaW50ZWdyYXRpb24gYW5kIG1haW50ZW5hbmNlIHByb2Nl c3NlcyBmb3IgdGhlc2UgdmVuZG9ycy4NCg0KPiBBZGRpbmcgdGhpcyBpbnN0ZWFkIGludG8g YnNkaW5zdGFsbCBhbmQgdGhlIGRvY3VtZW50YXRpb24gYXMgYSBzdWdnZXN0ZWQNCj4gICBr bm9iIHNlZW1zIGxpa2UgYSBnb29kIHdheSB0byBnby4NCj4gDQo+IEp1c3Qgc29tZXRoaW5n IHRvIGtlZXAgaW4gbWluZCB3aGVuIG1ha2luZyB0aGlzIGNoYW5nZS4NCg0KTm93IGJhY2sg dG8gdGhlIHByb3Bvc2VkIGJlaGF2aW9yIGNoYW5nZSwgcmVnYXJkaW5nIHlvdXIgc3VnZ2Vz dGlvbiB0byANCmNoYW5nZSB0aGUgZGVmYXVsdCBpbiB0aGUgaW5zdGFsbGVyLCBJIGhhdmUg cmVzZXJ2YXRpb25zIGFib3V0IHRoaXMgDQphcHByb2FjaC4gT25lIG9mIG15IHByaW1hcnkg bW90aXZhdGlvbnMgZm9yIHRoaXMgY2hhbmdlIGlzIHRvIG1vdmUgYXdheSANCmZyb20gdXNp bmcgZmxhZ3MgdG8gc3BlY2lmeSB3aGljaCBjb21wcmVzc2lvbiBtZXRob2Qgc2hvdWxkIGJl IHVzZWQuICBJbiANCm15IHZpZXcsIHRoZSBzb2Z0d2FyZSBwYWNrYWdlIGRpc3RyaWJ1dGVk IGNvbmZpZ3VyYXRpb24gc2hvdWxkIG5vdCANCmRpY3RhdGUgdGhlIGNvbXByZXNzaW9uIG1l dGhvZCB0byBiZSB1c2VkIGJ5IHRoZSB1c2VyLiBSYXRoZXIsIGl0cyByb2xlIA0Kc2hvdWxk IGJlIHRvIGluZm9ybSBuZXdzeXNsb2cgYWJvdXQgdGhlIHN1aXRhYmlsaXR5IG9mIGEgZmls ZSBmb3IgDQpjb21wcmVzc2lvbi4gVGhpcyBzaGlmdCBpbiBhcHByb2FjaCBhaW1zIHRvIHBy b3ZpZGUgdXNlcnMgd2l0aCBncmVhdGVyIA0KZmxleGliaWxpdHkgYW5kIGF1dG9ub215IGlu IG1hbmFnaW5nIHRoZWlyIGNvbXByZXNzaW9uIHNldHRpbmdzLg0KDQpDaGVlcnMsDQo= --------------VOOdigIYZnCO0NCmSudelF0e-- --------------6lRi4mdpTte28Q2hK2HyAy7b Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQS7JJNqVzWrbGqXjc8RA+Lrl1nkxQUCZYdpzAUDAAAAAAAKCRARA+Lrl1nkxYxv AQC4QuW+j//C5WD9+GE/cdDpnuMncZbw5inJsmdZFk9+UQEA595u0W2cIWT2FylkfVqIvu+HwAGP VLyIaKQ4sf/28A8= =KtRv -----END PGP SIGNATURE----- --------------6lRi4mdpTte28Q2hK2HyAy7b--