SC Media and Mezha.net both describe the same warning, crediting BleepingComputer—not separate incidents or independently discovered faults.
What fails—and where to look
An early-boot jitterentropy health test in FIPS mode intermittently fails, stopping startup with a kernel panic. Veeam names EPYC 7262, 7302 and 7F72 processors as examples, not an exhaustive affected-hardware list. Its documented scope is the Linux-based appliance, not Windows-based Veeam installations generally.
The diagnostic message is:
Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9
Depending on the hypervisor, administrators may need the serial console or hypervisor event log to find it. A reboot following a kernel update can expose the problem.
Veeam’s mitigation and recovery steps
Veeam recommends:
- Consider redeploying the appliance on a host with a different processor.
- If that is impractical, disable automatic appliance updates and install updates manually while observing the reboot.
- If the panic occurs, power the VM off, then power it on. Restarting the guest operating system does not recover it.
After a successful boot, Veeam expects no further errors or impact on Backup & Replication operation. That assurance applies after startup; it does not eliminate the next reboot’s risk.
The operational takeaway
Treat this as a maintenance-planning problem, not a reason to abandon updates. If adopting manual updates, assign an owner and a monitored maintenance window. Otherwise, a workaround intended to prevent unattended downtime could quietly become an indefinite patching holiday.
The useful distinction is simple: scheduling updates manually provides an opportunity to intervene; it does not repair the underlying boot failure.