Bug#983435: Regarding the backup/restore function

[Dimitri John Ledkov]

On Fri, 26 Feb 2021 10:21:47 +0900 bugsgrid+deb at 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.