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

[Alexey Gladkov <gladkov.alexey@gmail.com>]

On Mon, Aug 23, 2021 at 02:04:06PM +0300, Leonid Krivoshein wrote:
> > > 1. Разобраться, как запускать виртуалку с -novga (без TTY's) и поработать в
> > > консоли с dialog.
> > Говорю просто для информации. В master переехала фича bootloader с TUI на
> > libnewt. Правда он не модульный. Я слышал, что Петр Михалицын имеет
> > некоторые мысли по развитию этого TUI.
> 
> Больше фич хороших и разных! Надо будет потом посмотреть.

Это не самодостаточная фича. Это часть:

https://github.com/osboot/make-initrd-bootloader

Это мой текущий bootloader.

> Насчёт именно libnewt, помню, у коллег были большие сомнения. К слову, и
> propagator написан с зависимостями на неё.

Те кто писал на ncurses поймут почему я выбрал эту библиотеку :)

> > > 2. Добавить в bootchain-core и bootchain-intractive код для поддержки
> > > netconsole.
> > Не стоит ли сделать поддержку netconsole глобальной ?
> 
> Вчера уже выгрузил этот код, вроде всё работает. Основное попало в
> bootchain-interactive (bootchain-sh-functions и чуток в виджеты). Именно его
> с поддержкой netconsole имеет смысл делать отдельной фичей, как только её
> лучше назвать? В bootchain-core (форк pipeline) попало лишь крошечное
> изменение, теперь демон понимает опцию nottys, чтобы не создавать на tty3
> процесс вывода журнала, это параметр из bootchain-interactive.
> 
> С этой netconsole наловил кучу дистрибутивных багов, не связанных с
> make-initrd. Не все умеют с ней работать, даже grub работает лишь в
> определённых условиях, в зависимости от образа. Нужно сначала понять, то ли
> я вообще сделал, что требовалось? Мне не удалось найти надёжного способа
> автоматического определения netconsole, поэтому пришлось ввести ещё один
> параметр nottys. Но вообще реализация получилась очень простой и, на первый
> взгляд, рабочей, и даже код определения размеров консоли пришёлся кстати.
> :-)

Надо будет посмотреть на этот код. Очень интересно.
 
> Решаю задачу с автоматизацией тестирования в полу-ручном режиме и
> формализацией этого процесса. Осталось не так уж много. Разворачивать стенд
> полностью вручную и вспоминать на память все тест-кейсы каждый раз было бы
> неправильно. Но и закрыть проблему через какой-нибудь CI я сходу не смогу,
> не имел с этим опыта пока.

Тесты это всегда трудно.

> > > 1. Будем перетаскивать bootchain-interactive в первую очередь отдельно от
> > > остального и под каким именем? См.:
> > > https://lists.altlinux.org/pipermail/make-initrd/2021-June/000454.html
> > Возможность доспросить у пользователя что-нибудь давно назрела. Было бы
> > здорово иметь её для всех модулей.
> 
> Нужно переименовать, чтобы не было ассоциации с bootchain. Только во что?
> early-dialog? im? interactive? interactive-mode? ...

Нужно посмотреть на код. Насколько я понимаю, для работы в полную силу эта
фича требует присутствия вызовов интерактивных функций везде, где
происходит запрос данных у пользователя. Это так ?

Если да, то получается, что этот функционал должен быть в data/, а вот
бэкенды рисующие диалоги должны быть в фиче или фичах.

Ну или я просто плохо помню идею и несу чушь.

> > > 2. Будем сначала решать проблему обеспечения полной совместимости с
> > > pipeline? См.:
> > > https://lists.altlinux.org/pipermail/make-initrd/2021-July/000500.html
> > Мне уже двое пользователей сказали о том, что используют pipeline. Я
> > считаю, что держать два почти одинаковых модуля не имеет смысла тем более,
> > что один вырос из другого.
> 
> Вчера я нашёл свою ошибку и у меня всё заработало с altboot даже так:
> root=pipeline pipeline=fg,altboot, вопреки черновику документации! :-)

\o/

> > > 4. Будем дожидаться появления в make-initrd API для проверки и сравнения
> > > версии или оставим это пока в bootchain? См.:
> > > https://lists.altlinux.org/pipermail/make-initrd/2021-July/000471.html
> > Постой. Тот тред был о том, что в /etc/initrd-release попадала
> > неправильная версия, что было исправлено. Ни о каком API для сравнения
> > речи не было.
> > 
> > Зачем такой API вообще нужен ?
> 
> Плохо то, что я начал не с него, хотя про API говорил тоже, но позже. Сейчас
> конкретной нужды нет. Но если поведение чего-либо в самом make-initrd
> меняется в зависимости от версии, то было бы здорово такой API иметь -- у
> всех библиотек подобное есть и make-initrd для фич предоставляет какой-то
> API.

Мне не очень хочется добавлять код "на всякий случай". Версия в образе
присутствует. Если возникнет необходимость, то функцию проверки напишем.

> Но в первую очередь я интересовался переносом функции initrd_version()
> из bootchain-core, т.к. это уже второй "клиент", выводящий версию initramfs.

А. Ну создать функцию, которая возвращает версию можно.

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

Ты предлагаешь растянуть мердж bootchain на несколько релизов make-initrd?

-- 
Rgrds, legion