[make-initrd] bootchain+altboot: у меня есть план

Tue Aug 31 10:40:46 MSK 2021

On Mon, Aug 30, 2021 at 10:54:35PM +0300, Leonid Krivoshein wrote:
> > > 24.08.2021 4:16, Leonid Krivoshein пишет:
> > > > 23.08.2021 14:48, Alexey Gladkov пишет:
> > > > > On Mon, Aug 23, 2021 at 02:04:06PM +0300, Leonid Krivoshein wrote:
> > > > > > > [...]
> > > > > > > Не стоит ли сделать поддержку netconsole глобальной ?
> > > Полагаю, глобальной должна быть опция nottys и организация захвата и
> > > освобождения TTY'ов разными фичами. Тогда и вопрос расшаривания консоли
> > > решается проще.
> > Я не очень понял про захват tty в том смысле, что ты предлагаешь ?
> 
> Любая фича, которая хочет использовать конкретный TTY или общий
> /dev/console, вроде как не должна это делать на своё усмотрение. Хорошо бы
> иметь общий механизм захвата и освобождения указанной TTY, например, в
> initrd-sh-functions:

В rdshell-sh-functions уже есть console_lock/console_unlock, которые
уже применяются в коде. Правда, выбора номера терминала они не
предусматривают.

> lock_tty(n)
> unlock_tty(n)
> 
> где n, номер VT либо 0 для /dev/console и netconsole.
>
> иначе асинхронная работа двух разных фич с одним терминалом не будет
> согласованной.

А как код будет понимать, что ему лочить N или 0 ? Я всё ещё не понимаю,
что будет в netconsole.

> > > > > > С этой netconsole наловил кучу дистрибутивных багов, не связанных с
> > > > > > make-initrd. Не все умеют с ней работать, даже grub работает лишь в
> > > > > > определённых условиях, в зависимости от образа. Нужно сначала
> > > > > > понять, то ли
> > > > > > я вообще сделал, что требовалось? Мне не удалось найти надёжного
> > > > > > способа
> > > > > > автоматического определения netconsole, поэтому пришлось ввести
> > > > > > ещё один
> > > > > > параметр nottys. Но вообще реализация получилась очень простой
> > > > > > и, на первый
> > > > > > взгляд, рабочей, и даже код определения размеров консоли
> > > > > > пришёлся кстати.
> > > > > > :-)
> > > > > Надо будет посмотреть на этот код. Очень интересно.
> > > > #283645 -- так быстрее. И... sorry for my English! ))
> > > > 
> > > Допустил в README опечатку в конце. Но лучше этот код немного доделать. В
> > > исходной реализации не было разделения процесса на две части, перевода на
> > > передний план. Просто запрашивалась активация и выводились виджеты. В
> > > последней реализации, которую пришлось существенно пересмотреть, всё сделано
> > > для того, чтобы диалоги не мелькали лишний раз без надобности, чтобы их
> > > вывод не смешивался с выводом на tty1 от демонов, который организует
> > > make-initrd.
> > > 
> > > Особенно при использовании nottys и rdshell хорошо заметно, как на
> > > единственной текущей консоли дерутся за ввод и вывод rdshell, виджеты и
> > > вывод от демонов. Возможно тут не хватает блокировок.
> > rdshell и вывод на консоль это отдельная сложная задача. На консоль пишут
> > не только сервисы, но и утилиты, которые про notty и вообще всё это ничего
> > не знают.
> > 
> > Есть два варианта:
> > 
> > * перенаправить вывод сервисов в лог файлы.
> > * использовать для их вывода другой tty, но в этом случае будут проблемы с
> >    serial/net console.
> > > Думаю, будет не сложно добавить альтернативный вариант активации с
> > > использованием текущей консоли, без разделения процесса через IM_exec().
> > Я вот этого не понял.
> 
> API должен быть написан исходя из конкретных потребностей, а не чтобы просто
> был. Кому и как может потребоваться API для работы с диалогами ввода/вывода?
> Я исхожу из того, что "пользователи" API -- это фичи make-initrd, это
> работающий код демонов, вывод которых уже куда-то перенаправлен, например в
> журнал или на /dev/console. Или это обработчики событий. Вдруг, им
> недостаточно события, а надо ещё и у пользователя что-то спросить? А может
> они ждут события, чтобы после него спросить нечто у пользователя? Например,
> PIN-код на вставленный токен.

