v0.22.0

Full version: 0.22.0-2026032408.v591c165

Changes

• gRPC: After a successful servicing operation, the image hash will be returned in the completion message. (#561)
• Updated trident-proto to v1.1.

Bug Fixes

• Fix rollback version check to account for distro versioning schemes (#550)
• Fix pcrlock rule ordering (#568)
• Fixed an issue where slow downloads would get killed every 30 seconds and resumed. Also added a download monitor that reports when speeds fall below 15Mbps (configurable via internal param). (#560)
• Address low impact CVEs (#551, #574)

Known Issues

• ImageCustomizer v1.2.0 produces UKI COSI files that are only compatible with Trident v0.21+. Trident v0.22 works with COSI files created by any recent ImageCustomizer.
• In this release, new integration with systemd-journald was added to directly send logs to the system journal. However, this implementation is not compatible with chrooted environments, which causes Trident logs produced during the chroot steps to be missing from the system journal. All logs are still available in the background log file.

Links

• Docs – README, Docs
• Release date – 2026/03/25
• Commit – 591c165196a075312023dd23e7ed8950969a4839

v0.21.0

Full version: 0.21.2026022501-ve392693

New Features

Sysext, Confext, and Netplan servicing without reboot

Trident supports runtime updates, which allow configuration changes of extensions and netplans to be applied to the servicing OS without requiring a full OS image update.

To utilize, modify the existing Host Configuration's os.systexts, os.confexts, and/or os.netplans sections (if any other sections are modified, Trident will begin an A/B update).

Health checks can be utilized to validate runtime updates. If health checks are configured in the Host Configuration, Trident runs them to verify that the update was successful. Ensure that health checks are configured to run on runtime updates by specifying runtime-update after runsOn. If any health check fails, the runtime update will be rolled back.

For more information, see the Runtime Updates documentation.

Manual Rollback

Trident now provides an API to rollback previously applied updates. Users can:

Command	Description
trident get rollback-chain	Query for available rollbacks
trident rollback --check	Query if the last update was an ab or runtime
trident rollback	Undo whatever the last update was
trident rollback --runtime	Undo runtime updates in the servicing OS one at a time
trident rollback --ab	Undo the last A/B update

For more information, see the Manual Rollback documentation.

Diagnose

Trident now provides an API to collect helpful logs and system information. Use trident diagnose to help diagnose any issues.

For more information, see the Generate a Diagnostics Bundle documentation.

Tracing to Journald

Trident tracing is now added to Journald. The tracing entries are stored with a syslog-id of trident-tracing.

To retrieve, as json for example, use a command like journalctl -t trident-tracing -o json

Trident log explorer helps diagnose issues

Trident has introduced the log explorer to help interpret the log files Trident produces. With the log explorer, it is easy to find errors or warnings. Log entries are helpfully parsed to be more user-friendly and readable.

gRPC API

Trident now supports running as a daemon that responds to gRPC requests over a local Unix socket. In this first version with gRPC support only a limited subset of functionality is supported, but it will be expanded to cover all of Trident's features in the future.
The gRPC services available in this release are described in the gRPC protobuf definitions.

The Trident RPM now includes tridentd.socket and tridentd.service to enable this functionality. By default, the Trident socket exists at /run/trident/trident.sock and is only accessible to the root user.

More info.

Disk Streaming

A new servicing type to bootstrap hosts with Trident. Whereas the regular install process requires a Host Configuration to drive the provisioning, the disk streaming process only requires a COSI (v1.2+) file. Trident will use the COSI metadata to re-create the disk the COSI file was made from in a disk in the target node. Functionally, it is similar to applying a raw image onto a disk to "install" an OS, but with the advantages of size, compression, and efficiency of COSI and Trident.

More info.

Other Updates

COSI download optimizations

The trident downloader has also been improved to be more resilient to network issues that might arise in the middle of COSI downloads.

Bug Fixes

• Trident errors have been reformated to fix some context issues: #510
• Validate extension paths in Host Configuration: #387

Known Issues

• ImageCustomizer v1.2.0 produces UKI COSI files that are only compatible with Trident v0.21.0+. Trident v0.21.0 works with COSI files created by any recent ImageCustomizer.
• In this release, new integration with systemd-journald was added to directly send logs to the system journal. However, this implementation is not compatible with chrooted environments, which causes Trident logs produced during the chroot steps to be missing from the system journal. All logs are still available in the background log file.

Links

• Docs – README, Docs
• Release date – 2026/02/26
• Commit – e392693bde4c940e53abfd343f88542b7025cf15

v0.20.0

Full version: 0.20.2025120104-v2137957

API Changes

N/A

New Features

Sysext and Confext Servicing on Clean Install and A/B Update

Trident now supports servicing sysexts and confexts during clean install and A/B update. Please reference the API documentation and Explanation notes for sysexts and confexts.

Example:

os:
    sysexts:
        url: https://example.com/sysext
        sha384: 123456...
        path: /var/lib/extensions/example-sysext.raw
    confexts:
        url: https://example.com/confext
        sha384: 123456...
        path: /var/lib/confexts/example-confext.raw

Health Checks

Trident now supports health checks, which allow users to validate their target OS. If a health check fails during a clean install, Trident will not consider the host to be Provisioned. If a health check fails during an A/B update, a rollback to the servicing OS will be triggered.

Users may specify validation scripts that Trident will run and/or systemd services that Trident will check after booting into the target OS.

Please reference the API documentation.

Example:

health:
  checks:
  - name: sample-commit-script
    runOn:
    - ab-update
    - clean-install
    content: |
      if ! ping -c 1 8.8.8.8; then
        echo "Network is down"
        exit 1
      fi
      if ! kubectl get nodes; then
        echo "Kubernetes nodes not reachable"
        exit 1
      fi
  - name: sample-systemd-check
    runOn:
    - ab-update
    - clean-install
    systemdServices:
    - kubelet.service
    - docker.service
    timeoutSeconds: 15

UEFI Fallback

Trident now ensures that the UEFI fallback path contains the current boot files to provide resiliency in case of UEFI variable corruption. This new API, uefiFallback can be set to one of 3 options:

• conservative: this is the default and aligns to Trident's UEFI variable configuring, where, for A/B update, the target OS is only configured as UEFI fallback after the boot has been validated.
• optimistic: as the name suggests, this is a more optimistic approach, where the target OS is configured as UEFI fallback immediately.
• disabled: Trident will not do anything to configure a UEFI fallback.

Please reference the Explanation of UEFI Fallback.

Example:

os:
  uefiFallback: "conservative"

Bug Fixes

• Fixed a bug where the creation of a cloud-init networking file would fail when the cloud-init config directory was absent: #273
• Fixed a bug where an interrupted clean install staging could lead to Trident incorrectly interpreting the Host Status on subsequent runs: #278
• Fixed issue #343 for Azure VMs by removing the dependency on /dev/disk/by-path/ for disk device resolution: #358

Other Updates

• Added backwards compatibility for old Host Statuses: #282

Known Issues

N/A

Links

• Docs – README, Docs
• Release date – 2025/12/2
• Commit – 213795789211d617e0b05df4cb4b4f3b08a914f5

v0.19.0

Full version: 0.19.2025100303-v216ed9b

Publication of Trident Repo

Trident repo is now public on GitHub! Going forward, all our resources and issues will be managed through this GitHub repo. Review our updated, versioned, and user-friendly Trident docs here.

API Changes

Changes around TPM 2.0 (Trusted Platform Module) encryption

TPM 2.0 is a hardware security feature that Trident uses to protect keys to the encrypted volumes. In particular, Trident allows customers to seal encryption keys to the expected, "healthy" states of various boot components, such as Secure Boot, boot loader code, and UKIs. There have been two changes related to the TPM 2.0 encryption performed by Trident.

List of PCRs to seal encrypted volumes to is now required

A list of pcrs containing at least one PCR is now required in the storage.encryption section of Host Configuration to use encryption with Trident. This is a list of PCRs in the TPM (Trusted Platform Module) 2.0 device to seal encrypted volumes to in the target OS.

Example:

storage:
  encryption:
      recoveryKeyUrl: file:///recovery.key
      volumes:
        ...
      pcrs:
        - boot-loader-code # 4
        - secure-boot-policy # 7
        - kernel-boot # 11

Different sets of PCRs are valid, depending on the type of the target OS image.

1. When doing a clean install of a grub target OS image, the following options are valid:

• 7, or secure-boot-policy

2. When doing a clean install of a UKI target OS image, the following options are valid:

• 4, or boot-loader-code
• 7, or secure-boot-policy
• 11, or kernel-boot
• 4 and 7
• 4 and 11
• 7 and 11
• 4, 7, and 11

However, due to the limitations of systemd-pcrlock, which is used internally for encryption in UKIs, PCR 7 cannot be used if:

• SecureBoot is disabled,
• Trident is running inside a container.

So, to use PCR 7 for encryption in UKIs, Trident must be running in a non-containerized environment, with SecureBoot enabled.

Trident no longer clears TPM 2.0 by default during clean install

clearTpmOnInstall is a new optional parameter in the storage.encryption section of Host Configuration that determines whether the TPM 2.0 device will be cleared on clean install. By default, it is set to false. If set to true, Trident will clear the TPM 2.0 device on install. TPM cannot be cleared on A/B updates.

Previously, Trident would clear the TPM 2.0 device by default on clean install. Now, this behavior must be explicitly enabled by setting storage.encryption.clearTpmOnInstall to true.

Example:

storage:
  encryption:
      recoveryKeyUrl: file:///recovery.key
      volumes:
        ...
      pcrs:
        ...
      clearTpmOnInstall: true

Clearing the TPM 2.0 device will remove all keys and data from the TPM 2.0 device. This operation is irreversible and might result in data loss. However, this option might be needed to ensure that the TPM 2.0 is in a known state; to avoid entering the DA (Direct Attack) lockout mode on repetitive provisioning attempts, e.g. during testing and development.

New features

N/A

Other Updates

• Updated, versioned, and user-friendly Trident docs are now available! For the public release, we added a lot of useful documentation, and we recommend to first, get familiar with Trident and follow step-by-step instructions on solving key problems with our detailed tutorials. If you want to learn more about a particular topic, our how-to guides will help you tackle a wide range of issues. Our explanation section will be helpful in understanding key concepts in Trident, while our references will provide clear information on Trident's API.

Known Issues

N/A

Upcoming Changes

• [Verity support]: Trident is planning to migrate from supporting grub-based root-verity to primarily supporting usr-verity with systemd-boot and UKIs. For more information, please contact us on Teams.

Links

• Docs – README, Docs
• Release date – 2025/10/6
• Commit – 216ed9b6f16f782edda2d583f72c77e3b59e0ba6