From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 92F473D27; Thu, 20 Nov 2025 14:56:32 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id AD04B3D20; Thu, 20 Nov 2025 14:56:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-a7-smtp.messagingengine.com (fout-a7-smtp.messagingengine.com [103.168.172.150]) by atuin.qyliss.net (Postfix) with ESMTPS id 50A2B3D80 for ; Thu, 20 Nov 2025 14:56:27 +0000 (UTC) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 664CCEC0206; Thu, 20 Nov 2025 09:56:24 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Thu, 20 Nov 2025 09:56:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1763650584; x=1763736984; bh=TUiQ0RKjJe +asqGPPa9Ju1CHNN25TriOFWn44BH6/4s=; b=O9rZN3uZ/uG5+HYPdli4dQTUwU P4OA5QTpnYNeT0oj1Iwuk18tJ86KbCcfNZspVEzSDQi+66xeBND8l02kZsoPXZpH mkZwSU9eh/kCoqU+yCKFaALmB9ndhgyNoRpNL4tMv15gTpPdmNsHIbdaKHcetUgd 4Bw4GE2Cp/YgBvE+qXHL2jt2/5bALPJ61NEZwOBZNkv/xtWDu6ii/i9jLB8zytLv 3eI+gW1WR8tcBtyeykuxLsDhHk3kyr5gTePv0LLlDwYh8yv9uLGocXdoth4LVdNo e5r0LGHlfrbim2KZ6ubo3pVjWdwxQF/Ni+8coRhk2xGhyRSHDL/G6z3x2ZVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1763650584; x=1763736984; bh=TUiQ0RKjJe+asqGPPa9Ju1CHNN25TriOFWn 44BH6/4s=; b=MiZKsVP0iu1Sg+BJ3CXmZ12ELhvYYBhmO1THwYm3tPRWp5cHMU9 /FwxZr/8VgZYmJ++MkXZvr6ftjUeD27rUk0//FtcjTsvyz7ct8aSvdzbXGAiMxMP 0dp9xkMXEvWRk3rw+05T9xmwNXwuwdBIQd1bt4fjCWzpUOtXKxO2vT5y10XTDYqx MtfmU4tjl/QPys0Y+g0nbys2TZV4ClNe4+AiwhSAeSL7iXLPh3/UvB9qIxyMHQUf KXVZktPM0VvgH9x/bmuUu+XF1IAJe8luQOT7K20jKmwqigvPstPfRAG+ztUHfwF5 xk4iYJkqXlgKtuK/brtY7fMxiQGG6UlqJcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdejfeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefujghffffkgggtsehgtderredttdejnecuhfhrohhmpeetlhihshhsrgcu tfhoshhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpeffffejff fgudejueekvedvjeeugfeileffjedtvedtieetvefgieeghfdtgfegjeenucffohhmrghi nhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhephhhisegrlhihshhsrgdrihhspdhnsggprhgtphhtthhopedvpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopeguvghmihhosggvnhhouhhrsehgmhgrih hlrdgtohhmpdhrtghpthhtohepuggvvhgvlhesshhpvggtthhruhhmqdhoshdrohhrgh X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Nov 2025 09:56:23 -0500 (EST) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 9C0AA6A5097E; Thu, 20 Nov 2025 15:56:21 +0100 (CET) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: [PATCH v2 6/8] Support updates via systemd-sysupdate In-Reply-To: <2ade0084-7ce6-4be5-abc1-86e7a91f9dfa@gmail.com> References: <20251112-updates-v2-0-88d96bf81b79@gmail.com> <20251112-updates-v2-6-88d96bf81b79@gmail.com> <87tsyxc26t.fsf@alyssa.is> <154426ab-f42b-4c5e-9f0e-8a91abbe7596@gmail.com> <877bvslskd.fsf@alyssa.is> <2ade0084-7ce6-4be5-abc1-86e7a91f9dfa@gmail.com> Date: Thu, 20 Nov 2025 15:56:20 +0100 Message-ID: <878qg04usr.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: WIEFDBI3DRQYVIMV6QRYGT6DGUIE4KXX X-Message-ID-Hash: WIEFDBI3DRQYVIMV6QRYGT6DGUIE4KXX X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Spectrum OS Development X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Demi Marie Obenour writes: > On 11/14/25 07:14, Alyssa Ross wrote: >> Demi Marie Obenour writes: >>=20 >>> On 11/13/25 11:44, Alyssa Ross wrote: >>>> Demi Marie Obenour writes: >>>> >>>>> + >>>>> + backtick -E update_vm_id_ { >>>>> + backtick -E id_path { readlink /run/vm/by-name/sys.appvm-updates= } >>>>> + basename -- $id_path >>>>> + } >>>>> + >>>>> + multisubstitute { >>>>> + define fsdir /run/vm/by-id/${update_vm_id_}/fs >>>>> + define update_vm_id ${update_vm_id_} >>>> >>>> Why? >>> >>> Avoiding serial substitution. >>=20 >> But this is serial substitution. You're substituting update_vm_id_, and >> then you're doing another substitution of update_vm_id without the >> underscore. Why? Why not the following? >>=20 >> backtick update_vm_id { ... } >> multisubstitute { >> define fsdir ... >> importas -Siu update_vm_id >> } > > "serial substitution" means that one substitutes into a string > that has already been substituted into. See the multisubstitute > documentation for why this is bad. I avoided the route you describe > because I wanted to define fsdir and update_vm_id in the same call > to multisubstitute. Right =E2=80=94 I now understand. I think going forward we might want to consider having to substitute more than once as an indication that the script is too complicated for execline, which I'm sure you'll be happy to here. But we can do this way for now and do a full audit of our execline scripts later when we get a chance. >>>>> + } >>>>> + >>>>> + # $fsdir is read-only to the guest, but read-write to the host. >>>>> + # Directories bind-mounted into it are read-write to the guest. >>>>> + # See etc/s6-linux-init/run-image/service/vhost-user-fs/template/r= un >>>>> + # for details. >>>>> + >>>>> + # Set up /etc with what the VM needs. The VM will overlay this >>>>> + # on its own /etc. >>>>> + if { rm -rf -- ${fsdir}/etc } >>>>> + if { umask 022 mkdir -p -- ${fsdir}/updates ${fsdir}/etc/systemd } >>>>> + if { cp -R -- /etc/updatevm/sysupdate.d /etc/updatevm/url-env ${fs= dir}/etc } >>>>> + if { cp -- /etc/systemd/import-pubring.gpg ${fsdir}/etc/systemd } >>>> >>>> Why copy rather than bind mount? >>> >>> Target does not exist and I didn't want to bind-mount all of /etc/syste= md. >>=20 >> You can touch a file and then bind mount, and still save a copy. > > This is a tiny file. I suspect the extra exec is more expensive than > the copy. My concern is the tmpfs space utilization =E2=80=94 I know it's small but I= 'd like to avoid files being stored on tmpfs at all unless there's a good reason. >>>>> @@ -17,5 +18,11 @@ let >>>>> callConfig =3D config: if builtins.typeOf config =3D=3D "lambda" t= hen config { >>>>> inherit default; >>>>> } else config; >>>>> + finalConfig =3D default // callConfig config; >>>>> in >>>>> - default // callConfig config; >>>>> + finalConfig // { >>>>> + update-signing-key =3D builtins.path { >>>>> + name =3D "signing-key"; >>>>> + path =3D finalConfig.update-signing-key; >>>>> + }; >>>>> + } >>>> >>>> What does this do? >>> >>> This ensures that the Nix store path doesn't depend on the name of >>> the update signing key, only its contents. >>=20 >> Interesting. Does that matter, though? It ends up being called >> /etc/systemd/import-pubring.gpg in the image regardless. > > Otherwise renaming it would cause a pointless rebuild of a bunchof stuff. Okay. Can we do this at the point of use? I'd rather not have a special override for this one config value =E2=80=94 it's another place to = have to remember to read to understand how config works. >>>>> diff --git a/vm/app/updates.nix b/vm/app/updates.nix >>>>> new file mode 100644 >>>>> index 0000000000000000000000000000000000000000..d2c1e5fcb35b37c7ed8a1= 73f19b97894a36a7f0c >>>>> --- /dev/null >>>>> +++ b/vm/app/updates.nix >>>>> @@ -0,0 +1,37 @@ >>>>> +# SPDX-License-Identifier: MIT >>>>> +# SPDX-FileCopyrightText: 2023 Alyssa Ross >>>>> +# SPDX-FileCopyrightText: 2025 Demi Marie Obenour >>>>> + >>>>> +import ../../lib/call-package.nix ( >>>>> +{ callSpectrumPackage, config, curl, lib, src >>>>> +, runCommand, systemd, writeScript >>>>> +}: >>>>> + >>>>> +let >>>>> + update-url =3D config.update-url; >>>>> + mountpoint =3D "/run/virtiofs/virtiofs0"; >>>>> + sysupdate-path =3D "${systemd}/lib/systemd/systemd-sysupdate"; >>>>> + runner =3D writeScript "update-run-script" >>>>> + '' >>>>> + #!/usr/bin/execlineb -P >>>>> + if { mount -toverlay -olowerdir=3D${mountpoint}/etc:/etc -- over= lay /etc } >>>>> + envfile ${mountpoint}/etc/url-env >>>> >>>> Seems like overkill to use an envfile for a single URL? >>> >>> It is indeed overkill, but I'm not aware of a simpler option. >>> There is backtick + cat but that's two programs rather than one. >>=20 >> I think the canonical way would be redirfd + withstdinas, but that's >> also two programs, so if you want to avoid that, perhaps s6-envdir? >> Reading it isn't any simpler but writing it at least doesn't require a >> special tool. > > We need sed to generate the .transfer files anyway. What does sed have to do with envfile/s6-envdir/etc? >>>>> + importas -i update_url UPDATE_URL >>>>> + if { ${sysupdate-path} update } >>>>> + if { ${curl}/bin/curl -L --proto =3Dhttp,https >>>>> + -o ${mountpoint}/updates/SHA256SUMS.gpg ''${update_url}/SHA25= 6SUMS.gpg } >>>>> + # systemd-sysupdate recently went from needing SHA256SUMS.gpg to= SHA256SUMS.sha256.asc. >>>>> + # I (Demi) have no need if this is intentional or a bug. I also= have no idea if this >>>>> + # behavior will stay unchanged in the future. Therefore, create= both files and let >>>>> + # systemd-sysupdate ignore the one it isn't interested in. >>>>> + if { ln -f ${mountpoint}/updates/SHA256SUMS.gpg ${mountpoint}/up= dates/SHA256SUMS.sha256.asc } >>>> >>>> Would be good to figure out why that happened. If we add a comment li= ke >>>> this it's very unlikely to ever get cleaned up. >>> >>> https://github.com/systemd/systemd/issues/39273 >>=20 >> "hwdb: drop trailing whitespace"? > > https://github.com/systemd/systemd/issues/39723 > ("systemd-sysupdate checks for SHA256SUMS.sha256.asc when fetching from f= ile:///"), > which was fixed in > > ("pull: fix SHA256SUMS fallback for file:// URLs"). > systemd v258.1 should have the fix. Does Spectrum use an older nixpkgs? Yes, we're still on 258. I expect an update before this series is applied though, because then we'll also pick up the systemd musl fix. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCaR8sFAAKCRCZddwkt31p Fa+EAP9b0NE7pEuG+JpJeC5xIaZ/FOWdHjMyE1PZmrCV7mVpXQD/Y+NmRm+jPTSe 1+qwWKXVKBNggebneaRKEH3jYbEMNQ0= =o3zW -----END PGP SIGNATURE----- --=-=-=--