Hi,
i meanwhile think that grub-mkrescue.c simply has no means for removing
grub-install backup files before it runs xorriso.
It only has means to remove all /tmp files afterwards and to remove only
the backup files at premature program end.
-----------------------------------------------------------------------
Long story:
While trying to mimick in my test program the strace lines of your mail
Date: Sun, 25 May 2025 06:17:07 +0200
i stumbled over an explanation for our observations which needs less
ghosts and pixies than my suspicion about a delayed unlink effect.
The only ghost-like aspect is the use of atexit(3).
In the strace the last
unlink("/tmp/grub.Y1wajm/boot/grub/locale/de.mo~") = 0
probably came from this call at the end of grub-mkrescue.c:
grub_util_unlink_recursive (iso9660_dir);
because the straced run had a successful xorriso run.
In case of a failed xorriso run and exit via grub_util_error()
the unlink was probably triggered by restore_backup_atexit() in
util/grub-install-common.c , which has:
if (grub_install_backup_ponr)
clean_grub_dir_real (backup_dirs[i], CLEAN_BACKUP);
CLEAN_BACKUP is the gesture which removes only ~-files.
In util/grub-install-common.c function append_to_backup_dirs() i see
atexit (restore_backup_atexit);
The variable grub_install_backup_ponr is set by a call in
grub-mkrescue.c which happens after all calls of
grub_install_copy_files():
grub_set_install_backup_ponr ();
So the last straced unlink call would have been done after the
intentionally failed xorriso runs when grub_util_error() lets the
program exit. This explains why we saw the .mo files but not the .mo~
files in /tmp/grub.pNWWGC/boot/grub/locale of your mail
Date: Sat, 24 May 2025 19:29:18 +0200
-----------------------------------------------------------------------
The grub-mkrescue bug would be that it does not clean up its ~-files
before it starts xorriso.
Such a cleanup is not needed here, because i only have X86_64_EFI
configured in my Debian 12. (I will have to learn how to add I386_EFI
and I386_PC without getting a Frankendebian.)
Regrettably i see no API call of grub-install-common.c which would
cause
clean_grub_dir_real (..., CLEAN_BACKUP).
So i cannot propose an immediate code experiment in grub-mkrescue.c.
The remedy for the surplus files would possibly be an API call
of grub-install-common.c which performs restore_backup_atexit()
and gets called immediately after
grub_set_install_backup_ponr ();
in the middle of the program, or immediately before
rv = grub_util_exec ((const char *const *)xorriso_argv);
near the end of the program.
A try to avoid the multiple calls to grub_install_copy_files()
looks risky, because of the plat parameter:
for (plat = 0; plat < GRUB_INSTALL_PLATFORM_MAX; plat++)
{
...
grub_install_copy_files (platdir,
boot_grub, plat);
}
Have a nice day :)
Thomas
