Grub timeout 30s

Разве ж по ссылке костыльное исправление? Настоящие костыли — отредактировать руками grub.cfg и убрать всё, связаное с recordfail.

Избавься от grub

Как-то объяснял одному любителю обзывать всё костылями.

Всё же хотелось бы чтобы grub не считал каждую загрузку аварийной.

Вот что нашёл http://www.d3noob.org/2024/04/changing-grub-boot-delay-time-from.html?m=1 Не пойму, opensuse в своём установщике давно пихает btrfs по умолчанию. Именно там Я впервые и познакомился с btrfs, и там не было никаких 30 с в grub. Упоминания этого бага модно найти в Гугле лет 5 назад, и там же пишут, что его исправили тогда. Очень странно.

mint
kdeneon

попробуй не пользоваться болгеносами

Читай внимательно, а не по диагонали, у меня и на минте был этот баг, и как выясняется он не зависит от дистрах, а от файловой системы корня. И никто лучше не готовит кеды, чем сами создатели кед. От kubuntu 24.10 всё плюются.

Не знаю про какой баг вы пишете и при чём тут файловая система корня.

Насколько мне известно, GRUB_RECORDFAIL_TIMEOUT и пр. — убунтовское изобретение, основаное на переменной recordfail, которая переменная grub и хранится в /boot/grub/grubenv или там ещё подкаталог добавлен. Одни скрипты туда пишут «1», другие «0». Grub'у вобще безразлично состояние ФС и процесс завершения работы, эти скрипты к Grub не относятся. И переменная recordfail не является какой-то особенной, Grub никак специально её значение не задаёт.

Что mint, что kdeneon — это всё производные Убунту, и все ошибки в убунтовских скриптах там будут. В opensuse, насколько я знаю, не проверяют возможность записи на ФС из grub и не принимают на основании этого решение был сбой или нет. Поэтому им без разницы, умеет grub писать на btrfs или нет.

Я ссылку привёл, там всё подробно написано. Вполне возможно, что эти всё относится к семейству бубунты.

В стартовом сообщении вы привели ссылку на убунту-форум, где написано, что не работает настройка GRUB_TIMEOUT и в ней ссылка на https://bugs.launchpad.net/ubuntu/ source/grub2/ bug/1814403 , где разбирается, что такое поведение стало результатом криво-быстро починить эту проблему:

The change is deliberate and necessary because without it, it is impossible on a UEFI system to reliably access the boot menu. That means that if you ever had a kernel that fails to boot, you will be stuck with a non-bootable system and be unable to recover it from the grub menu (by booting the previous, working kernel).

То есть из-за uefi они решили, что нельзя отключать таймаут, вобще никогда, иначе на некоторых системах загрузка зависнет в boot menu. И это не связано с recordfail, просто по быстрому добавили, что timeout=30, всегда. И потом там идёт ковыряние, что давайте на non-efi сделаем как было, давайте на efi разрешим пользователю выставлять свой тамаут, но не отключать его и т.д.

А по второй ссылке, про btrfs и пр. нет указания на багрепорт. Скриптом /etc/grub.d/00_header проверяет, поддерживает ли grub запись на boot ФС. Если не поддерживает, то там выставляется ″recordfail_broken=1″ и в конфиг груба дописывается ″timeout=30″. И это похоже фича, а не баг, слишком явно прописана логика. То есть, если ФС не поддерижвается grub'ом на запись, то этот алгоритм с переменной recordfail принциписально не рабочий. И это уже точка зрения разрабов — стакан наполовину пуст или полон.

Не уверен, но, вроде как, без разницы в каком месте grub.cfg ставить timeout, то есть можно и в /etc/grub.d/40_custom написать исправление timeout, если выставился ″recordfail_broken=1″. И, так как этот файл не затирается при обновлениях, то такое решение не костыль, а кастомизация.

можно и в /etc/grub.d/40_custom написать…

Не можно, а нужно. Он для того и придуман, чтобы туда писать что тебе нужно, а не что вздумалось системе.