On Fri, 26 Feb 2021 10:21:47 +0900 bugsgrid+...@gmail.com wrote: > Regarding the backup/restore function > in the commit bb3205709aa9f83e1c8cb91e7f6f9f110d41b34e, > for me it seems bringing in more critical dangers than the safety it provides. > > The logic is too error prone, it relies on on_exit() absolutely never > duped by any fork()'s, > meaning it's requiring absolutely every fork() in the entire code to be > patched. > And there is no safeguard against misfiring of restore_backup_on_exit(). > It itself is "just irrevocably removing them as the first action," > even if there is nothing to be restored. > Oh well. > > I bet it's better to set onhold on grub for now... > >
Reading the logs above I am not sure what is causing the misfire. I see that it fails to install any translations, are grub.mo from grub-common somehow excluded on the system? (i.e. with a dpkg filter) Is that the cause for the bug, or a red herring, I will try to test that. I would want to make it safer if I could. Indeed, duped by any fork() is painful. Intention is for the top level tool to decide if it is aborting or not, and unfortunately it doesn't do any sort of cleanup and just exits() whenever it is. For me to avoid doing it on_exit() would mean to rewrite all the places where grub_install tries to exit to try to do cleanups & restores. Would doing it in grub-install without on_exit inspire more confidence, or guarding to only do anything in the main_pid of grub-install? Should the log of actions be maintained and then rolled back only if they can be? Regards, Dimitri.
