Обноружил при тестировании нового memtest86+ на loongarch64. При одновременном обновлении grub и memtest86+ *иногда* не обновляется /boot/grub/grub.cfg, в результате чего в меню остаётся неработующая строка от старого memtest86+
Исследовал проблему и пришёл к такому выводу: проблема в конструкции if grep [...]; then ... fi | if grep -Eqs [...]; then ... fi `grep -Eqs [...]` выходит, как только обнаруживает match; если первый grep при этом продолжает писать, он получает SIGPIPE, завершается ошибкой, и в первое условие оказыватся ложным. Упростим grub.filetrigger вот до такого: $ cat ./a.sh #!/bin/sh if grep -E '^/boot/(vmlinuz|xen|memtest)|^/usr/lib(64|)/grub'; then echo >&2 "regenerating" fi | if grep -Eqs '^/usr/lib(64|)/grub'; then echo >&2 "grub updated" fi В простейшем случае всё работает: $ echo "/usr/lib64/grub" | ./a.sh grub updated regenerating Однако можно подобрать входные данные, при которых первый grep упадёт, и regenerating выдаваться не будет. У меня на локалхосте это стабильно вот так: $ yes "/usr/lib64/grub" | head -n 100000 | ./a.sh grub updated То есть, будет ли вызван grub-mkconfig зависит от количества обновляемых пакетов и порядка, в котором имена файлов из этих пакетов подаются на вход файлтригерру. Особенно возрастают шансы воспроизвести проблему, если в одной транзакции обновляется много пакетов или большие пакеты, и grub.filetrigger должен сработать на несколько из них.
Пока сделал так: https://git.altlinux.org/people/iv/packages/grub.git?a=commitdiff;h=d458c1e4364fa8ab9b5338737952137a92f2f189 Хотя по-моему логичнее и проще сделать два отдельных файлтриггера.
