systemd 261 में sysinstall, IMDSD, storagectl जोड़े गए

{{IMAGE:2}}

systemd परियोजना ने शुक्रवार को systemd 261 जारी किया, जिसमें बिल्डरों के लिए तीन मुख्य जोड़ शामिल हैं: systemd-sysinstall, systemd-imdsd, और storagectl।

systemd-sysinstall वितरणों को systemd के partitioning और credential टूल्स के आधार पर बना एक text installer देता है। यह installer USB drive जैसी temporary boot media से एक OS कॉपी करता है, और छोटे वितरणों को अलग graphical stack साथ लिए बिना installer जारी करने का रास्ता देता है।

Cloud उपयोगकर्ताओं को systemd-imdsd मिलता है, जो स्थानीय programs के लिए instance metadata service access हेतु एक daemon है। यह release ऐसे hardware database entries भी जोड़ता है जो SMBIOS data के ज़रिए Amazon EC2, Microsoft Azure, Google Compute Engine, Oracle Cloud, Tencent Cloud, Hetzner, और अन्य cloud platforms की पहचान करते हैं।

Storage से जुड़ा काम storagectl के माध्यम से आता है, जो managed user storage के लिए एक command-line tool और Varlink interface है। यह homelab hosts के लिए महत्वपूर्ण है जो local disks, virtual machines, containers, और per-user storage policy का मिश्रण चलाते हैं।

प्रदर्शन और पावर नोट्स

Phoronix की रिपोर्ट में benchmark result set शामिल नहीं था, इसलिए builders को systemd 261 को एक feature release के रूप में देखना चाहिए, जब तक कि distribution package builds और boot charts प्रकाशित नहीं हो जाते। मापने योग्य क्षेत्र स्पष्ट हैं:

क्षेत्र	कैप्चर करने योग्य मीट्रिक	कारण
Boot path	systemd-analyze blame और critical-chain	नए services boot ordering बदल सकते हैं
Cloud guests	IMDS query latency	metadata access provisioning scripts को प्रभावित कर सकता है
Storage hosts	Varlink call time और mount setup time	storagectl उन paths को छूता है जिन्हें admins script करते हैं
TPM fallback	Service startup time और idle RSS	swtpm hardware TPM न होने वाले systems पर एक userspace daemon जोड़ता है
cgroups	CPU isolation jitter	CPUSetPartition= pinned workloads को प्रभावित कर सकता है

Power users को नए services enable करने के बाद idle draw पर नज़र रखनी चाहिए। systemd-imdsd और systemd-tpm2-swtpm.service लक्षित systems पर समझ में आते हैं, लेकिन workstation और lab images पर इन्हें इरादे के साथ enable करना चाहिए। एक साफ test वही kernel, firmware, governor, और package set उपयोग करता है, फिर upgrade से पहले और बाद में AC wall draw और package C-state residency की तुलना करता है।

संगतता नोट्स

Systemd 261 H2 2026 Linux distribution work के साथ मेल खाता है। जो distros पहले से recent systemd partitioning, credentials, Varlink, और TPM features पर निर्भर हैं, वे इसे कम glue code के साथ अपनाएँगे।

Admins को production images में इसे rollout करने से पहले इन बदलावों का audit करना चाहिए:

Feature	संगतता जाँच
systemd-sysinstall	Partition layout support और credential flow की पुष्टि करें
systemd-imdsd	प्रत्येक provider image पर cloud detection का परीक्षण करें
storagectl	Varlink clients और user storage policy को validate करें
systemd-tpm2-swtpm.service	measured boot और secrets के लिए TPM expectations की पुष्टि करें
RestrictFileSystemAccess=	BPF LSM और DM-Verity support की पुष्टि करें
CPUSetPartition=	pinned workloads के तहत cgroup v2 behavior का परीक्षण करें

यह release Linux kernel की Live Update Orchestrator और Kernel Handover capabilities के लिए PID 1 support भी जोड़ता है, user session managers में user unit FD stores को persist करता है, DefaultMemoryZSwapWriteback=, जोड़ता है, और individual binaries में dlopen ELF metadata notes embed करता है।

Build Recommendation

Lab users को पहले spare boot media या snapshot-backed VM पर systemd 261 का परीक्षण करना चाहिए। Boot timing, cloud-init या provisioning scripts, storage setup, और TPM-backed secrets से शुरुआत करें। जो servers CPU isolation पर निर्भर हैं, उन्हें hosts को service में लेने से पहले CPUSetPartition= के आसपास एक workload test जोड़ना चाहिए।

Source downloads और पूरा changelog systemd GitHub repository में उपलब्ध हैं। यह release distribution maintainers को installers, cloud guests, storage, और kernel handover work के लिए system-management की व्यापक surface देता है, इसलिए upgrade उतनी ही measurement pass की मांग करता है जितनी आप किसी नए kernel को देते।