Hi, Adam Purkrt wrote: > so I've tried on updated Debian 12 to come to the same conclusion > as you - the problem does not occur there, but it does on Gentoo and Arch. > Maybe the reason is different libisoburn or xorriso version behaving > differently and adding those ".mo~" files...
I am their developer and would know about such a feature ... normally. You can try by running grub-mkrescue with an -o of which the directory does not exist. This will cause a failure of the xorriso run and keep grub-mkrescue from removing the /tmp/grub.* directory tree. First assess the existing /tmp/grub directories: $ ls -d /tmp/grub.* ls: cannot access '/tmp/grub*': No such file or directory $ Then let grub-mkrescue fail: $ grub-mkrescue -o /does_not_exist/output.iso ./minimal ... libburn : SORRY : Neither stdio-path nor its directory exist xorriso : FAILURE : Cannot acquire drive 'stdio:/does_not_exist/output.iso' grub-mkrescue: error: `xorriso` invocation failed . $ ls -d /tmp/grub* /tmp/grub.7bbbmZ $ ls -a /tmp/grub.7bbbmZ/boot/grub/locale ... i bet you see .mo~ files ... If you see them, maybe their timestamps can give a clue when they got written relative to their .mo counterparts: $ ls -alt --full-time /tmp/grub.7bbbmZ/boot/grub/locale Regrettably i see only three different times here 18:41:30.631384340 18:41:30.627384429 18:41:30.623384520 But at least it should become obvious whether the .mo~ get created directly after their .mo or whether they get created in one sweep after all .mo were written. ----------------------------------------------------------------------- Off topic (but hey, when it's about ISO 9660 then i cannot resist): > Btw I thought ISO9660 does not have hard nor soft links, Indeed ISO 9660 has no notation of links. The roles of inode and dirent are combined in the ISO 9660 directory record. It holds the block address and file size like an inode and the name like a readdir(3) dirent. The space saving effect of hard links can be achieved by having two files share the same content. libisofs sorts its input files by dev_t and ino_t. Groups of files with identical (dev_t,ino_t) get their content stored as a single string of data blocks which is addressed multiple times by the directory records of the files. Symbolic links can be represented by the Rock Ridge extensions, which xorriso enables by default. Actually the "rr" in its name stands for Rock Ridge. GNU/Linux mounts with Rock Ridge interpretation by default. You'd have to disable it by mount -o norock to get the possible Joliet tree with Microsoft-style names and -o norock,nojoliet to surely get dull ISO 9660 names. Hard links can be represented in Rock Ridge 1.12. But the Linux kernel and afaik all others ignore the field "File Serial Number" in Rock Ridge entry PX. Linux for example generates its inode numbers from the byte addresses of the directory records divided by 32: $ ls -i /mnt/iso/boot/grub/locale/[email protected] 1567 /mnt/iso/boot/grub/locale/[email protected] tells that the directory record begins between bytes 1567*32=50144 and 50175 of the ISO image. So even files which share their content get shown by Linux with different inode numbers. Have a nice day :) Thomas