Так уже есть фичи, которые спрашивают пин и они пользуются console_lock.

> При написании bootchain я всё это прошёл и по настоянию Антона Мидюкова
> капитально переделал работу с консолью.
> 
> Изначально идея была простая. В скрипте, в котором нужны виджеты, вызывается
> IM_activate(). И далее в нём же выводятся диалоги. Чтобы сохранить и потом
> восстановить tty1, занятой выводом сообщений make-initrd и демонов, ввод и
> вывод внутри IM_activate() перенаправлялся на /dev/tty2 и туда производилось
> немедленное переключение через chvt 2. Любой другой скрипт делал всё то же
> самое, но повторно переключение на TTY2 не выполнялось, активация консоли
> делалась лишь единожды.
> 
> Причина переработки всей концепции заключалась в том, что если нет ввода, а
> есть только вывод и этот вывод в процессе загрузки выполняется очень быстро
> (2-3 секунды на практике), то и незачем видеть все эти лишние мелькания на
> экране. У нас даже баг такой открыт на propagator -- ведь у него тоже это
> имело место, причём он, в отличие от altboot, работал на tty1.
> 
> Чтобы реализовать отложенную активацию консоли, процесс открытия терминала
> tty2 и его инициализацию пришлось разделить на два процесса. IM_exec()
> инициирует создание tty2 и запуска в нём указанного процесса, возможно
> перезапустить тут сам демон с нужным параметром. А уже будучи запущенным
> порождённый процесс вызывает IM_activate().
> 
> Такая реализация годится для bootchain, но чтобы переносить её на уровень
> выше в make-initrd нужно заново определить всю концепцию диалогового
> ввода/вывода. Я бы исходил из того, что:
> 
> 1) По возможности, диалоги в/в не должны работать с tty1, т.к. эта консоль
> для сообщений make-initrd.
> 2) Не нужно иметь несколько tty'ов для диалогов, достаточно всего одного,
> например, tty2.
> 3) В случае netconsole все работают с единственной текущей консолью, что
> требует вызова reset после работы с программой dialog, иначе теряется
> клавиатурный ввод (не знаю, почему). Я бы использовал тут же блокировку для
> процессов вывода сообщений и захвата клавиатурного ввода.
> 4) Хорошо бы предусмотреть отложенное переключение на tty2 для диалогов
> вывода. Но для ошибок и диалогов ввода оно должно быть немедленным.
> 5) Хороший вопрос -- кто и когда должен освободить консоль tty2? Это
> обязательно надо делать, иначе оставшийся мусор переезжает в stage2. В
> случае с bootchain это делалось автоматически в exit_handler().
> 
> Теперь отвечу на вопрос.
> 
> Можно вернуть исходную простую реализацию IM_activate(): http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=recent/bootchain/data/sbin/IM-sh-functions;h=c09ab2ed1c1833a6ad60ba4c871bb32d2d374d90;hb=974e6a5e7f662bcf484d3c9a432ed3a7ad65de1c#l32
> в расчёте на то, что демоны или обработчики make-initrd ничего не хотят
> знать о разделении на два процесса, и если им нужно что-либо ввести или
> вывести, то вызов любого виджета должен автоматом приводить к активации
> нужного VT.
> 
> Мне кажется, если фича intarcative попадает в образ, она должна готовить
> tty2, а до перехода в stage2 его освобождать. Вообще, пока нет двух фич,
> которым нужны диалоги, весьма муторно проектировать правила работы. В
> нынешнем виде фича пригодна для единоличного использования другой фичей. Но
> для общего пользования её придётся немного доработать, определившись с
> концепцией в/в на уровне make-initrd.
> 
> 
> > > В нынешнем виде фичу interactive может использовать любая другая фича. Но
> > > как только станет два "пользователя", эта конструкция перестанет быть
> > > рабочей. Как лучше воткнуть блокировки, тебе видней. Есть ещё фича kbd, и
> > > она сбрасывает/перенастраивает консоли. Соответствующий демон должен
> > > запускаться и полностью отрабатывать до фичи interactive, если попадает в
> > > initramfs. Не знаю, как это лучше организовать.
> > А kbd разве нужна для bootchain ?
> 
> Нет, но она тоже использует tty2. А если демоны запускаются и работают
> параллельно, то работающий код в kbd может что-то испортить на tty2 в
> нынешнем bootchain-interactive. Вот почему предлагаю использовать тут
> блокировки, ttyN -- это конкретный ресурс.
> 
> 
> > Для синхронизации с kbd можно поступить как с сетью и сделать сервис
> > kbd-ready, который можно ставить в зависимости других сервисов.
> 
> А вот тут уже я не понял.))

