tools/compat.py checks what this patch assumes about middlewared against iXsystems' actual source, every day. Those assumptions no longer hold on the versions below.
This does not break anyone today.apply.sh re-checks on every boot and declines to apply a module whose assumptions fail, so TrueNAS is left stock rather than half-patched. The cost is the module's feature, not a broken backup.
master
nested
CloudTaskServiceMixin._validate('self', 'verrors', 'name', 'entry') — positional parameters changed; the patch calls it as (self, app, verrors, name, data)
CRUD_BLOCK wraps it to drop the no-further-nesting error
restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
SYNC_BLOCK wraps it to tear down bind mounts in a finally
providers
rclone/remote/b2.py does not exist, so B2RcloneRemote is gone
B2_BLOCK sets .get_restic_config and .restic on this class
get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Full support matrix
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.7
ok
ok
—
24.10.2.5 (unreleased)
ok
ok
—
26.0.0-RC.1 (unreleased)
ok
ok
—
master (27-dev)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
master is not the next release. iX branches each major off to its own release/ line and master rolls straight on to the one after — so master is 27-dev while 26 is still in beta. A BROKEN master means iX has changed
something that will reach users a major release from now, not in the version you
are about to install. Read the numbered rows for that.
A row like 25.10.5 _(unreleased)_ is the next maintenance release: branched by iX,
not tagged yet, and the very next thing a 25.10.4 box gets. It is checked precisely
because it is the one unshipped ref that reaches real users without warning.
Filed and kept up to date by compat.yml. It edits this body when the findings change, and stays quiet when they do not.
`tools/compat.py` checks what this patch assumes about middlewared against iXsystems' actual source, every day. Those assumptions no longer hold on the versions below.
**This does not break anyone today.** `apply.sh` re-checks on every boot and **declines to apply** a module whose assumptions fail, so TrueNAS is left stock rather than half-patched. The cost is the module's feature, not a broken backup.
### `master`
**nested**
- CloudTaskServiceMixin._validate('self', 'verrors', 'name', 'entry') — positional parameters changed; the patch calls it as (self, app, verrors, name, data)
<br><sub>CRUD_BLOCK wraps it to drop the no-further-nesting error</sub>
- restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
<br><sub>SYNC_BLOCK wraps it to tear down bind mounts in a finally</sub>
**providers**
- rclone/remote/b2.py does not exist, so `B2RcloneRemote` is gone
<br><sub>B2_BLOCK sets .get_restic_config and .restic on this class</sub>
- get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
<br><sub>RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous</sub>
<details><summary>Full support matrix</summary>
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.7 | ok | ok | — |
| 24.10.2.5 _(unreleased)_ | ok | ok | — |
| 26.0.0-RC.1 _(unreleased)_ | ok | ok | — |
| master _(27-dev)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
**`master` is not the next release.** iX branches each major off to its own
`release/` line and master rolls straight on to the one after — so master is
`27-dev` while 26 is still in beta. A **BROKEN** master means iX has changed
something that will reach users *a major release from now*, not in the version you
are about to install. Read the numbered rows for that.
A row like `25.10.5 _(unreleased)_` is the next maintenance release: branched by iX,
not tagged yet, and the very next thing a 25.10.4 box gets. It is checked precisely
because it is the one unshipped ref that reaches real users without warning.
</details>
_Filed and kept up to date by [`compat.yml`](.github/workflows/compat.yml). It edits this body when the findings change, and stays quiet when they do not._
<!-- compat-fingerprint: 00d8172927205fc0 -->
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
create-snapshot: create_snapshot is now def, the patch requires async def (plugins/cloud/snapshot.py)
why it matters: SNAPSHOT_BLOCK replaces it with async def that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
crud-mixin-validate: CloudTaskServiceMixin._validate is now def, the patch requires async def (plugins/cloud/crud.py)
why it matters: CRUD_BLOCK replaces it with async def that AWAITS the original, to drop the no-further-nesting error
restic-backup: restic_backup is now def, the patch requires async def (plugins/cloud_backup/sync.py)
why it matters: SYNC_BLOCK replaces it with async def that AWAITS the original, to tear down bind mounts in a finally
master
nested — the patch will not apply:
create-snapshot: create_snapshot is now def, the patch requires async def (plugins/cloud/snapshot.py)
why it matters: SNAPSHOT_BLOCK replaces it with async def that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
crud-mixin-validate: CloudTaskServiceMixin._validate is now def, the patch requires async def (plugins/cloud/crud.py)
why it matters: CRUD_BLOCK replaces it with async def that AWAITS the original, to drop the no-further-nesting error
restic-backup: restic_backup is now def, the patch requires async def (plugins/cloud_backup/sync.py)
why it matters: SYNC_BLOCK replaces it with async def that AWAITS the original, to tear down bind mounts in a finally
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') no longer takes cloud_backup
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `create-snapshot`: create_snapshot is now `def`, the patch requires `async def` (plugins/cloud/snapshot.py)
- why it matters: SNAPSHOT_BLOCK replaces it with `async def` that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
- `crud-mixin-validate`: CloudTaskServiceMixin._validate is now `def`, the patch requires `async def` (plugins/cloud/crud.py)
- why it matters: CRUD_BLOCK replaces it with `async def` that AWAITS the original, to drop the no-further-nesting error
- `restic-backup`: restic_backup is now `def`, the patch requires `async def` (plugins/cloud_backup/sync.py)
- why it matters: SYNC_BLOCK replaces it with `async def` that AWAITS the original, to tear down bind mounts in a finally
### master
**nested** — the patch will not apply:
- `create-snapshot`: create_snapshot is now `def`, the patch requires `async def` (plugins/cloud/snapshot.py)
- why it matters: SNAPSHOT_BLOCK replaces it with `async def` that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
- `crud-mixin-validate`: CloudTaskServiceMixin._validate is now `def`, the patch requires `async def` (plugins/cloud/crud.py)
- why it matters: CRUD_BLOCK replaces it with `async def` that AWAITS the original, to drop the no-further-nesting error
- `restic-backup`: restic_backup is now `def`, the patch requires `async def` (plugins/cloud_backup/sync.py)
- why it matters: SYNC_BLOCK replaces it with `async def` that AWAITS the original, to tear down bind mounts in a finally
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') no longer takes cloud_backup
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
unknown
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
create-snapshot: create_snapshot is now def, the patch requires async def (plugins/cloud/snapshot.py)
why it matters: SNAPSHOT_BLOCK replaces it with async def that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
crud-mixin-validate: CloudTaskServiceMixin._validate is now def, the patch requires async def (plugins/cloud/crud.py)
why it matters: CRUD_BLOCK replaces it with async def that AWAITS the original, to drop the no-further-nesting error
restic-backup: restic_backup is now def, the patch requires async def (plugins/cloud_backup/sync.py)
why it matters: SYNC_BLOCK replaces it with async def that AWAITS the original, to tear down bind mounts in a finally
master
nested — the patch will not apply:
create-snapshot: create_snapshot is now def, the patch requires async def (plugins/cloud/snapshot.py)
why it matters: SNAPSHOT_BLOCK replaces it with async def that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
crud-mixin-validate: CloudTaskServiceMixin._validate is now def, the patch requires async def (plugins/cloud/crud.py)
why it matters: CRUD_BLOCK replaces it with async def that AWAITS the original, to drop the no-further-nesting error
restic-backup: restic_backup is now def, the patch requires async def (plugins/cloud_backup/sync.py)
why it matters: SYNC_BLOCK replaces it with async def that AWAITS the original, to tear down bind mounts in a finally
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | unknown | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `create-snapshot`: create_snapshot is now `def`, the patch requires `async def` (plugins/cloud/snapshot.py)
- why it matters: SNAPSHOT_BLOCK replaces it with `async def` that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
- `crud-mixin-validate`: CloudTaskServiceMixin._validate is now `def`, the patch requires `async def` (plugins/cloud/crud.py)
- why it matters: CRUD_BLOCK replaces it with `async def` that AWAITS the original, to drop the no-further-nesting error
- `restic-backup`: restic_backup is now `def`, the patch requires `async def` (plugins/cloud_backup/sync.py)
- why it matters: SYNC_BLOCK replaces it with `async def` that AWAITS the original, to tear down bind mounts in a finally
### master
**nested** — the patch will not apply:
- `create-snapshot`: create_snapshot is now `def`, the patch requires `async def` (plugins/cloud/snapshot.py)
- why it matters: SNAPSHOT_BLOCK replaces it with `async def` that AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuple
- `crud-mixin-validate`: CloudTaskServiceMixin._validate is now `def`, the patch requires `async def` (plugins/cloud/crud.py)
- why it matters: CRUD_BLOCK replaces it with `async def` that AWAITS the original, to drop the no-further-nesting error
- `restic-backup`: restic_backup is now `def`, the patch requires `async def` (plugins/cloud_backup/sync.py)
- why it matters: SYNC_BLOCK replaces it with `async def` that AWAITS the original, to tear down bind mounts in a finally
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
flan
changed title from Incompatible with upcoming TrueNAS: release/26.0.0-BETA.3,master to TrueNAS compatibility: the patch's assumptions no longer hold2026-07-13 15:07:36 -04:00
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
tools/compat.py found that the patch's assumptions about middlewared no longer hold.
TrueNAS
B2/S3 providers
Nested snapshots
Hardware-verified
24.10.2.4
ok
ok
—
25.04.2.6
ok
ok
—
25.10.4
ok
ok
nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m
26.0.0-BETA.3 (unreleased)
ok
BROKEN
—
master (unreleased)
BROKEN
BROKEN
—
verdict
meaning
ok
Every assumption the patch makes about middleware still holds.
BROKEN
middleware changed underneath the patch. apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature.
native
TrueNAS does this itself now. The module retires; it is not a failure.
"ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
master
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, so zfs.dataset.query is gone
why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
call-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.delete is gone
why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
call-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, so zfs.snapshot.query is gone
why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
providers — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Filed automatically by .github/workflows/compat.yml.
`tools/compat.py` found that the patch's assumptions about middlewared no longer hold.
| TrueNAS | B2/S3 providers | Nested snapshots | Hardware-verified |
| --- | --- | --- | --- |
| 24.10.2.4 | ok | ok | — |
| 25.04.2.6 | ok | ok | — |
| 25.10.4 | ok | ok | nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m |
| 26.0.0-BETA.3 _(unreleased)_ | ok | **BROKEN** | — |
| master _(unreleased)_ | **BROKEN** | **BROKEN** | — |
| verdict | meaning |
| --- | --- |
| **ok** | Every assumption the patch makes about middleware still holds. |
| **BROKEN** | middleware changed underneath the patch. `apply.sh` **refuses to apply that module** on this version and leaves TrueNAS stock, so backups keep working — without the module's feature. |
| **native** | TrueNAS does this itself now. The module retires; it is not a failure. |
"ok" means *the patch's assumptions hold*, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
**Hardware-verified** column, which is filled in by hand and only by doing it.
### release/26.0.0-BETA.3
**nested** — the patch will not apply:
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
### master
**nested** — the patch will not apply:
- `restic-backup`: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)
- why it matters: SYNC_BLOCK wraps it to tear down bind mounts in a finally
- `call-zfs-dataset-query`: plugins/zfs_/dataset.py no longer exists, so `zfs.dataset.query` is gone
- why it matters: SNAPSHOT_BLOCK enumerates FILESYSTEM datasets to build the staging plan
- `call-zfs-snapshot-delete`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.delete` is gone
- why it matters: delete_snapshot_tree() sweeps the recursive snapshot. Without it every run orphans one snapshot per descendant dataset (250 on a real pool)
- `call-zfs-snapshot-query`: plugins/zfs_/snapshot.py no longer exists, so `zfs.snapshot.query` is gone
- why it matters: delete_snapshot_tree()'s fallback sweep enumerates the tree by name
**providers** — the patch will not apply:
- `restic-config-fn`: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)
- why it matters: RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
_Filed automatically by `.github/workflows/compat.yml`._
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
tools/compat.pychecks what this patch assumes about middlewared against iXsystems' actual source, every day. Those assumptions no longer hold on the versions below.This does not break anyone today.
apply.shre-checks on every boot and declines to apply a module whose assumptions fail, so TrueNAS is left stock rather than half-patched. The cost is the module's feature, not a broken backup.masternested
CRUD_BLOCK wraps it to drop the no-further-nesting error
SYNC_BLOCK wraps it to tear down bind mounts in a finally
providers
B2RcloneRemoteis goneB2_BLOCK sets .get_restic_config and .restic on this class
RESTIC_BLOCK wraps it to rewrite the repo URL; it calls the original WITHOUT await, so it must stay synchronous
Full support matrix
apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
masteris not the next release. iX branches each major off to its ownrelease/line and master rolls straight on to the one after — so master is27-devwhile 26 is still in beta. A BROKEN master means iX has changedsomething that will reach users a major release from now, not in the version you
are about to install. Read the numbered rows for that.
A row like
25.10.5 _(unreleased)_is the next maintenance release: branched by iX,not tagged yet, and the very next thing a 25.10.4 box gets. It is checked precisely
because it is the one unshipped ref that reaches real users without warning.
Filed and kept up to date by
compat.yml. It edits this body when the findings change, and stays quiet when they do not.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
create-snapshot: create_snapshot is nowdef, the patch requiresasync def(plugins/cloud/snapshot.py)async defthat AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuplecrud-mixin-validate: CloudTaskServiceMixin._validate is nowdef, the patch requiresasync def(plugins/cloud/crud.py)async defthat AWAITS the original, to drop the no-further-nesting errorrestic-backup: restic_backup is nowdef, the patch requiresasync def(plugins/cloud_backup/sync.py)async defthat AWAITS the original, to tear down bind mounts in a finallymaster
nested — the patch will not apply:
create-snapshot: create_snapshot is nowdef, the patch requiresasync def(plugins/cloud/snapshot.py)async defthat AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuplecrud-mixin-validate: CloudTaskServiceMixin._validate is nowdef, the patch requiresasync def(plugins/cloud/crud.py)async defthat AWAITS the original, to drop the no-further-nesting errorrestic-backup: restic_backup is nowdef, the patch requiresasync def(plugins/cloud_backup/sync.py)async defthat AWAITS the original, to tear down bind mounts in a finallyproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') no longer takes cloud_backupFiled automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
create-snapshot: create_snapshot is nowdef, the patch requiresasync def(plugins/cloud/snapshot.py)async defthat AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuplecrud-mixin-validate: CloudTaskServiceMixin._validate is nowdef, the patch requiresasync def(plugins/cloud/crud.py)async defthat AWAITS the original, to drop the no-further-nesting errorrestic-backup: restic_backup is nowdef, the patch requiresasync def(plugins/cloud_backup/sync.py)async defthat AWAITS the original, to tear down bind mounts in a finallymaster
nested — the patch will not apply:
create-snapshot: create_snapshot is nowdef, the patch requiresasync def(plugins/cloud/snapshot.py)async defthat AWAITS the original and returns (snapshot, staging_root). TrueNAS 26 made it synchronous: the wrapper would return a coroutine that sync.py unpacks as a tuplecrud-mixin-validate: CloudTaskServiceMixin._validate is nowdef, the patch requiresasync def(plugins/cloud/crud.py)async defthat AWAITS the original, to drop the no-further-nesting errorrestic-backup: restic_backup is nowdef, the patch requiresasync def(plugins/cloud_backup/sync.py)async defthat AWAITS the original, to tear down bind mounts in a finallyproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.Incompatible with upcoming TrueNAS: release/26.0.0-BETA.3,masterto TrueNAS compatibility: the patch's assumptions no longer holdtools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.tools/compat.pyfound that the patch's assumptions about middlewared no longer hold.apply.shrefuses to apply that module on this version and leaves TrueNAS stock, so backups keep working — without the module's feature."ok" means the patch's assumptions hold, checked automatically against iX's
source. It does not mean a human ran a backup on it — that is the
Hardware-verified column, which is filled in by hand and only by doing it.
release/26.0.0-BETA.3
nested — the patch will not apply:
call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis gonemaster
nested — the patch will not apply:
restic-backup: restic_backup('context', 'job', 'entry', 'credentials', 'dry_run', 'rate_limit') — positional parameters changed; the patch calls it as (middleware, job, cloud_backup)call-zfs-dataset-query: plugins/zfs_/dataset.py no longer exists, sozfs.dataset.queryis gonecall-zfs-snapshot-delete: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.deleteis gonecall-zfs-snapshot-query: plugins/zfs_/snapshot.py no longer exists, sozfs.snapshot.queryis goneproviders — the patch will not apply:
restic-config-fn: get_restic_config('entry', 'credentials') — positional parameters changed; the patch calls it as (cloud_backup)Filed automatically by
.github/workflows/compat.yml.This report is now kept up to date automatically: the body above always reflects the current findings, and a comment is only added when they change.
The findings changed — the report above has been updated.
Currently broken on:
master.