diff --git a/content/cumulus-linux-516/Whats-New/rn.md b/content/cumulus-linux-516/Whats-New/rn.md index bed1eb9b48..76d1e10a01 100644 --- a/content/cumulus-linux-516/Whats-New/rn.md +++ b/content/cumulus-linux-516/Whats-New/rn.md @@ -15,10 +15,8 @@ pdfhidden: True | Issue ID | Description | Affects | Fixed | |--- |--- |--- |--- | | 4989440 | The nv show interface qos-roce-status command causes HIGH CPU. | 5.16.0-5.16.1 | | -| 4989435 | During warm and fast reboots, NVUE intentionally skips a comprehensive Git cleanup to adhere to strict service start-up SLAs. When this cleanup is bypassed, existing Git maintenance debt, such as unreachable loose objects or blocked Garbage Collection (GC) states, remain in place and accumulate across successive reboots. The lightweight housekeeping performed during a standard nv config apply is not equivalent to a full cleanup. Consequently, stale objects and blocked GC states can persist until the repository becomes unreadable, eventually causing git commit operations to fail with the error fatal: could not parse HEAD.
To work around this issue, run sudo systemctl restart nvued.service manually after a warm or fast reboot to trigger the full cleanup path skipped during the automated startup sequence. | 5.16.1 | | | 4989434 | If the nginx nvue.conf file is updated (for example, with package update) and the NVUE git database is corrupt, the startup configuration might fail and the nvue.conf file might come from the debian package instead of the NVUE configuration that you create. To work around this issue, you can force the nginx nvue.conf file to update by making a basic change to system API, applying the change, then backing it out; for example:
nv set system api compression gzip
nv config apply -y
nv unset system api compression gzip
nv config apply -y
 | 5.16.1 | |
 | 4989432 | When an interface is constantly flapping and the same BGP neighbor is coming up on a different interface, routes might not be reprogrammed in the kernel after the kernel deletes the routes during interface down events. To recover from this state, restart the FRR service. | 5.16.1 | |
-| 4989430 | If you add a static default route, then delete it, the switch removes the default route in the ASIC. | 5.16.0-5.16.1 | |
 | 4989428 | In rare cases, where a gNMI client terminates without cleaning up its gNMI gRPCs, the gNMI server might continue to buffer notifications for the client, resulting in an increase in gNMI server memory usage, potentially leading to a restart of the gNMI server. | 5.15.1-5.16.1 | |
 | 4989427 | When upgrading the switch to Cumulus Linux 5.16,  the upgrade process completes successfully and both gNMI and SNMP services are up, but gNMI telemetry data is not returned for several key metrics. | 5.16.0-5.16.1 | |
 | 4989426 | The nv show interface qos-roce-status command causes HIGH CPU. | 5.16.0-5.16.1 | |
@@ -249,7 +247,6 @@ pdfhidden: True
 |  Issue ID 	|   Description	|   Affects	|   Fixed |
 |---	        |---	        |---	    |---	                |
 | 4989440 | The nv show interface qos-roce-status command causes HIGH CPU. | 5.16.0-5.16.1 | |
-| 4989430 | If you add a static default route, then delete it, the switch removes the default route in the ASIC. | 5.16.0-5.16.1 | |
 | 4989428 | In rare cases, where a gNMI client terminates without cleaning up its gNMI gRPCs, the gNMI server might continue to buffer notifications for the client, resulting in an increase in gNMI server memory usage, potentially leading to a restart of the gNMI server. | 5.15.1-5.16.1 | |
 | 4989427 | When upgrading the switch to Cumulus Linux 5.16,  the upgrade process completes successfully and both gNMI and SNMP services are up, but gNMI telemetry data is not returned for several key metrics. | 5.16.0-5.16.1 | |
 | 4989426 | The nv show interface qos-roce-status command causes HIGH CPU. | 5.16.0-5.16.1 | |
diff --git a/content/cumulus-linux-516/rn.xml b/content/cumulus-linux-516/rn.xml
index 5c6431cdc9..a52278096b 100644
--- a/content/cumulus-linux-516/rn.xml
+++ b/content/cumulus-linux-516/rn.xml
@@ -13,12 +13,6 @@
 
 
 
-4989435
-During warm and fast reboots, NVUE intentionally skips a comprehensive Git cleanup to adhere to strict service start-up SLAs. When this cleanup is bypassed, existing Git maintenance debt, such as unreachable loose objects or blocked Garbage Collection (GC) states, remain in place and accumulate across successive reboots. The lightweight housekeeping performed during a standard {{nv config apply}} is not equivalent to a full cleanup. Consequently, stale objects and blocked GC states can persist until the repository becomes unreadable, eventually causing git commit operations to fail with the error {{fatal: could not parse HEAD}}.
To work around this issue, run {{sudo systemctl restart nvued.service}} manually after a warm or fast reboot to trigger the full cleanup path skipped during the automated startup sequence.
-5.16.1
-
-
-
 4989434
 If the nginx {{nvue.conf }} file is updated (for example, with package update) and the NVUE git database is corrupt, the startup configuration might fail and the {{nvue.conf}} file might come from the debian package instead of the NVUE configuration that you create. To work around this issue, you can force the nginx {{nvue.conf}} file to update by making a basic change to system API, applying the change, then backing it out; for example:
 nv set system api compression gzip
@@ -35,12 +29,6 @@ nv config apply -y
 
 
 
-4989430
-If you add a static default route, then delete it, the switch removes the default route in the ASIC.
-5.16.0-5.16.1
-
-
-
 4989428
 In rare cases, where a gNMI client terminates without cleaning up its gNMI gRPCs, the gNMI server might continue to buffer notifications for the client, resulting in an increase in gNMI server memory usage, potentially leading to a restart of the gNMI server.
 5.15.1-5.16.1
@@ -1429,12 +1417,6 @@ hal_mlx_port.c:3919 ERR port state set failed for port <#>: Driver's Retur
 
 
 
-4989430
-If you add a static default route, then delete it, the switch removes the default route in the ASIC.
-5.16.0-5.16.1
-
-
-
 4989428
 In rare cases, where a gNMI client terminates without cleaning up its gNMI gRPCs, the gNMI server might continue to buffer notifications for the client, resulting in an increase in gNMI server memory usage, potentially leading to a restart of the gNMI server.
 5.15.1-5.16.1