systemd 252 與 UKI 支持、改進等一起到來

經過五個月的發展 宣布發布新版systemd 252，其中的版本 新版本的關鍵變化是集成了 支持 現代化的啟動過程， 它不僅可以驗證內核和引導加載程序，還可以使用數字簽名驗證底層系統環境的組件。

所提出的方法涉及使用 UKI 統一內核映像（Unified kernel image) on load，結合了從 UEFI 加載內核的驅動（UEFI boot stub）、Linux 內核鏡像和加載到內存中的 initrd 系統環境，用於上一階段初始化初始化到 FS 根掛載.

相關文章：

他們建議對 Linux 啟動過程進行現代化改造

尤其是好處 systemd-cryptsetup、systemd-cryptenroll 和 systemd-creds 已調整 使用此信息，因此您可以確保加密磁盤分區綁定到數字簽名內核（在這種情況下，僅當 UKI 映像通過基於數字簽名的驗證時才提供對加密分區的訪問）。在放置的參數中在 TPM 中）。

此外，還包括 systemd-pcrphase 實用程序，它允許您控制各種引導階段與支持 TPM 2.0 規範的加密處理器放置在內存中的參數的綁定（例如，您可以使分區解密密鑰 LUKS2 僅可用在 initrd 映像中並阻止在後續下載時訪問它）。

systemd 252的主要新功能

在 systemd 252 中突出的其他變化是e 確保默認語言環境是 C.UTF-8 如果配置中沒有指定其他語言環境。

除了它在 systemd 252 中還有 實現了執行完整服務預設操作的能力 （“systemctl 預設”）在第一次引導期間。 在啟動時啟用預設需要使用“-Dfirst-boot-full-preset”選項進行構建，但計劃在未來版本中默認啟用。

在用戶管理單元中使用 CPU 資源控制器，這使得可以確保將 CPUWeight 設置應用於所有用於將系統劃分為切片（app.slice、background.slice、session.slice）的切片單元，以隔離不同用戶服務之間的資源，競爭 CPU 資源。 CPUWeight 還支持“空閒”值來觸發正確的租用模式。

另一方面，在初始化過程中 (PID 1)，添加了從 SMBIOS 字段導入憑據的功能 （類型 11，“OEM 供應商鏈”）以及通過 qemu_fwcfg 定義它們，這簡化了向虛擬機提供憑據並消除了對第三方工具（如 cloud-init 和點火）的需求。

在關機期間，卸載虛擬文件系統（proc、sys）的邏輯發生了變化，並且有關阻止文件系統卸載的進程的信息被保存到日誌中。

sd bootloader 增加了以混合模式啟動的功能， 從 64 位 UEFI 固件運行 32 位 Linux 內核。 添加了從位於 ESP（EFI 系統分區）上的文件中自動應用 SecureBoot 密鑰的實驗能力。

為 bootctl 實用程序“–all-architectures”添加了新選項 為所有受支持的 EFI 架構安裝二進製文件，«–root=”和“–image=» 使用目錄或磁盤映像，«--安裝源=» 定義要安裝的字體，«--efi-boot-option-description=» 控制引導條目的名稱。

其他變化 從 systemd 252 中脫穎而出：

• systemd-nspawn 允許在“–bind=”和“–overlay=”選項中使用相對文件路徑。 在“–bind=”選項中添加了對“rootidmap”選項的支持，以將容器上的 root 用戶 ID 綁定到主機端掛載目錄的所有者。
• systemd-resolved 默認使用 OpenSSL 包作為加密後端（保留 gnutls 支持作為選項）。 不受支持的 DNSSEC 算法現在被視為不安全而不是返回錯誤 (SERVFAIL)。
• systemd-sysusers、systemd-tmpfiles 和 systemd-sysctl 實現了通過憑證存儲機制傳遞配置的能力。
• 向 systemd-analyze 添加了“比較版本”命令，以將字符串與版本號進行比較（類似於“rpmdev-vercmp”和“dpkg –compare-versions”）。
• 在“systemd-analyze dump”命令中添加了按掩碼過濾驅動器的功能。
• 在選擇多階段睡眠模式（睡眠然後休眠，休眠後休眠）時，現在根據剩餘電池壽命預測選擇在待機模式下花費的時間。
• 當電池電量低於 5% 時，會立即轉換到睡眠模式。

還值得一提的是 2024 年，systemd 計劃停止支持 cgroup v1 資源封頂機制， 在 systemd 版本 248 中已棄用。 建議管理員提前將鏈接到 cgroup v1 的服務轉移到 cgroup v2。

關鍵區別 cgroups v2 和 v1 之間 是使用常見的 cgroups 層次結構 對於所有資源類型，而不是針對 CPU 資源分配、內存管理和 I/O 的單獨層次結構。 在為不同層次結構中的命名進程應用規則時，單獨的層次結構會導致難以組織驅動程序之間的交互以及額外的內核資源成本。

2023年下半年計劃停止支持拆分目錄層次結構，此時/usr與root分開掛載，或/bin與/usr/bin，/lib與/usr/lib目錄分離。