On 2018/1/27 18:37, Ard Biesheuvel wrote: > On 27 January 2018 at 01:47, Huangming (Mark) <huangmin...@huawei.com> wrote: >> >> >> On 2018/1/23 18:23, Leif Lindholm wrote: >>> On Thu, Jan 18, 2018 at 11:01:42PM +0800, Ming Huang wrote: >>>> OsBootLib can create OS option after upgrade firmware. >>> >>> I will respond more strongly that Ard did: >>> >>> I have seen functionality like this implemented in publicly available >>> systems - laptops, desktops. >>> Without exception, they end up in bug reports saying "my system >>> refuses to boot after installation/upgrade". >>> Without exception, they add to existing negative perceptions of UEFI >>> in general in certain market spaces. >>> >>> Presumably this is trying to address a real problem you have faced. >>> Please bring this issue to the table for discussion, so that we can >>> agree on an appropriate way of resolving it. >>> >>> Regardless, this code will not be included in 18.02. >>> >>> / >>> Leif >>> >>> . >>> >> >> The problem is that OS boot option is lost after upgrade firmware. > > Why is that? There is no need to clear the variable store if you > upgrade the executable image. If you fix this issue, you don't need > this patch. >
Ok, retaining the variable store can solve the problem also. But retaining the variable store have some issues, like,if the struct stored in variable is different between new firmware and old firmware, this situation may cause a problem. If OsBootLib is not needed for community, It will use for internal project in hisilicon. Thanks. >> It is inconvenient for using. OsBootLib can help this. >> >> OsBootLib retain the options installed by OS, and create OS boot option >> after upgrade firmware if grub file is existed in EFI partition and in >> mUefiOsBootFiles, >> and delete redundant options in the same GPT. >> > > . > -- Best Regards, Ming _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
