Hi everybody,
To find a workaround for Delta Updates without a initial rootfs update - #6 by B-Stefan I applied the following patch file to the mender client and tried to modify the logic for accepting updates.
The observed behavior after the patch:
- The client accepts the delta-update due to the disabled logic
- The client downloads the artifact
- The client installs the artifact
- Device changed state to rebooting
- Device changed state to rollback, reason from logs: “The deployment was aborted from the server.”
I have the supposition that the server tries to find the current deployment based on the provides and depends on properties to finish the deployment, and this fails in my case because I can only change the logic on the client (hosted mender).
My question: Where lies the responsibility of accepting an artifact? Based on the current architecture in the mender client, I would expect that the client has the responsibility and not the server?
Ignore rootfs.checksum requirement
I would not advise using this patch in any production build
diff --git a/app/mender.go b/app/mender.go
index 8c8cbca..343c139 100644
--- a/app/mender.go
+++ b/app/mender.go
@@ -256,6 +256,12 @@ func verifyArtifactDependencies(
return errors.Errorf(errMsgDependencyNotSatisfiedF,
key, depend, provides[key])
}
+ // Hacky workaround to avoid a full rootfs update before the first delta update
+ // This condition should only apply if: the provides[key] is null,
+ // and we are checking the rootfs-image.checksum
+ if key == "rootfs-image.checksum" {
+ continue
+ }
return errors.Errorf(errMsgDependencyNotSatisfiedF,
key, depend, nil)
}