52976 2025-02-07 20:59:06 +0300 grub-efi-autoupdate forcibly changes BootOrder every time 2026-03-16 14:55:46 +0300 1 1 4 Development Sisyphus grub-efi unstable x86_64 Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=41959 P5 major --- 1 arseny egori antohami egori george nickel placeholder rider qa-sisyphus oldest_to_newest 258865 0 arseny 2025-02-07 20:59:06 +0300 Бывают администраторы, которым на сотне машин нужна сетевая загрузка по умолчанию, но есть и локально стоящая система. На сегодняшний день у них после каждого grub-efi-autoupdate (например, при изменении ядер) запись в NVRAM от $efi_distributor становится первой в списке, и её приходится (иногда вне операционной системы, т. е. руками и ногами) оттуда вытряхивать. Можно ли это убрать? Вообще, зачем кому-либо, кроме инсталлятора, трогать порядок nvram-записей? (Даже в инсталляторе нужна галка "игнорировать nvram") 258866 1 arseny 2025-02-07 21:00:28 +0300 Я бы мог отказаться от grub на этих машинах вообще, но у нас на сегодняшний день это, как я понимаю, единственный поддерживаемый загрузчик (в том числе автоматикой от make-initrd и kernel-image) 258867 2 arseny 2025-02-07 21:02:13 +0300 https://git.altlinux.org/tasks/373524 258893 3 antohami 2025-02-08 04:56:53 +0300 Так removable разве не то, что надо? 271584 4 arseny 2025-08-28 18:17:50 +0300 (In reply to Антон Мидюков from comment #3) > Так removable разве не то, что надо? Мне в своё время не помогло. 271588 5 arseny 2025-08-28 21:00:54 +0300 Я попробовал mount -o remount,ro /sys/firmware/efi/efivars перед обновлением. grub-install от такого выпадает в осадок: <...> Searching for ALT Linux GRUB efi image to update Skipping /boot/efi/EFI/BOOT/BOOT*.EFI (not ALT Linux GRUB) Found /boot/efi/EFI/BOOT/grub*.efi (ALT Linux GRUB) Found /boot/efi/EFI/altlinux/grub*.efi (ALT Linux GRUB) Updating grub in /boot/efi Installing for x86_64-efi platform. Could not delete variable: Read-only file system grub-install: error: efibootmgr failed to register the boot entry: Block device required. /usr/lib/rpm/grub-efi.filetrigger failed error: posttrans filetriggers scriptlet failed, exit status 1 E: Some errors occurred while running transaction rebuilding database /var/lib/rpm started rebuilding database /var/lib/rpm finished [root@ ~]# echo $? 100 и утаскивает за собой всю транзакцию. Йес! Хорошо, что падает (фактически) после обновления всё-таки, а не во время. 274430 6 george 2025-10-14 13:28:23 +0300 Вот сегодня после обновления ядер *во всех классах* ВМК пропала загрузка по сети — она там был первой, а теперь по умолчанию грузится ядро. И обратно только руками можно поменять. Я понимаю, что скорее всего переписывать Boot-записи надо (мало ли что там меняется), но вот перебивать BootOrder должен разве что инсталлятор. 283835 7 repository-robot 2026-03-13 22:00:48 +0300 grub-2.14-alt1 -> sisyphus: Fri Feb 27 2026 Egor Ignatov <egori@altlinux> 2.14-alt1 - update to grub 2.14 - add grub-efi-install utility for EFI installation with Secure Boot support and proper NVRAM management (closes: #52976) - add probe module to efi image (closes: #54496) - align with upstream usage for GRUB_CMDLINE_LINUX variable (closes: #53710) - replace 'failsafe' with 'single' default for recovery boot entries (closes: #44269) - add GRUB_BTRFS_USE_DEFAULT_SUBVOL option (closes: #56881) - new subpackage grub-common-extra (closes: #38715, #51394, #51395) - add ALT Linux distro name translation (closes: #36004) - add "UEFI Firmware settings" translation (closes: #48768) - read distro name from /etc/os-release (closes: #55546) - add btrfs savedefault support (closes: #50525) - disable savedefault for f2fs (closes: #52193) - refactor grub filetriggers (closes: #57107) - enhance grub-efi-autoupdate UX (closes: #56960) 283975 8 arseny 2026-03-16 14:55:46 +0300 На первый взгляд стало лучше, обновление ядра больше не пишет в BootOrder. Масштабный апгрейд планируется летом, там увидим. Спасибо!