Нестабильный автозапуск ядра ALT Workstation K 10.3

[Dron.ru]

Дано: Пишу драйвер для дистанционного управления технологической установкой. Оператор с рабочего места (ALT Workstation K 10.3) подключается к удалённому компьютеру (ALT Workstation K 10.3), который уже управляет оборудованием посредством моего драйвера. Удалённый компьютер компактно встроен в оборудование, без монитора, мышки и клавиатуры - только кнопка включения и всё.

Проблема: GRUB2 при начальной загрузке должен автоматически запускать последнее установленное ядро после 2 сек ожидания (как это настроено по умолчанию в меню GUI KDE в разделе Запуск и Завершение -> Загрузчик GRUB2). Время от времени загрузчик перестаёт выполнять автозапуск и бесконечно ожидает выбора пользователя. Но как пользователь нажмёт Enter дистанционно до загрузки системы? Ставить комп со встроенным BMC не вариант - это решения серверного класса, дорогие и не рациональные (в каждый холодильник BMC не поставишь). Поэтому вопрос - как добиться от GRUB2 автозапуска в 100% случаев? Что вообще его побуждает менять поведение при загрузке? Какой-то системы пока не выявил - проблема появляется внезапно, на разных компьютерах без каких-либо действий со стороны пользователя (обновление ядра, нестандартное завершение работы и т.п.)

[kessys]

С клавиатурами работает без нареканий, а вообще в KDE есть возможность немедленно запустить.

[asy]

С клавиатурами работает без нареканий, а вообще в KDE есть возможность немедленно запустить.

При чём тут KDE, если речь про загрузчик?

[asy]

Поэтому вопрос - как добиться от GRUB2 автозапуска в 100% случаев? Что вообще его побуждает менять поведение при загрузке? Какой-то системы пока не выявил - проблема появляется внезапно, на разных компьютерах без каких-либо действий со стороны пользователя (обновление ядра, нестандартное завершение работы и т.п.)

Это неправильно конечно, но что-то я раньше про такое поведение Grub не слышал. Правда я им и не пользуюсь пока активно, больше Lilo. Как вариант, если никаких особенностей нет, можно Lilo попробовать поставить. Но не со всеми современными материнками работает, именно потому у меня кое-где Grub всё же есть.

[Dron.ru]

Нашел частичное решение на другом форуме:

Так же столкнулся с подобной проблемой. В случае нештатного отключения компьютера (вырубили свет потом включили) GRUB2 доходил до меню и ждал выбора. Мне бы хотелось чтобы компьютер рестартовал сам с включением света и сервер поднимался. Как оказалось за это отвечает переменная Recordfail , которая по умолчанию выставляется Recordfail=1 после успешной загрузки системы она обнуляется. А при загрузке GRUB2 в файле /boot/grub/grub.cfg идет проверка:

Код: [Выделить]

if [ ${recordfail} = 1 ]; then
  set timeout=-1
else
  set timeout=0таким образом GRUB2 в случае если система была выключена не штатно принудительно выводит меню загрузки и ждет пока администратор в ручную выберет что грузить. Это делается для предотвращения зацикливания загрузки системы, если там что-то серьезно навернулось.
Теперь вторая особенность. Везде пишут что /boot/grub/grub.cfg редактировать нельзя, мол он все-равно потом автоматически генерируется и все вами сделанное потрется. Это не совсем так. Перезапись файла происходит только по команде sudo update-grub Пока эта команда не выполнена конфиг не меняется системой (во всяком случае я не обнаружил обратное)

Таким образом решением проблемы автозапуска системы в случае сбоя будет замена кода в файле /boot/grub/grub.cfg на следующий:

Код: [Выделить]

if [ ${recordfail} = 1 ]; then
#  set timeout=-1
  set timeout=15
else
  set timeout=0Исходное значение было # set timeout=-1 Оно заменено на set timeout=15 И теперь если произойдет некорректное выключение системы, меню будет висеть 15 сек, а не до нажатия enter.
Недостатки данного решения:
1. К сожалению этот костыль влечет опасность зацикливания загрузки системы в случае серьезного сбоя в системе.
2. Каждый раз когда вам надо поменять настройки GRUB2 вы запускаете sudo update-grub, а значит перезаписываете /boot/grub/grub.cfg , после чего опять в ручную надо его править.

К сожалению это работало в ubuntu 12 лет назад, а сегодня в Alt в grub.cfg нет таких строк.
Нашел для Alt https://www.altlinux.org/Grub

Код: [Выделить]

