[PATCH] NVRAM: check NVRAM file size and recover from template
Michal Privoznik
mprivozn at redhat.com
Tue Sep 1 09:44:45 UTC 2020
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 at 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
More information about the libvir-list
mailing list