Failed to initialize NvPCR index: No such file or directory

systemd version the issue has been seen with

262

Used distribution

Arch Linux

Linux kernel version used

No response

CPU architectures issue was seen on

None

Component

No response

Expected behaviour you didn't see

0 failed units

Unexpected behaviour you saw

4 failed units

Steps to reproduce the problem

Update systemd to version 262. Reboot

Additional program output to the terminal or log subsystem illustrating the issue

UNIT                             LOAD   ACTIVE SUB    DESCRIPTION                                      
● [email protected]    loaded failed failed TPM NvPCR Measurement of User Record for UID 1000
● [email protected]     loaded failed failed TPM NvPCR Measurement of User Record for UID 945
● systemd-pcrproduct.service       loaded failed failed TPM NvPCR Product ID Measurement
● systemd-tpm2-setup-early.service loaded failed failed Early TPM SRK Setup

Sep 22 20:01:07 loq systemd-tpm2-setup[370]: Failed to initialize NvPCR index: No such file or directory
Sep 22 20:01:07 loq systemd-tpm2-setup[370]: Failed to initialize NvPCR index: No such file or directory
Sep 22 20:01:07 loq systemd-tpm2-setup[370]: Failed to initialize NvPCR index: No such file or directory
Sep 22 20:01:07 loq systemd-tpm2-setup[370]: Failed to initialize NvPCR index: No such file or directory
Sep 22 20:01:07 loq systemd-tpm2-setup[370]: 4 NvPCRs failed to initialize, proceeding anyway.
Sep 22 20:01:07 loq systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
Sep 22 20:01:07 loq systemd[1]: Starting TPM NvPCR Product ID Measurement...
Sep 22 20:01:07 loq systemd-pcrextend[404]: Could not extend NvPCR: No such file or directory
Sep 22 20:01:07 loq systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
Sep 22 20:01:09 loq systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
Sep 22 20:01:09 loq systemd[1]: Starting TPM NvPCR Product ID Measurement...
Sep 22 20:01:09 loq systemd-pcrextend[661]: Could not extend NvPCR: No such file or directory
Sep 22 20:01:09 loq systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
Sep 22 20:01:09 loq systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
Sep 22 20:01:09 loq systemd[1]: Starting TPM NvPCR Product ID Measurement...
Sep 22 20:01:10 loq systemd-pcrextend[673]: Could not extend NvPCR: No such file or directory
Sep 22 20:01:10 loq systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
Sep 22 20:01:10 loq systemd[1]: Starting TPM NvPCR Measurement of User Record for UID 945...
Sep 22 20:01:10 loq systemd-pcrextend[870]: Could not extend NvPCR: No such file or directory
Sep 22 20:01:10 loq systemd[1]: Failed to start TPM NvPCR Measurement of User Record for UID 945.
Sep 22 20:01:20 loq systemd[1]: Starting TPM NvPCR Measurement of User Record for UID 1000...
Sep 22 20:01:20 loq systemd-pcrextend[1176]: Could not extend NvPCR: No such file or directory
Sep 22 20:01:20 loq systemd[1]: Failed to start TPM NvPCR Measurement of User Record for UID 1000.

On my system it seem to be unable to find tpm2-pcr-public-key.pem (when I run it from a booted system.)