В /etc/sysconfig/grub2 поддерживаются следующие опции:
GRUB_VMLINUZ_FAILSAFE=true/false/default
добавлять ли failsafe-пункты (добавлять, не добавлять, добавлять только для /boot/vmlinuz [по умолчанию]Попробую этот вариант.

[asy]

Нашел частичное решение на другом форуме:

Только вот в ALT в grub.cfg нет упоминания recordfail, а "set timeout=-1" упоминается в качестве обработки нажатого shift. Хотя у меня все инсталляции старые достаточно, может быть в новых иначе. Нет ли в /etc/grub.d/ чего-нибудь подобного? Может какой-то пакет стоит с (не)нужной частью конфига.

[w00zy]

ИМХО удаленная железяка не должна сама генерировать конфиги загрузчика ядра. И иметь возможность их изменять во время загрузки.
При умолчальном поведении

Код: [Выделить]

GRUB_DEFAULT='saved'
GRUB_SAVEDEFAULT=trueГруб запомнит последнее загруженное ядро, вернее запишет (попытается) его в grubenv (со своими тараканами система). Если что то будет не так (а может быть многое), будет ждать ввода пользователя.

Быстрый выход - загрузка первой (0) записи из конфига, это всегда последнее ядро, можно скрыть меню.

Код: [Выделить]

GRUB_DEFAULT=0
GRUB_SAVEDEFAULT=false
# Set normal timeout
GRUB_TIMEOUT=2
# Set hidden timeout (do not show menu)
GRUB_HIDDEN_TIMEOUT=2
# Show timeout counter when hidden
GRUB_HIDDEN_TIMEOUT_QUIET=TRUE

А вообще, если машина удаленная, то отключать автоконфигурацию груба. не нужна она. Все одно сможете загрузить только одно  ядро, значит оставлять минимальный конфиг, типа
/boot/grub/grub.cfg : (ПРИМЕР ИЗ ГОЛОВЫ!!!)

Код: [Выделить]

# по-умолчанию выбран пункт меню 0
set default=0

# при бездействии пользователя он загрузится через 2 секунд
set timeout=2

# пункт меню номер 0
menuentry "ALT" {
        linux   /boot/vmlinuz root=UUID=4e2f7b40-d8ca-4156-b106-aaaaaaaaaaaaaaa ro panic=30 systemd.unit=graphical.target quiet loglevel=3
        initrd  /boot/initrd.img
}


[kessys]

конфиг граба может обновиться при dist-upgrade
И добавиться запись при update-kernel

[w00zy]

конфиг граба может обновиться при dist-upgrade
И добавиться запись при update-kernel

Нет, если отредактировать /etc/sysconfig/grub2 (/etc/default/grub)

Код: [Выделить]

# Automaticaly update config file on kernel install/removal
# default: true
GRUB_AUTOUPDATE_CFG=true

# Automaticaly updated config filename
# default: /boot/grub/grub.cfg
GRUB_AUTOUPDATE_CFGNAME=/boot/grub/grub.cfg
Запретить автоупдате, и надевая презерватив на свечку, заменить имя генерируемого конфига на другое.
При всех этих обновлениях, вызывается update-grub, а он делает что мы прописали в конфиге.

[Dron.ru]

Нет, если отредактировать /etc/sysconfig/grub2 (/etc/default/grub)
Запретить автоупдате, и надевая презерватив на свечку, заменить имя генерируемого конфига на другое.
При всех этих обновлениях, вызывается update-grub, а он делает что мы прописали в конфиге.

А зачем запрещать GRUB_AUTOUPDATE_CFG=false ?
/etc/sysconfig/grub2 (/etc/default/grub) при обновлении не затирается (рядом создается файл /etc/sysconfig/grub2.rpmnew), а в /boot/grub/grub.cfg куча ссылок на  /etc/grub.d/* и /etc/sysconfig/grub2
Так понимаю, что достаточно изменить /etc/sysconfig/grub2, чтобы проблема решилась и настройки не слетели при обновлении ядра?

Прописал в /etc/sysconfig/grub2:
GRUB_AUTOUPDATE_CFG=true
GRUB_SAVEDEFAULT=false
GRUB_DEFAULT=0
GRUB_RECORDFAIL_TIMEOUT=15

Потестирую такие настройки.

[Dron.ru]

Прописал в /etc/sysconfig/grub2:
GRUB_AUTOUPDATE_CFG=true
GRUB_SAVEDEFAULT=false
GRUB_DEFAULT=0
GRUB_RECORDFAIL_TIMEOUT=15

Потестирую такие настройки.

Не помогло
Сегодня утром не сработал автозапуск, хотя последнее завершение работы было корректным.

[asy]

А если секцию "set timeout=-1" убрать? Там, где про shift. И, если ещё где есть, тоже.

[Nicom]

Что вообще его побуждает менять поведение при загрузке?

Вот это может побуждать.

как это настроено по умолчанию в меню GUI KDE в разделе Запуск и Завершение -> Загрузчик GRUB2

У меня не ALT Workstation K 10.3 а стартеркиты, но не думаю, что файлы граба отличаются. Я пока ещё не видел подобной проблемы, хотя и обновления устанавливаются, и конфиг граба правлю через команды.

Сравните файлы /etc/sysconfig/grub2 и /boot/grub/grub.cfg на свежеустановленной системе и после внесения изменений через KDE.
Если нужно изменить задержку перед запуском, то можно просто отредактировать строчку GRUB_TIMEOUT=2 в файле /etc/sysconfig/grub2 и пересобрать конфиг update-grub -o /boot/grub/grub.cfg