On Wed, Mar 24, 2021 at 11:50:56AM +0800, Michael Chang wrote: > On Tue, Mar 23, 2021 at 05:48:01PM +0100, Daniel Kiper wrote: > > On Tue, Mar 23, 2021 at 12:16:21PM +0800, Michael Chang via Grub-devel > > wrote: > > > On Mon, Mar 22, 2021 at 04:20:00PM +0100, Daniel Kiper wrote: > > > > On Thu, Mar 18, 2021 at 07:30:26PM +0800, Michael Chang via Grub-devel > > > > wrote: > > [snip] > > > IIRC I was looking at this patch a few weeks ago but decided to not take > > it because the changes are too intrusive for freeze stage. Though I can > > reconsider it once again if you think it is worth of it... > > Yes please ... It is indeed a bit instrusive, but neverthelast it is > also worth the effort to integrate a method that will help to improve > integrity of the grub installation.
OK, I will take a look at it once again. > At present the procedure of module and image install is not atomic, so > the system may suffer from booting in unspecified state if the process > aborted prematurely in the halfway. A promising solution to revert the > unspecified state to the original one is therefore very much desired and > will benefit us in the log run ... > > > > Afterall, keeping existing running system to survive update (NOT new > > > install) is really an important thing as many can't afford that to > > > happen. If we can make it any better to reduce the cost please consider > > > to do it. It doesn't conflict with the purpose to stop the short mbr gap > > > support, given we all know the broken system can be avoided in the first > > > place ... > > > > This makes sense for me and I am OK with hardening the upgrade path. > > However, I think it is post release work... > > Thanks for taking the patch into consideration. Your plan also looks > good to me. Great! Thanks, Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
