Automated release note commit

Author: cumulusAnia

content/cumulus-linux-516/Whats-New/rn.md

@@ -41,7 +41,6 @@ pdfhidden: True
 | 4930152 | When you configure layer 3 SVI interfaces with an anycast gateway (VRR) IP address only and no unique IP address, the connected route for the subnet is not programmed in the ASIC, causing packets destined for locally connected hosts to drop after decapsulation. | 5.11.3-5.16.1 | |
 | 4930019 | The OTEL <code>nvswitch_buffer_cell_size_bytes</code> metric is missing. | 5.16.1 | |
 | 4926427, 4926426 | When you run the <code>nv config apply</code> command or the <code>sudo systemctl reload frr.service</code> command on a switch configured with VRF route leaking that has many BGP peers, VRFs, and BGP learned prefixes, FRR reload might time out. To work around this issue, run <code>sudo systemctl edit frr.service</code> to change the <code>TimeoutSec=2m</code> to a higher value and apply the changes with <code>sudo systemctl daemon-reload</code>. | 5.15.0-5.16.1 | 5.9.5|
-| 4925516 | If Cumulus Linux generates a core file while automatic cl-support file generation is deactivated, automatic file generation does not work for core files even after you reactivate automatic cl-support file generation but does work for other types of failures, such as service failures and restarts.<br>To clear this problem condition and get automatic cl-support file generation working for cores again, run the following commands:<br><pre>cumulus&#64;switch:~$ sudo systemctl reset-failed cumulus-core.service<br>cumulus&#64;switch:~$ sudo systemctl restart cumulus-core.service<br>cumulus&#64;switch:~$ sudo systemctl reset-failed cumulus-core.path<br>cumulus&#64;switch:~$ sudo systemctl restart cumulus-core.path</pre> | 5.16.1 | |
 | 4925514, 4919006 | Core processing services such as <code>cumulus-core.service</code> and <code>cumulus-core.path</code> might enter a failed state due to <code>systemd</code> start rate limiting caused by rapid start and stop cycles. This issue can prevent core files from being included in subsequent automatically generated cl-support collections even after you reactivate automatic cl-support generation after deactivation due to a chain of faults. Newly generated core files might accumulate, potentially leading to <code>/var</code> partition exhaustion. To recover from this condition, run the <code>sudo systemctl reset-failed cumulus-core.service cumulus-core.path</code> command. | 5.16.1 | |
 | 4925316 | Known registered multicast traffic is duplicated to receivers behind an EVPN-MH dual-homed access switch. | 5.16.0-5.16.1 | |
 | 4924838 | When the a BGP neighbor is up for more than a day (24 hours), the uptime depicts correctly but the reset time which indicates the last connection reset time, does not account for the time elapsed past a day after the BGP neighbor resets. This is a display issue in NVUE; there is no direct traffic or functional impact. | 5.16.0-5.16.1 | |

content/cumulus-linux-516/rn.xml

@@ -169,16 +169,6 @@
 <td>5.9.5</td>
 </tr>
 <tr>
-<td>4925516</td>
-<td>If Cumulus Linux generates a core file while automatic cl-support file generation is deactivated, automatic file generation does not work for core files even after you reactivate automatic cl-support file generation but does work for other types of failures, such as service failures and restarts.To clear this problem condition and get automatic cl-support file generation working for cores again, run the following commands:
-cumulus@switch:~$ sudo systemctl reset-failed cumulus-core.service
-cumulus@switch:~$ sudo systemctl restart cumulus-core.service
-cumulus@switch:~$ sudo systemctl reset-failed cumulus-core.path
-cumulus@switch:~$ sudo systemctl restart cumulus-core.path</td>
-<td>5.16.1</td>
-<td></td>
-</tr>
-<tr>
 <td>4925514, 4919006</td>
 <td>Core processing services such as {{cumulus-core.service}} and {{cumulus-core.path}} might enter a failed state due to {{systemd}} start rate limiting caused by rapid start and stop cycles. This issue can prevent core files from being included in subsequent automatically generated cl-support collections even after you reactivate automatic cl-support generation after deactivation due to a chain of faults. Newly generated core files might accumulate, potentially leading to {{/var}} partition exhaustion. To recover from this condition, run the {{sudo systemctl reset-failed cumulus-core.service cumulus-core.path}} command.</td>
 <td>5.16.1</td>