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

Mon Aug 30 22:54:35 MSK 2021

30.08.2021 21:13, Alexey Gladkov пишет:
> On Mon, Aug 30, 2021 at 08:14:49PM +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:

lock_tty(n)
unlock_tty(n)

где n, номер VT либо 0 для /dev/console и 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-код на вставленный токен.

При написании 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, который можно ставить в зависимости других сервисов.

А вот тут уже я не понял.))

>>> [...]
>>>
>>>>> Отлично! Будет смысл согласовать "окно" после финальной проверки всего
>>>>> комплекса. Привязка по времени к продуктам на p10 необязательна,
>>>>> так как для
>>>>> тестирования решения более широкими массами оно должно сначала
>>>>> попасть в
>>>>> Сизиф и тогда есть шанс наловить больше багов на регулярках. При
>>>>> переносе в
>>>>> make-initrd мне придётся параллельно удалять это из Сизифа.
>>>> Ты предлагаешь растянуть мердж bootchain на несколько релизов
>>>> make-initrd?
>>> Наоборот, спрашиваю, как лучше. Тут только ты определяешь...
>>>
> Извини, что не ответил раньше. Я подзалип из-за релизе другого проекта.

Вот и у меня получилось два месяца полной приостановки, так что хорошо 
понимаю. Сейчас уже вернулся к altboot и уже очень скоро всё доделаю (по 
плану).

>> Отправил пока всю пачку в Сизиф (#284217), чтобы начать полномасштабное
>> тестирование на железе. Тем временем доделываю формализацию и частичную
>> автоматизацию тестирования. В корне проекта появились новые скрипты для
>> этого и пока только частично написанный testplan. Но я освободился от других
>> больших дел, так что в свободное время оставшееся доделаю быстро.
> Мне бы не хотелось делать релиз make-initrd (не путать со сборкой пакета в
> сизиф) с частично рабочей фичей. Поэтому я предлагаю отладить патчи на
> сизифе и тогда я сделаю релиз. В этом случае мы сможем делать сборки и
> дорабатывать эту фичу.
>
> Что думаешь ?

Да, конечно. Движение в апстрим я и сам хотел начать не раньше, чем 
будет написан testpaln до конца, написаны все README, пройдены все тесты 
по тестплану. Отправка в Сизиф сейчас увеличивает масштаб тестирования 
на реальном железе, поскольку очень скоро на altboot будет переключена 
сборка регулярок.

Однако, меня просили поторопиться с pseudo-gui, вот я её и отделил 
пораньше, запустил, как пробный шар. :-) Моё многословное объяснение 
выше о том, что будучи в коде bootchain и тестируясь в составе bootchain 
фича interactive не становится автоматом пригодной для работы в качестве 
API между несколькими фичами, для этих целей её придётся дорабатывать и, 
в идеале, для этого нужен второй "клиент" фичи interactive плюс 
утверждение концепции работы с tty с твоей стороны.

-- 
Best regards,
Leonid Krivoshein.