Found container virtualization none.
Reading EFI variable /sys/firmware/efi/efivars/LoaderTpm2ActivePcrBanks-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
Loaded shared library 'libtss2-esys.so.0' via dlopen().
Loaded shared library 'libtss2-rc.so.0' via dlopen().
Loaded shared library 'libtss2-mu.so.0' via dlopen().
Shared library 'libcrypto.so.4' is not available: libcrypto.so.4: cannot open shared object file: No such file or directory
Loaded shared library 'libcrypto.so.3' via dlopen().
Loaded shared library 'libtss2-tcti-device.so.0' via dlopen().
Loaded SRK public key from '/run/systemd/tpm2-srk-public-key.pem'.
Loaded SRK public key fingerprint: b748d1a04e697046e1ea44e1e944642f4e8aee145388872c39d995ab65228ea5
Using TPM2 TCTI driver 'device' with device '/dev/tpmrm0'.
Loaded 'libtss2-tcti-device.so.0' via dlopen()
Loaded TCTI module 'tcti-device' (TCTI module for communication with Linux kernel interface.) [Version 2]
TPM successfully started up.
Getting TPM2 capability 0x0000 property 0x0001 count 127.
Getting TPM2 capability 0x0002 property 0x011f count 256.
Getting TPM2 capability 0x0008 property 0x0000 count 508.
Getting TPM2 capability 0x0005 property 0x0000 count 1.
Getting TPM2 capability 0x0006 property 0x012c count 1.
Getting TPM2 capability 0x0001 property 0x81000001 count 1.
SRK already stored in the TPM.
SRK fingerprint is b748d1a04e697046e1ea44e1e944642f4e8aee145388872c39d995ab65228ea5.
SRK saved in '/run/systemd/tpm2-srk-public-key.pem' matches SRK in TPM2.
Using TPM2 TCTI driver 'device' with device '/dev/tpmrm0'.
Loaded 'libtss2-tcti-device.so.0' via dlopen()
Loaded TCTI module 'tcti-device' (TCTI module for communication with Linux kernel interface.) [Version 2]
TPM successfully started up.
Getting TPM2 capability 0x0000 property 0x0001 count 127.
Getting TPM2 capability 0x0002 property 0x011f count 256.
Getting TPM2 capability 0x0008 property 0x0000 count 508.
Getting TPM2 capability 0x0005 property 0x0000 count 1.
Getting TPM2 capability 0x0006 property 0x012c count 1.
Setting up NvPCR 'verity' (priority 300).
tpmrm0: No TPM2_BROKEN_NVPCR property for '/dev/tpmrm0', assuming NvPCRs work.
Failed to find TPM PCR public key file 'tpm2-pcr-public-key.pem': No such file or directory
Failed to load PCR public key for NvPCR: No such file or directory
Failed to initialize NvPCR index: No such file or directory
Setting up NvPCR 'hardware' (priority 500).
tpmrm0: No TPM2_BROKEN_NVPCR property for '/dev/tpmrm0', assuming NvPCRs work.
Failed to find TPM PCR public key file 'tpm2-pcr-public-key.pem': No such file or directory
Failed to load PCR public key for NvPCR: No such file or directory
Failed to initialize NvPCR index: No such file or directory
Setting up NvPCR 'cryptsetup' (priority 700).
tpmrm0: No TPM2_BROKEN_NVPCR property for '/dev/tpmrm0', assuming NvPCRs work.
Failed to find TPM PCR public key file 'tpm2-pcr-public-key.pem': No such file or directory
Failed to load PCR public key for NvPCR: No such file or directory
Failed to initialize NvPCR index: No such file or directory
Setting up NvPCR 'login' (priority 800).
tpmrm0: No TPM2_BROKEN_NVPCR property for '/dev/tpmrm0', assuming NvPCRs work.
Failed to find TPM PCR public key file 'tpm2-pcr-public-key.pem': No such file or directory
Failed to load PCR public key for NvPCR: No such file or directory
Failed to initialize NvPCR index: No such file or directory
4 NvPCRs failed to initialize, proceeding anyway.
Skipping EK setup in early boot phase.

