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