https://blog.margrop.net/en/tag/compatibility/ Recent content in Compatibility on Margrop Blog Hugo -- gohugo.io en-US Mon, 18 May 2026 10:05:00 +0800 https://blog.margrop.net/en/post/chrome-bitwarden-vaultwarden-login-failure-prelogin/ Mon, 18 May 2026 10:05:00 +0800 https://blog.margrop.net/en/post/chrome-bitwarden-vaultwarden-login-failure-prelogin/ <blockquote> <p><strong>TL;DR</strong></p> <p>The failure looked like a Chrome or Bitwarden extension problem: newly installed computers could not log in to a self-hosted Vaultwarden instance, while existing computers continued to work with the same Bitwarden <code>2026.4.1</code> browser extension. The actual root cause was server-side compatibility: the clients were using a newer prelogin endpoint, while the Vaultwarden server was still running <code>vaultwarden/server:1.35.4-alpine</code>, which did not provide <code>/identity/accounts/prelogin/password</code>.</p> <p>Existing machines were likely protected by an already established login state and local cache. They did not prove that the full first-login API path was still compatible. The correct fix was to back up the Vaultwarden data, upgrade the server image to <code>1.36.0</code> or newer, and confirm from logs that the prelogin endpoint no longer returned 404.</p> <p>All domains, paths, usernames, and deployment details in this article are sanitized. Examples use placeholders such as <code>vault.example.com</code> and <code>/opt/vaultwarden</code>; no internal network or private information is included.</p> </blockquote> https://blog.margrop.net/en/post/openclaw-upgrade-to-2026-3-23-compatibility-playbook/ Tue, 24 Mar 2026 21:20:00 +0800 https://blog.margrop.net/en/post/openclaw-upgrade-to-2026-3-23-compatibility-playbook/ <p>This post documents a real OpenClaw upgrade, not a laboratory demo. The goal was not simply to change a version string. The real goal was to move a small multi-node environment from <code>2026.3.8 / 2026.3.13</code> to <code>2026.3.23-2</code> while keeping message channels, external plugins, service startup behavior, and rollback paths under control.</p> <p>In practice, the most difficult part was not the OpenClaw core package. The hardest part was everything around it: plugin SDK compatibility, JIT cache reuse, mixed installation layouts, restricted outbound access on an edge node, and differences in bind mode that changed what health probes actually meant. If you do not identify those variables first, an upgrade can easily look successful while one or more production channels are already broken.</p>