На runlevel 3 запускаются сервисы. Чтобы синхронизировать свой запуск с
асинхронными событиями такими как поднятие сети был сделан псевдосервис
network-up (он приезжает с фичей network). Сервисы, которым нужна сеть
ставят его в зависимости и будут запущены после него.

Такую же штуку можно сделать и для настройки терминалов. В этом случае
можно будет стартовать сервис после того как фича kbd отработает.

> > > > [...]
> > > > 
> > > > > > Отлично! Будет смысл согласовать "окно" после финальной проверки всего
> > > > > > комплекса. Привязка по времени к продуктам на p10 необязательна,
> > > > > > так как для
> > > > > > тестирования решения более широкими массами оно должно сначала
> > > > > > попасть в
> > > > > > Сизиф и тогда есть шанс наловить больше багов на регулярках. При
> > > > > > переносе в
> > > > > > make-initrd мне придётся параллельно удалять это из Сизифа.
> > > > > Ты предлагаешь растянуть мердж bootchain на несколько релизов
> > > > > make-initrd?
> > > > Наоборот, спрашиваю, как лучше. Тут только ты определяешь...
> > > > 
> > Извини, что не ответил раньше. Я подзалип из-за релизе другого проекта.
> 
> Вот и у меня получилось два месяца полной приостановки, так что хорошо
> понимаю. Сейчас уже вернулся к altboot и уже очень скоро всё доделаю (по
> плану).
> 
> 
> > > Отправил пока всю пачку в Сизиф (#284217), чтобы начать полномасштабное
> > > тестирование на железе. Тем временем доделываю формализацию и частичную
> > > автоматизацию тестирования. В корне проекта появились новые скрипты для
> > > этого и пока только частично написанный testplan. Но я освободился от других
> > > больших дел, так что в свободное время оставшееся доделаю быстро.
> > Мне бы не хотелось делать релиз make-initrd (не путать со сборкой пакета в
> > сизиф) с частично рабочей фичей. Поэтому я предлагаю отладить патчи на
> > сизифе и тогда я сделаю релиз. В этом случае мы сможем делать сборки и
> > дорабатывать эту фичу.
> > 
> > Что думаешь ?
> 
> Да, конечно. Движение в апстрим я и сам хотел начать не раньше, чем будет
> написан testpaln до конца, написаны все README, пройдены все тесты по
> тестплану. Отправка в Сизиф сейчас увеличивает масштаб тестирования на
> реальном железе, поскольку очень скоро на altboot будет переключена сборка
> регулярок.
> 
> Однако, меня просили поторопиться с pseudo-gui, вот я её и отделил пораньше,
> запустил, как пробный шар. :-) Моё многословное объяснение выше о том, что
> будучи в коде bootchain и тестируясь в составе bootchain фича interactive не
> становится автоматом пригодной для работы в качестве API между несколькими
> фичами, для этих целей её придётся дорабатывать и, в идеале, для этого нужен
> второй "клиент" фичи interactive плюс утверждение концепции работы с tty с
> твоей стороны.

Так. Я понял, что я совсем не в контексте и не могу продуктивно обсуждать,
то что не видел. Присылай патчи, мы их обсудим, а потом подумаем, что
нужно от остального кода.

-- 
Rgrds, legion