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 <wanghao...@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