openat(AT_FDCWD, "/etc/systemd/tpm2-pcr-public-key.pem", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/run/systemd/tpm2-pcr-public-key.pem", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/lib/systemd/tpm2-pcr-public-key.pem", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/systemd/tpm2-pcr-public-key.pem", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Edit: I resolved the not found issue by setting PCRPKey=/etc/systemd/tpm2-pcr-initrd-public-key.pem in my /etc/kernel/uki.conf, since I have two pcr keys like in the example section of ukify man page.

How to generate that key without breaking anything?

I'm also on Arch, and can confirm NvPCRs to work if --sign-initrd-pcrs is used together with PCRPKey=. Specifically this part of the release notes is relevant:

The way that NvPCRs are anchored has been improved. They are now
created with a write policy which only permits the initial extend to
be performed from the initrd environment, and no longer rely on a
secret that is sealed to the TPM (the "anchor secret"). For NvPCRs to
work, all NvPCR definitions (/usr/lib/nvpcr/*.nvpcr) must now be
shipped in the UKI. The UKI must also embed a signed PCR policy that
is bound to the initrd boot phase and with the "initrd" policy
reference. This can be created by supplying the --sign-initrd-pcrs
option to ukify. NvPCRs that are not defined or initialized in the
initrd will fail to initialize lazily during runtime if an attempt is
made to extend them with systemd-pcrextend. Existing NvPCRs that were
created with previous systemd versions will be automatically
upgraded, and the existing "anchor secret" stored in /var/lib and the
ESP/XBOOTLDR will be removed.

I am using the following uki.conf:

[UKI]
SecureBootSigningTool=systemd-sbsign
SignKernel=true
SecureBootPrivateKey=/var/lib/sbctl/keys/db/db.key
SecureBootCertificate=/var/lib/sbctl/keys/db/db.pem
Splash=/usr/share/systemd/bootctl/splash-arch.bmp
PCRPKey=/etc/systemd/tpm2-pcr-initrd-public-key.pem
SignInitrdPCRs=yes

[PCRSignature:initrd]
Phases=enter-initrd
PCRPrivateKey=/etc/systemd/tpm2-pcr-initrd-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-initrd-public-key.pem

[PCRSignature:system]
Phases=enter-initrd:leave-initrd
       enter-initrd:leave-initrd:sysinit
       enter-initrd:leave-initrd:sysinit:ready
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key-system.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key-system.pem

The issue I see however that SignInitrdPCRs=yes is missing from the manpage - only the CLI switch --sign-initrd-pcrs is documented, see here.

Edit I opened #43863 for the missing documentation entry.

My uki.conf is empty/default, secureboot enabled with sbctl

My uki.conf is empty/default, secureboot enabled with sbctl

You need to use a signed PCR policy as the release notes explain. Without a PCR policy, NvPCRs will not work anymore. This is on top of sbctl. As you can see in my config, I use sbctl for the signing keys and then two separate keys for PCR policies.

Why not working feature enabled by default?

See the PR that introduced that change, #42796 , for the reasoning. There's been a bunch of security concerns with the previous anchoring approach.

And now it failed completely after update because keys never existed before and not been generated after

Just upgraded Fedora 44 to 45 and now I have the same problem: fifty shades of red at boot. Now it feels like I have to become a TPM2 and PCR expert in order to resolve this. I understand security concerns but this is going to be heavy for users to figure out.

The first thing to figure out is if I now need to manage a new key for PCRs is this key distribution scoped or per-machine scoped? and if the latter how are immutable distributions going to manage that?

I am now curious. If disk encryption was enabled, system would be unbootable because this error?

And now it failed completely after update because keys never existed before and not been generated after

The signing keys need to be generated. See the Arch wiki here and the genkey command on ukify(1) on how to do so.

The first thing to figure out is if I now need to manage a new key for PCRs is this key distribution scoped or per-machine scoped? and if the latter how are immutable distributions going to manage that?

So, PCR 11 is dependent on UKI measurements and the boot phase. An immutable distribution can use an externally generated keypair and does not need to deploy this per machine. You only need access to the private key if the UKI changes.

I am now curious. If disk encryption was enabled, system would be unbootable because this error?

This breaks the NvPCR definitions systemd creates. If you rely on any of these, then yes, it would break the disk decryption. However, the default NvPCR definitions are measured late in boot and aren't typically used for disk decryption.

What exactly cryptenroll command should be to just enroll generated keys to tpm? I'm not using luks.
after generating keys and editing uki.conf there is a new error: Failed to initialize NvPCR index: Device not a stream. This is because keys are not enrolled?

What exactly cryptenroll command should be to just enroll generated keys to tpm? I'm not using luks. after generating keys and editing uki.conf there is a new error: Failed to initialize NvPCR index: Device not a stream. This is because keys are not enrolled?

fwiw, I'm now having exactly the same issue after following the steps in the Wiki and there is a bug open somewhere about it also (can't find it now though). I think the device is not a stream is a red herring and the actual error is that the NvPCR is already defined (confirmed by messing with TPM tools). Systemd seems to want to re-create it anyway. There is a chance my issue is selinux related, but if you are using Arch then maybe not

Is systemd-pcrlock-make-policy.service supposed to be disabled? Because on my system it is

My solution to fix NvPCR initialization with systemd 262 using signed UKI PCR policies

I managed to resolve the NvPCR initialization failures after upgrading to systemd 262-1 on Arch Linux.

I am sharing my configuration, the steps that fixed the issue, and one remaining non-fatal TPM warning.

1. Initial configuration

My system uses:

Arch Linux with systemd 262-1
UEFI Secure Boot enabled
sbctl for signing EFI binaries
Unified Kernel Images (UKIs) generated with mkinitcpio and systemd-ukify
LUKS2 encrypted root filesystem with automatic TPM2 unlocking
TPM2 enrollment bound to PCRs 0+7
Btrfs root filesystem
systemd-boot

My /etc/mkinitcpio.conf hooks:

MODULES=(amdgpu)

HOOKS=(
  systemd plymouth autodetect microcode modconf
  kms keyboard sd-vconsole block sd-encrypt
  filesystems sd-shutdown
)

Initially, my UKIs were signed using sbctl, but they did not contain the .pcrpkey and .pcrsig sections.

This configuration worked before upgrading to systemd 262.

2. Problem after upgrading to systemd 262

After upgrading, several TPM-related services failed, including:

systemd-tpm2-setup-early.service
systemd-pcrproduct.service
systemd-pcrlogin@*.service

The journal reported:

Failed to initialize NvPCR index: No such file or directory
4 NvPCRs failed to initialize, proceeding anyway
Could not extend NvPCR: No such file or directory

The four NvPCR indexes existed but were not initialized:

hardware
cryptsetup
verity
login

Reading them with tpm2_nvread returned:

0x14A TPM_RC_NV_UNINITIALIZED

3. Solution: Generate signed PCR policies and embed them in the UKI

I kept sbctl for Secure Boot signing and configured ukify separately for PCR policy signing.

Step 1 — Generate the PCR signing key pair

sudo ukify genkey \
  --pcr-private-key=/etc/systemd/tpm2-pcr-private-key-initrd.pem \
  --pcr-public-key=/etc/systemd/tpm2-pcr-public-key-initrd.pem

Step 2 — Configure /etc/kernel/uki.conf

[UKI]
PCRPKey=/etc/systemd/tpm2-pcr-public-key-initrd.pem
SignInitrdPCRs=yes

[PCRSignature:initrd]
Phases=enter-initrd
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key-initrd.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key-initrd.pem

This allows ukify to embed the PCR public key and signed PCR policies into the UKI.

Step 3 — Rebuild the UKIs

sudo mkinitcpio -p linux

Both default and fallback UKIs were rebuilt and signed by my existing sbctl post-hook.

Step 4 — Verify the UKI sections

objdump -h /efi/EFI/Linux/arch-linux.efi \
  | grep -E '\.(pcrpkey|pcrsig|linux|initrd)'

The UKI now contains:

.pcrpkey
.pcrsig
.linux
.initrd

Secure Boot signatures were also verified:

sudo sbctl verify

4. Results after reboot

After rebooting, all previously failing services started successfully.

systemctl --failed

Result:

0 loaded units listed.

The four NvPCR indexes are now initialized:

sudo systemd-analyze nvpcrs

NAME         NVINDEX
verity       0x1d10202
hardware     0x1d10200
cryptsetup   0x1d10201
login        0x1d10203

All four indexes now have valid SHA-256 values.

The journal confirms successful initialization:

4 NvPCRs initialized.

Subsequent measurements also work:

Extended NvPCR index 'hardware' with 'product-id:...'
Extended NvPCR index 'login' with 'login:plasmalogin:...'
Extended NvPCR index 'login' with 'login:joan:...'

Secure Boot, measured UKI, measured OS, and automatic TPM2-based LUKS2 unlocking are all working.

5. Remaining non-fatal TPM warning

There is still one minor issue.

During early TPM initialization, systemd-tpm2-setup logs the following error four times:

WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:332:Esys_NV_DefineSpace_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:119:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x0000014c)

The TPM error 0x14C corresponds to TPM_RC_NV_DEFINED, indicating that the NV index is already defined.

Immediately afterward, systemd reports:

4 NvPCRs initialized.

The service finishes successfully.

I verified all four NV indexes with:

for idx in 0x01d10200 0x01d10201 0x01d10202 0x01d10203; do
    sudo tpm2_nvreadpublic "$idx"
done

All indexes exist, have the written attribute, use SHA-256, and share the same authorization policy.

The NvPCR measurements continue to work, so this appears to be a non-fatal issue.

Could this be an expected NV_DefineSpace attempt on already existing indexes, or is there an opportunity to avoid these TPM2-TSS error messages during initialization?

I have not deleted or recreated the NV indexes, since everything is functioning correctly.

6. Package versions

systemd     262-1
tpm2-tss    4.2.0-2
tpm2-tools  5.8-1

Conclusion

In my case, the NvPCR initialization failures after upgrading to systemd 262 were resolved by adding signed PCR policies to my UKIs using ukify.

The resulting boot chain is:

mkinitcpio
    |
    v
systemd-ukify
    |-- .pcrpkey
    |-- .pcrsig
    |
    v
sbctl (Secure Boot signing)
    |
    v
UEFI Secure Boot
    |
    v
systemd-stub + TPM2
    |
    v
NvPCR initialization and measurements

No TPM clearing, NV index deletion, or LUKS2 re-enrollment was required.

The only remaining issue is the non-fatal TPM_RC_NV_DEFINED (0x14C) warning during early initialization.

Hopefully, this helps others using Arch Linux, signed UKIs, Secure Boot, and TPM2 with systemd 262.

To people that want an alternative to using ukify and also use dracut, I have made a PR to dracut at dracut-ng/dracut#2784. It has yet to be reviewed and merged, but it's there if anyone wants to test it. It has worked fine on my own machine, but my TPM only uses sha256 for its PCR banks, but the code should technically pick up on banks with different algorithms. It adds an 'initrd' policy reference by default to the signature, which is what is needed now for NvPCR values to be defined or initialized.
It also works when dracut uses ukify, which it does by default when it is installed.

tpm2: Don't fail NvPCR initialization if there is no initial write po…

tpm2-util: fall back to a PCR policy for NvPCR initialization (#44078)

Closing this, as the systemd side is addressed by #43948 and #44078, both of which will be part of v263 (and #43948 backported to stable):

UKIs without PCR signing (no .pcrpkey/.pcrsig, or no signature with the initrd policy reference for the embedded key): tpm2: Don't fail NvPCR initialization if there is no initial write policy available #43948 stopped this from producing failed units. With tpm2-util: fall back to a PCR policy for NvPCR initialization #44078, NvPCRs are now initialized in this case too: in the initrd, their initial write is bound to the current value of PCR 11 instead of a signed policy. No keys or ukify configuration are needed anymore. Note that the NvPCR names then change with every UKI update, so a signed policy (SignInitrdPCRs=yes) is still the better choice if you rely on the NvPCRs for attestation.
systemd-tpm2-setup-early.service missing from the initrd: NvPCRs can only be initialized in the initrd. systemd no longer tries to initialize them after switch-root, and instead logs an error that points at the missing service. The initrd generators need to include it: mkinitcpio does since 42.2, and dracut has open PRs for it (fix(systemd-pcrextend): add systemd-pcrextend.socket dracut-ng/dracut#2776 , feat(dracut): produce and embed TPM2 PCR signatures into UEFI executable dracut-ng/dracut#2784).
Esys_NV_DefineSpace ... ErrorCode (0x0000014c) on every boot: harmless, and fixed in tpm2-util: fall back to a PCR policy for NvPCR initialization #44078. Existing NvPCR indexes are now looked up before trying to define them.
TPMs without NvPCR support and exhausted NV index space are still skipped gracefully.

If you still see problems with v263, please open a new issue.

If you are annoyed by the "failed" units on boot, don't want to wait for v263, you have never used TMP to unlock your LUCKS (or not using LUKS at all!), know nothing about NvPCRs, simply add systemd.tpm2_measured_os=0 to your kernel parameters. Quick and easy. For more detailed information, but very well digested, read this post.

tpm2: Don't fail NvPCR initialization if there is no initial write po…

Add TPM PCR policy configuration and Noctalia theme integration (#53)

Late comment. But it might help somebody. It seems 262 changed to use Agon2id for --tpm2-with-pin=yes. Opening 3 LUKS2 volumes in parallel at boot was too much for the 16GB RAM on my Yoga laptop and it resulted in an OOM situation. Logging in with TPM2 keys could never succeed. Replacing --tpm2-with-pin=yes with --tpm2-with-pin=direct solved the issue. I rolled new TPM2 keys w/pin on my 3 LUKS2 volumes and it works flawlessly.
Also, probably good idea: remove all custom compression choices from mkinitcpio.conf.

@mokkurkalve

@mokkurkalve The proper fix is to use this option https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptenroll.html#--tpm2-argon2id-memory=BYTES

Navigation Menu

Repository navigation

Failed to initialize NvPCR index: No such file or directory #43848

systemd version the issue has been seen with

Used distribution

Linux kernel version used

CPU architectures issue was seen on

Component

Expected behaviour you didn't see

Unexpected behaviour you saw

Steps to reproduce the problem

Additional program output to the terminal or log subsystem illustrating the issue

111 remaining items

My solution to fix NvPCR initialization with systemd 262 using signed UKI PCR policies

1. Initial configuration

2. Problem after upgrading to systemd 262

3. Solution: Generate signed PCR policies and embed them in the UKI

4. Results after reboot

5. Remaining non-fatal TPM warning

6. Package versions

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Failed to initialize NvPCR index: No such file or directory #43848

Description

systemd version the issue has been seen with

Used distribution

Linux kernel version used

CPU architectures issue was seen on

Component

Expected behaviour you didn't see

Unexpected behaviour you saw

Steps to reproduce the problem

Additional program output to the terminal or log subsystem illustrating the issue

Activity

Duncaen commented on Sep 22, 2026

VoSed commented on Sep 23, 2026

ChrisTX commented on Sep 23, 2026

VoSed commented on Sep 23, 2026

ChrisTX commented on Sep 23, 2026

VoSed commented on Sep 23, 2026

ChrisTX commented on Sep 23, 2026

VoSed commented on Sep 23, 2026

rlees85 commented on Sep 23, 2026

VoSed commented on Sep 24, 2026

ChrisTX commented on Sep 24, 2026

VoSed commented on Sep 24, 2026

rlees85 commented on Sep 24, 2026

VoSed commented on Sep 24, 2026

111 remaining items

joan31 commented on Oct 9, 2026

My solution to fix NvPCR initialization with systemd 262 using signed UKI PCR policies

1. Initial configuration

2. Problem after upgrading to systemd 262

3. Solution: Generate signed PCR policies and embed them in the UKI

4. Results after reboot

5. Remaining non-fatal TPM warning

6. Package versions

Conclusion

marskodev commented on Oct 11, 2026

katexochen commented on Oct 14, 2026

iyanmv commented on Oct 15, 2026

mokkurkalve commented on Nov 12, 2026

benjarobin commented on Nov 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions