systemd 261 ajoute sysinstall, IMDSD, storagectl

{{IMAGE:2}}

Le projet systemd a livré systemd 261 vendredi avec trois ajouts phares pour les intégrateurs: systemd-sysinstall, systemd-imdsd et storagectl.

systemd-sysinstall offre aux distributions un installateur texte construit autour des outils de partitionnement et d’identifiants de systemd. L’installateur copie un OS depuis un support de démarrage temporaire, comme une clé USB, et donne aux petites distributions une voie pour proposer un installateur sans avoir à embarquer une pile graphique distincte.

Les utilisateurs cloud obtiennent systemd-imdsd, un démon pour accéder au service de métadonnées d’instance depuis des programmes locaux. La version ajoute aussi des entrées de base de données matérielle qui identifient Amazon EC2, Microsoft Azure, Google Compute Engine, Oracle Cloud, Tencent Cloud, Hetzner et d’autres plateformes cloud via les données SMBIOS.

Le travail sur le stockage arrive via storagectl, un outil en ligne de commande et une interface Varlink pour le stockage utilisateur géré. C’est important pour les hôtes homelab qui mêlent disques locaux, machines virtuelles, conteneurs et politique de stockage par utilisateur.

Notes sur les performances et l’alimentation

L’article de Phoronix n’incluait pas de résultats de benchmark, donc les intégrateurs devraient considérer systemd 261 comme une version de fonctionnalités jusqu’à ce que les distributions publient des paquets et des graphiques de démarrage. Les zones qui méritent d’être mesurées sont claires:

Area	Metric to capture	Reason
Boot path	systemd-analyze blame and critical-chain	New services can change boot ordering
Cloud guests	IMDS query latency	Metadata access can affect provisioning scripts
Storage hosts	Varlink call time and mount setup time	storagectl touches paths admins script
TPM fallback	Service startup time and idle RSS	swtpm adds a userspace daemon on systems without hardware TPM
cgroups	CPU isolation jitter	CPUSetPartition= can affect pinned workloads

Les utilisateurs avancés devraient surveiller la consommation au repos après avoir activé de nouveaux services. systemd-imdsd et systemd-tpm2-swtpm.service ont du sens sur des systèmes ciblés, mais les images de postes de travail et de lab devraient les activer intentionnellement. Un test propre utilise le même noyau, le même firmware, le même gouverneur et le même ensemble de paquets, puis compare la consommation murale en courant alternatif et la résidence des états C du package avant et après la mise à niveau.

Notes de compatibilité

Systemd 261 s’aligne sur les travaux des distributions Linux H2 2026. Les distributions qui dépendent déjà des fonctions récentes de partitionnement, d’identifiants, de Varlink et de TPM de systemd l’adopteront avec moins de code de liaison.

Les administrateurs devraient auditer ces changements avant de les intégrer dans des images de production:

Feature	Compatibility check
systemd-sysinstall	Confirm partition layout support and credential flow
systemd-imdsd	Test cloud detection on each provider image
storagectl	Validate Varlink clients and user storage policy
systemd-tpm2-swtpm.service	Confirm TPM expectations for measured boot and secrets
RestrictFileSystemAccess=	Confirm BPF LSM and DM-Verity support
CPUSetPartition=	Test cgroup v2 behavior under pinned workloads

La version ajoute aussi la prise en charge par PID 1 des capacités Live Update Orchestrator et Kernel Handover du noyau Linux, persiste les stocks de descripteurs de fichiers des unités utilisateur dans les gestionnaires de session utilisateur, ajoute DefaultMemoryZSwapWriteback=, et intègre des notes de métadonnées ELF dlopen dans des binaires individuels.

Recommandation de compilation

Les utilisateurs de labo devraient d’abord tester systemd 261 sur un support de démarrage de rechange ou une VM adossée à un snapshot. Commencez par le temps de démarrage, les scripts cloud-init ou de provisioning, la configuration du stockage et les secrets adossés au TPM. Les serveurs qui dépendent de l’isolation CPU devraient ajouter un test de charge autour de CPUSetPartition= avant de mettre les hôtes en service.

Les téléchargements des sources et le journal des changements complet se trouvent dans le dépôt GitHub de systemd. La version offre aux mainteneurs de distributions une surface de gestion système plus large pour les installateurs, les invités cloud, le stockage et le travail de passage de relais du noyau, donc la mise à niveau mérite le même cycle de mesures que celui que vous accorderiez à un nouveau noyau.