Issues Fixed in Lightbits 3.20.1
ID | Description |
|---|---|
48538 | If the rebuild on the destination node of a protection group migration fails, for example, in a migration started by proactive rebalance after a node is added, the migration can remain stuck indefinitely. The migration task stays in the Running state, the protection group keeps an extra, unsynchronized replica, and the rebuild is not retried automatically, including after a cluster-manager restart. Affected versions: v3.18.2 through v3.21.1. Workaround: Contact Lightbits Support to restart the rebuild. Do not restart services on the destination node to recover, because this can cancel the migration and discard the rebuild progress. This issue is fixed in v3.22.1. |
46714 | In rare cases, after the etcd service on a server is stopped and restarted, the node on that server may remain inactive and not rejoin the cluster within the expected time. |
46209 | The bundled Grafana Alloy log-streaming agent ships with Grafana's anonymous usage statistics reporting enabled by default. The report is sent out on a fixed four-hour schedule to https://stats.grafana.org/. In air-gapped or firewalled deployments, these attempts fail and produce recurring error entries in the journal. In connected deployments, they may represent an unsanctioned outbound connection to a third party. The exact list of fields collected is documented at https://grafana.com/docs/alloy/latest/data-collection/. |
45912 | If a storage node has some working and some stalled or failed replication connections to other nodes, clients may experience write I/O timeouts. Workaround: Restart the network services on the affected node. This issue is fixed in v3.21.1. |
44875 | lbcli and REST documents describe that you can evict a server with 1x volumes with the force flag, but this is not possible. It also indicates that you can evict a server even if it could lead to risk of service loss using the force flag. However, force will only allow you to evict a server if its nodes are unavailable but still requires other nodes to be active. |
44819 | Lightbits release 3.19.1 introduced stringent validation of any REST requests sent to the Lightbits api-service. While previous faulty requests that had some non-supported fields or corrupted fields would have been accepted, and those fields would be ignored, the 3.19.1 rejects such malformed requests. |
44762 | Log stream to a rsyslog target only supports the secured mode of operation. Unsecured mode is not currently supported. |
44673 | In rare cases, performing a KEK rotation while simultaneously executing a high volume of volume/snapshot control plane operations could result in increased etcd contention. This affects only customers utilizing cluster-level encryption with the KEK rotation API. |
44159 | In a rare case, a rebuild could fail after the following sequence: two or more snapshots are created while a node is inactive, and then all are deleted with at least one deletion occurring after the node's recovery had started. This has been resolved. |
42963 | When SSD journaling is enabled, if the frontend fails due to a non-journal-related issue, the Node Manager (NM) might incorrectly classify the failure as a journal device failure, causing the NM to remain inactive and enter a Permanently Failed state. When SSD journaling is disabled, a frontend failure does not impact the failure scenario. However, users might receive a spurious "journal device failed" event even when journaling is not in use. This is cosmetic only and does not reflect an actual journal issue. |
© 2026 Lightbits Labs™