On 9/1/20 10:46 AM, Daniel P. Berrangé wrote:
On Sat, Aug 08, 2020 at 06:01:22PM +0800, Hao Wang wrote:
From: Hao Wang <wanghao232@huawei.com> Subject: [PATCH] NVRAM: check NVRAM file size and recover from template
A corrupted nvram file (e.g. caused by last unsuccessful creation due to insufficient memory) can lead to boot or migration failure.
Or it can be caused by incorrect deployment of new NVRAM file by an administrator or OS Distro...
Just last week we were debugging an issue on Ubuntu where a person had deployed incorrect NVRAM files of a different size.
Check the size of the existed nvram file when qemuPrepareNVRAM, and re-create if the existed one is unhealthy.
....this will delete valid NVRAM files, hiding the mistake by the administrator.
Overall I'm not a fan of performing a destructive action like deleting files which may or may not be correct.
Not to mention that the size is only one of indicators. The NVRAM has an internal structure and if it gets corrupted (e.g. guest crashes while writing the file), we have now way of detecting it (and I know this is not the scenario you are trying to fix). BTW: This all could have been avoided if you'd use firmware autoselection: <os firmware='efi'/>. Is there a problem with it that made you go with the old way of specifying NVRAM? Michal