Make-initrd development discussion
 help / color / mirror / Atom feed
* [make-initrd] bootchain+altboot: у меня есть план
@ 2021-08-21 19:14 Leonid Krivoshein
  2021-08-22 19:29 ` Leonid Krivoshein
  2021-08-23  9:29 ` Alexey Gladkov
  0 siblings, 2 replies; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-21 19:14 UTC (permalink / raw)
  To: make-initrd

Алексей, привет!


Почти два месяца, включая срочный проект и отпуск в полном ауте, но уже 
вернулся к bootchain+altboot...


Оставшиеся у меня задачи:
=========================

1. Разобраться, как запускать виртуалку с -novga (без TTY's) и 
поработать в консоли с dialog.
2. Добавить в bootchain-core и bootchain-intractive код для поддержки 
netconsole.
3. Подготовить систему автоматизации развёртывания сервера сетевой 
загрузки и установки.
4. Добавить README по каждой фиче bootchain.
5. Выполнить финальное тестирование всех возможных кейсов и 
задокументировать этот процесс.
6. Отлаженный пакет отправить в Сизиф, попросить Антона Мидюкова 
собирать регулярки с bootchain.
7. Согласовать с тобой оставшиеся вопросы по процессу апстрима в 
make-initrd.
8. Заапстримить новые фичи в make-initrd до выпуска продуктов на p10 
(2021/10).
9. Обсудить разногласия и замечания по документации.

Уже работаю по этому плану!


Вопросы для согласования плана по апстриму bootchain:
=====================================================

1. Будем перетаскивать bootchain-interactive в первую очередь отдельно 
от остального и под каким именем? См.: 
https://lists.altlinux.org/pipermail/make-initrd/2021-June/000454.html

2. Будем сначала решать проблему обеспечения полной совместимости с 
pipeline? См.: 
https://lists.altlinux.org/pipermail/make-initrd/2021-July/000500.html

3. Будем дожидаться поддержки в самом make-initrd функционала проверки 
фичи или оставим это пока в bootchain? См.: 
https://lists.altlinux.org/pipermail/make-initrd/2021-July/000474.html

4. Будем дожидаться появления в make-initrd API для проверки и сравнения 
версии или оставим это пока в bootchain? См.: 
https://lists.altlinux.org/pipermail/make-initrd/2021-July/000471.html

5. Будем дожидаться переноса в make-initrd API для более глубокой 
отладки или оставим это пока в bootchain? См.: 
https://lists.altlinux.org/pipermail/make-initrd/2021-July/000476.html

6. Будешь ли ты сам ревьювить полностью отлаженный код до начала 
процесса апстрима или тебе лучше делать это по ходу?

7. Предлагаю такую последовательность отправки коммитов: 
bootchain-interactive, затем bootchain-core + bootchain-getimage + 
bootchain-waitdev, затем замена фичи pipeline виртуальной зависимостью 
на фичи bootchain-getimage и bootchain-waitdev, всё остальное (вся пачка 
altboot), можно одним коммитом. Так пойдёт?



-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-21 19:14 [make-initrd] bootchain+altboot: у меня есть план Leonid Krivoshein
@ 2021-08-22 19:29 ` Leonid Krivoshein
  2021-08-23  9:29 ` Alexey Gladkov
  1 sibling, 0 replies; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-22 19:29 UTC (permalink / raw)
  To: make-initrd


21.08.2021 22:14, Leonid Krivoshein пишет:
> 1. Разобраться, как запускать виртуалку с -novga (без TTY's) и 
> поработать в консоли с dialog.
> 2. Добавить в bootchain-core и bootchain-intractive код для поддержки 
> netconsole.
> [...]
> 2. Будем сначала решать проблему обеспечения полной совместимости с 
> pipeline? См.: 
> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000500.html
>

Появилась поддержка netconsole, заработал режим полной совместимости с 
pipeline, изменения уже в локальной гитовнице. Для запуска виртуалки 
достаточно добавить:

-vga none -device virtio-gpu,xres=1280,yres=800 -nographic -vnc :5 
-serial mon:stdio

А в госте грузиться с добавлением параметров: console=ttyS0 nottys

При этом все диалоги в цвете работают через первый COM-порт (в консоли 
хоста), а устройства tty* становятся доступными уже после перехода в 
stage2 по VNC, и добраться до них можно, например, так:

remote-viewer vnc://localhost:5905

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


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-21 19:14 [make-initrd] bootchain+altboot: у меня есть план Leonid Krivoshein
  2021-08-22 19:29 ` Leonid Krivoshein
@ 2021-08-23  9:29 ` Alexey Gladkov
  2021-08-23 11:04   ` Leonid Krivoshein
  2021-08-23 11:19   ` Leonid Krivoshein
  1 sibling, 2 replies; 14+ messages in thread
From: Alexey Gladkov @ 2021-08-23  9:29 UTC (permalink / raw)
  To: make-initrd

On Sat, Aug 21, 2021 at 10:14:22PM +0300, Leonid Krivoshein wrote:
> Алексей, привет!
> 
> 
> Почти два месяца, включая срочный проект и отпуск в полном ауте, но уже
> вернулся к bootchain+altboot...
> 
> 
> Оставшиеся у меня задачи:
> =========================
> 
> 1. Разобраться, как запускать виртуалку с -novga (без TTY's) и поработать в
> консоли с dialog.

Говорю просто для информации. В master переехала фича bootloader с TUI на
libnewt. Правда он не модульный. Я слышал, что Петр Михалицын имеет
некоторые мысли по развитию этого TUI.

> 2. Добавить в bootchain-core и bootchain-intractive код для поддержки
> netconsole.

Не стоит ли сделать поддержку netconsole глобальной ?

> 3. Подготовить систему автоматизации развёртывания сервера сетевой загрузки
> и установки.
> 4. Добавить README по каждой фиче bootchain.
> 5. Выполнить финальное тестирование всех возможных кейсов и
> задокументировать этот процесс.
> 6. Отлаженный пакет отправить в Сизиф, попросить Антона Мидюкова собирать
> регулярки с bootchain.
> 7. Согласовать с тобой оставшиеся вопросы по процессу апстрима в
> make-initrd.
> 8. Заапстримить новые фичи в make-initrd до выпуска продуктов на p10
> (2021/10).
> 9. Обсудить разногласия и замечания по документации.
> 
> Уже работаю по этому плану!

Я считаю, что план должен быть удобным тебе. Мне сложно приоритезировать
работу, которую я не видел :) Ты автор, тебе и представлять работу.

> Вопросы для согласования плана по апстриму bootchain:
> =====================================================
> 
> 1. Будем перетаскивать bootchain-interactive в первую очередь отдельно от
> остального и под каким именем? См.:
> https://lists.altlinux.org/pipermail/make-initrd/2021-June/000454.html

Возможность доспросить у пользователя что-нибудь давно назрела. Было бы
здорово иметь её для всех модулей.

> 2. Будем сначала решать проблему обеспечения полной совместимости с
> pipeline? См.:
> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000500.html

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

> 3. Будем дожидаться поддержки в самом make-initrd функционала проверки фичи
> или оставим это пока в bootchain? См.:
> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000474.html

Это я сделаю в следующем релизе.

> 4. Будем дожидаться появления в make-initrd API для проверки и сравнения
> версии или оставим это пока в bootchain? См.:
> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000471.html

Постой. Тот тред был о том, что в /etc/initrd-release попадала
неправильная версия, что было исправлено. Ни о каком API для сравнения
речи не было.

Зачем такой API вообще нужен ?

> 5. Будем дожидаться переноса в make-initrd API для более глубокой отладки
> или оставим это пока в bootchain? См.:
> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000476.html

Это в некотором смысле с предложенной фичёй debug-tools:

https://github.com/osboot/make-initrd/pull/15

Правда она приносит gdb/strace, а не отладку в скрипты. Можно их
объединить или же держать отдельно для разных уровней отладки.

> 6. Будешь ли ты сам ревьювить полностью отлаженный код до начала процесса
> апстрима или тебе лучше делать это по ходу?

Мне удобнее по ходу так как если вдруг возникнут вопросы, то править будет
удобнее.

> 7. Предлагаю такую последовательность отправки коммитов:
> bootchain-interactive, затем bootchain-core + bootchain-getimage +
> bootchain-waitdev, затем замена фичи pipeline виртуальной зависимостью на
> фичи bootchain-getimage и bootchain-waitdev, всё остальное (вся пачка
> altboot), можно одним коммитом. Так пойдёт?

Вполне.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-23  9:29 ` Alexey Gladkov
@ 2021-08-23 11:04   ` Leonid Krivoshein
  2021-08-23 11:48     ` Alexey Gladkov
  2021-08-23 11:19   ` Leonid Krivoshein
  1 sibling, 1 reply; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-23 11:04 UTC (permalink / raw)
  To: make-initrd


23.08.2021 12:29, Alexey Gladkov пишет:
> On Sat, Aug 21, 2021 at 10:14:22PM +0300, Leonid Krivoshein wrote:
>> Алексей, привет!
>>
>>
>> Почти два месяца, включая срочный проект и отпуск в полном ауте, но уже
>> вернулся к bootchain+altboot...
>>
>>
>> Оставшиеся у меня задачи:
>> =========================
>>
>> 1. Разобраться, как запускать виртуалку с -novga (без TTY's) и поработать в
>> консоли с dialog.
> Говорю просто для информации. В master переехала фича bootloader с TUI на
> libnewt. Правда он не модульный. Я слышал, что Петр Михалицын имеет
> некоторые мысли по развитию этого TUI.

Больше фич хороших и разных! Надо будет потом посмотреть.

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


>> 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. Но вообще реализация получилась очень простой 
и, на первый взгляд, рабочей, и даже код определения размеров консоли 
пришёлся кстати. :-)


>> 3. Подготовить систему автоматизации развёртывания сервера сетевой загрузки
>> и установки.
>> 4. Добавить README по каждой фиче bootchain.
>> 5. Выполнить финальное тестирование всех возможных кейсов и
>> задокументировать этот процесс.
>> 6. Отлаженный пакет отправить в Сизиф, попросить Антона Мидюкова собирать
>> регулярки с bootchain.
>> 7. Согласовать с тобой оставшиеся вопросы по процессу апстрима в
>> make-initrd.
>> 8. Заапстримить новые фичи в make-initrd до выпуска продуктов на p10
>> (2021/10).
>> 9. Обсудить разногласия и замечания по документации.
>>
>> Уже работаю по этому плану!
> Я считаю, что план должен быть удобным тебе. Мне сложно приоритезировать
> работу, которую я не видел :) Ты автор, тебе и представлять работу.

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

Если не считать последней формальной проверки и недостатка переведённых 
README, весь код уже готов, я считаю.


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

Нужно переименовать, чтобы не было ассоциации с bootchain. Только во 
что? early-dialog? im? interactive? interactive-mode? ...


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

Вчера я нашёл свою ошибку и у меня всё заработало с altboot даже так: 
root=pipeline pipeline=fg,altboot, вопреки черновику документации! :-)


>> 3. Будем дожидаться поддержки в самом make-initrd функционала проверки фичи
>> или оставим это пока в bootchain? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000474.html
> Это я сделаю в следующем релизе.

Отлично! Уже видел часть проделанной работы в новых коммитах.

Тогда я (после разговора с тобой) создал несколько тредов для обсуждения 
возможности переноса из bootchain-sh-functions части API на более 
верхний уровень make-initrd...


>> 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.


>> 5. Будем дожидаться переноса в make-initrd API для более глубокой отладки
>> или оставим это пока в bootchain? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000476.html
> Это в некотором смысле с предложенной фичёй debug-tools:
>
> https://github.com/osboot/make-initrd/pull/15
>
> Правда она приносит gdb/strace, а не отладку в скрипты. Можно их
> объединить или же держать отдельно для разных уровней отладки.
>
>> 6. Будешь ли ты сам ревьювить полностью отлаженный код до начала процесса
>> апстрима или тебе лучше делать это по ходу?
> Мне удобнее по ходу так как если вдруг возникнут вопросы, то править будет
> удобнее.

OK.


>> 7. Предлагаю такую последовательность отправки коммитов:
>> bootchain-interactive, затем bootchain-core + bootchain-getimage +
>> bootchain-waitdev, затем замена фичи pipeline виртуальной зависимостью на
>> фичи bootchain-getimage и bootchain-waitdev, всё остальное (вся пачка
>> altboot), можно одним коммитом. Так пойдёт?
> Вполне.

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


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-23  9:29 ` Alexey Gladkov
  2021-08-23 11:04   ` Leonid Krivoshein
@ 2021-08-23 11:19   ` Leonid Krivoshein
  1 sibling, 0 replies; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-23 11:19 UTC (permalink / raw)
  To: make-initrd


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

Моё первое сообщение в треде и правда больше похоже на багрепорт, хотя я 
имел ввиду именно это: 
https://lists.altlinux.org/pipermail/make-initrd/2021-July/000488.html :-)


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-23 11:04   ` Leonid Krivoshein
@ 2021-08-23 11:48     ` Alexey Gladkov
  2021-08-24  1:16       ` Leonid Krivoshein
  0 siblings, 1 reply; 14+ messages in thread
From: Alexey Gladkov @ 2021-08-23 11:48 UTC (permalink / raw)
  To: make-initrd

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-23 11:48     ` Alexey Gladkov
@ 2021-08-24  1:16       ` Leonid Krivoshein
  2021-08-30 17:14         ` Leonid Krivoshein
  0 siblings, 1 reply; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-24  1:16 UTC (permalink / raw)
  To: make-initrd


23.08.2021 14:48, Alexey Gladkov пишет:
> On Mon, Aug 23, 2021 at 02:04:06PM +0300, Leonid Krivoshein wrote:
>>> [...]
>>> Не стоит ли сделать поддержку netconsole глобальной ?
>> Вчера уже выгрузил этот код, вроде всё работает. Основное попало в
>> bootchain-interactive (bootchain-sh-functions и чуток в виджеты). Именно его
>> с поддержкой netconsole имеет смысл делать отдельной фичей, как только её
>> лучше назвать? В bootchain-core (форк pipeline) попало лишь крошечное
>> изменение, теперь демон понимает опцию nottys, чтобы не создавать на tty3
>> процесс вывода журнала, это параметр из bootchain-interactive.
>>
>> С этой netconsole наловил кучу дистрибутивных багов, не связанных с
>> make-initrd. Не все умеют с ней работать, даже grub работает лишь в
>> определённых условиях, в зависимости от образа. Нужно сначала понять, то ли
>> я вообще сделал, что требовалось? Мне не удалось найти надёжного способа
>> автоматического определения netconsole, поэтому пришлось ввести ещё один
>> параметр nottys. Но вообще реализация получилась очень простой и, на первый
>> взгляд, рабочей, и даже код определения размеров консоли пришёлся кстати.
>> :-)
> Надо будет посмотреть на этот код. Очень интересно.

#283645 -- так быстрее. И... sorry for my English! ))


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

Я бы сказал, что это скорее просто API. Везде, где нужен ввод и/или 
вывод, это API можно использовать. Соответственно, кому эта фича нужна, 
он её подключает через $(call feature-requires,interactive) в config.mk. 
Если в коде нужен интерактивный ввод и/или вывод, нужно подключить API:

. interactive-sh-functions

Единственный пример того, как перезапустить процесс на передний план 
сейчас есть в bootchain-core (/sbin/bootchain-loop). Только в нём 
используется IM_exec() и IM_activate(), они вместе демонстрируют 
механизм перезапуска с отложенной активацией консоли (tty2 по 
умолчанию). Как делить одну консоль на всех "клиентов", данное API пока 
никак не решает, но если кому-то нужен свой отдельный tty, можно перед 
включением файла переопределить _IM_VT_number. Возможно фичу стоит 
доработать, чтобы одну консоль можно было расшарить между "клиентами", 
но я в этом не уверен. Другой вопрос -- как это будет уживаться с фичей 
kbd. С rdshell теперь вроде уживается.


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

Без "клиентов" данная фича неинтересна, а почти готовый "клиент" пока 
только один -- это altboot. Примеры использования виджетов раскиданы по 
всему altboot.


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

Хорошо, уже есть такой вариант:
https://lists.altlinux.org/pipermail/make-initrd/2021-July/000471.html


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

Наоборот, спрашиваю, как лучше. Тут только ты определяешь...


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-24  1:16       ` Leonid Krivoshein
@ 2021-08-30 17:14         ` Leonid Krivoshein
  2021-08-30 18:13           ` Alexey Gladkov
  0 siblings, 1 reply; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-30 17:14 UTC (permalink / raw)
  To: make-initrd

Привет!


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'ов разными фичами. Тогда и вопрос расшаривания консоли 
решается проще.


>>> [...]
>>>
>>> С этой netconsole наловил кучу дистрибутивных багов, не связанных с
>>> make-initrd. Не все умеют с ней работать, даже grub работает лишь в
>>> определённых условиях, в зависимости от образа. Нужно сначала 
>>> понять, то ли
>>> я вообще сделал, что требовалось? Мне не удалось найти надёжного 
>>> способа
>>> автоматического определения netconsole, поэтому пришлось ввести ещё 
>>> один
>>> параметр nottys. Но вообще реализация получилась очень простой и, на 
>>> первый
>>> взгляд, рабочей, и даже код определения размеров консоли пришёлся 
>>> кстати.
>>> :-)
>> Надо будет посмотреть на этот код. Очень интересно.
>
> #283645 -- так быстрее. И... sorry for my English! ))
>

Допустил в README опечатку в конце. Но лучше этот код немного доделать. 
В исходной реализации не было разделения процесса на две части, перевода 
на передний план. Просто запрашивалась активация и выводились виджеты. В 
последней реализации, которую пришлось существенно пересмотреть, всё 
сделано для того, чтобы диалоги не мелькали лишний раз без надобности, 
чтобы их вывод не смешивался с выводом на tty1 от демонов, который 
организует make-initrd.

Особенно при использовании nottys и rdshell хорошо заметно, как на 
единственной текущей консоли дерутся за ввод и вывод rdshell, виджеты и 
вывод от демонов. Возможно тут не хватает блокировок.

Думаю, будет не сложно добавить альтернативный вариант активации с 
использованием текущей консоли, без разделения процесса через IM_exec().

В нынешнем виде фичу interactive может использовать любая другая фича. 
Но как только станет два "пользователя", эта конструкция перестанет быть 
рабочей. Как лучше воткнуть блокировки, тебе видней. Есть ещё фича kbd, 
и она сбрасывает/перенастраивает консоли. Соответствующий демон должен 
запускаться и полностью отрабатывать до фичи interactive, если попадает 
в initramfs. Не знаю, как это лучше организовать.


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

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


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-30 17:14         ` Leonid Krivoshein
@ 2021-08-30 18:13           ` Alexey Gladkov
  2021-08-30 19:54             ` Leonid Krivoshein
  0 siblings, 1 reply; 14+ messages in thread
From: Alexey Gladkov @ 2021-08-30 18:13 UTC (permalink / raw)
  To: make-initrd

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 в том смысле, что ты предлагаешь ?

> > > > С этой 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().

Я вот этого не понял.

> В нынешнем виде фичу interactive может использовать любая другая фича. Но
> как только станет два "пользователя", эта конструкция перестанет быть
> рабочей. Как лучше воткнуть блокировки, тебе видней. Есть ещё фича kbd, и
> она сбрасывает/перенастраивает консоли. Соответствующий демон должен
> запускаться и полностью отрабатывать до фичи interactive, если попадает в
> initramfs. Не знаю, как это лучше организовать.

А kbd разве нужна для bootchain ?

Для синхронизации с kbd можно поступить как с сетью и сделать сервис
kbd-ready, который можно ставить в зависимости других сервисов.

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

Извини, что не ответил раньше. Я подзалип из-за релизе другого проекта.

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

Мне бы не хотелось делать релиз make-initrd (не путать со сборкой пакета в
сизиф) с частично рабочей фичей. Поэтому я предлагаю отладить патчи на
сизифе и тогда я сделаю релиз. В этом случае мы сможем делать сборки и
дорабатывать эту фичу.

Что думаешь ?

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-30 18:13           ` Alexey Gladkov
@ 2021-08-30 19:54             ` Leonid Krivoshein
  2021-08-31  7:40               ` Alexey Gladkov
  0 siblings, 1 reply; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-30 19:54 UTC (permalink / raw)
  To: make-initrd



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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-30 19:54             ` Leonid Krivoshein
@ 2021-08-31  7:40               ` Alexey Gladkov
  2021-08-31 22:02                 ` Leonid Krivoshein
  0 siblings, 1 reply; 14+ messages in thread
From: Alexey Gladkov @ 2021-08-31  7:40 UTC (permalink / raw)
  To: make-initrd

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-31  7:40               ` Alexey Gladkov
@ 2021-08-31 22:02                 ` Leonid Krivoshein
  2021-08-31 23:10                   ` Alexey Gladkov
  0 siblings, 1 reply; 14+ messages in thread
From: Leonid Krivoshein @ 2021-08-31 22:02 UTC (permalink / raw)
  To: make-initrd

Привет!


31.08.2021 10:40, Alexey Gladkov пишет:
> 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 у нас вообще нет TTY'ов. Я даже не понял, почему их 
нет. Поэтому логично вызов lock_tty(n) переадресовывать на 
console_lock() при nottys в /proc/cmdline. Ещё лучше, найти способ 
авто-определения netconsole и выставлять внутренне NOTTYS=1, если нет 
TTY'ов даже, если это не указано в /proc/cmdline, но я не нашёл 
надёжного способа такого определения на шеле.



>> [...]
>> API должен быть написан исходя из конкретных потребностей, а не чтобы просто
>> был. Кому и как может потребоваться API для работы с диалогами ввода/вывода?
>> Я исхожу из того, что "пользователи" API -- это фичи make-initrd, это
>> работающий код демонов, вывод которых уже куда-то перенаправлен, например в
>> журнал или на /dev/console. Или это обработчики событий. Вдруг, им
>> недостаточно события, а надо ещё и у пользователя что-то спросить? А может
>> они ждут события, чтобы после него спросить нечто у пользователя? Например,
>> PIN-код на вставленный токен.
> Так уже есть фичи, которые спрашивают пин и они пользуются console_lock.

Возможно, ты имеешь ввиду, что все диалоги должны происходить на одной 
консоли, той же, на которую runtime make-initrd выводит сообщения о 
запускаемых службах. Тогда да, можно не думать об отделении процесса 
через IM_exec(), тогда можно не заботиться о TTY'ах, можно блокировать 
консоль через пару console_lock() и console_unlock(), можно не думать о 
netconsole, так как это она и есть. Я это и имел ввиду под возвратом к 
более простой реализации, побочные эффекты которой -- мелькания диалогов 
вперемешку с выводом runtime. Если твоя концепция работы с TTY'ами будет 
именно такой, значит, под неё и придётся переделывать нынешнюю 
реализацию: #283645.



> [...]
>>> Для синхронизации с kbd можно поступить как с сетью и сделать сервис
>>> kbd-ready, который можно ставить в зависимости других сервисов.
>> А вот тут уже я не понял.))
> На runlevel 3 запускаются сервисы. Чтобы синхронизировать свой запуск с
> асинхронными событиями такими как поднятие сети был сделан псевдосервис
> network-up (он приезжает с фичей network). Сервисы, которым нужна сеть
> ставят его в зависимости и будут запущены после него.
>
> Такую же штуку можно сделать и для настройки терминалов. В этом случае
> можно будет стартовать сервис после того как фича kbd отработает.

Отлично!



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

Если нужно пораньше фичу interactive (pseudo-gui), то вот: #283645. Она 
уже давно оттестирована и не меняется. На днях с ней будут делаться 
регулярки, и тестирование будет иметь более широкий охват на железе. 
Если всё вместе, то уже работаю над этим всё свободное время, благо 
теперь у меня его больше. Для обсуждения концепции работы с TTY'ми можем 
организовать конфколл, Антона Мидикова позвать, надо ведь разные 
архитектуры учесть...


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-31 22:02                 ` Leonid Krivoshein
@ 2021-08-31 23:10                   ` Alexey Gladkov
  2021-09-15 21:19                     ` Leonid Krivoshein
  0 siblings, 1 reply; 14+ messages in thread
From: Alexey Gladkov @ 2021-08-31 23:10 UTC (permalink / raw)
  To: make-initrd

On Wed, Sep 01, 2021 at 01:02:09AM +0300, Leonid Krivoshein wrote:
> > > Любая фича, которая хочет использовать конкретный 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 у нас вообще нет TTY'ов. Я даже не понял, почему их нет.
> Поэтому логично вызов lock_tty(n) переадресовывать на console_lock() при
> nottys в /proc/cmdline. Ещё лучше, найти способ авто-определения netconsole
> и выставлять внутренне NOTTYS=1, если нет TTY'ов даже, если это не указано в
> /proc/cmdline, но я не нашёл надёжного способа такого определения на шеле.

Я не уверен, но если попытаться свести lock_tty к console_lock, то в
некоторых случаях можно будет получить deadlock.

> > > [...]
> > > API должен быть написан исходя из конкретных потребностей, а не чтобы просто
> > > был. Кому и как может потребоваться API для работы с диалогами ввода/вывода?
> > > Я исхожу из того, что "пользователи" API -- это фичи make-initrd, это
> > > работающий код демонов, вывод которых уже куда-то перенаправлен, например в
> > > журнал или на /dev/console. Или это обработчики событий. Вдруг, им
> > > недостаточно события, а надо ещё и у пользователя что-то спросить? А может
> > > они ждут события, чтобы после него спросить нечто у пользователя? Например,
> > > PIN-код на вставленный токен.
> > Так уже есть фичи, которые спрашивают пин и они пользуются console_lock.
> 
> Возможно, ты имеешь ввиду, что все диалоги должны происходить на одной
> консоли, той же, на которую runtime make-initrd выводит сообщения о
> запускаемых службах. Тогда да, можно не думать об отделении процесса через
> IM_exec(), тогда можно не заботиться о TTY'ах, можно блокировать консоль
> через пару console_lock() и console_unlock(), можно не думать о netconsole,
> так как это она и есть. Я это и имел ввиду под возвратом к более простой
> реализации, побочные эффекты которой -- мелькания диалогов вперемешку с
> выводом runtime. Если твоя концепция работы с TTY'ами будет именно такой,
> значит, под неё и придётся переделывать нынешнюю реализацию: #283645.

Я текущая реализация использует /dev/console и console_lock/console_unlock
именно потому, что я не хотел полагаться на локальные tty. У меня нет
тестов, но я всегда старался думать о netconsole.

Совершенно не обязательно иметь мелькание диалогов вперемешку с
сообщениями. Я делал реализацию quiet, которая вроде как работает и не
мешает показывать сплеэш. Основную консоль можно сделать чистой и
перенаправить сообщения в файл или отдельные логи.

По сути я не вижу большой разницы между plymouth и диалогами bootchain.

> > [...]
> > > > Для синхронизации с kbd можно поступить как с сетью и сделать сервис
> > > > kbd-ready, который можно ставить в зависимости других сервисов.
> > > А вот тут уже я не понял.))
> > На runlevel 3 запускаются сервисы. Чтобы синхронизировать свой запуск с
> > асинхронными событиями такими как поднятие сети был сделан псевдосервис
> > network-up (он приезжает с фичей network). Сервисы, которым нужна сеть
> > ставят его в зависимости и будут запущены после него.
> > 
> > Такую же штуку можно сделать и для настройки терминалов. В этом случае
> > можно будет стартовать сервис после того как фича kbd отработает.
> 
> Отлично!

Ок. Тогда так и сделаем.

> > [...]
> > Так. Я понял, что я совсем не в контексте и не могу продуктивно обсуждать,
> > то что не видел. Присылай патчи, мы их обсудим, а потом подумаем, что
> > нужно от остального кода.
> 
> Если нужно пораньше фичу interactive (pseudo-gui), то вот: #283645. Она уже
> давно оттестирована и не меняется. На днях с ней будут делаться регулярки, и
> тестирование будет иметь более широкий охват на железе. Если всё вместе, то
> уже работаю над этим всё свободное время, благо теперь у меня его больше.
> Для обсуждения концепции работы с TTY'ми можем организовать конфколл, Антона
> Мидикова позвать, надо ведь разные архитектуры учесть...

Я только за. Пишите, когда у вас есть время и сможем организоваться.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [make-initrd] bootchain+altboot: у меня есть план
  2021-08-31 23:10                   ` Alexey Gladkov
@ 2021-09-15 21:19                     ` Leonid Krivoshein
  0 siblings, 0 replies; 14+ messages in thread
From: Leonid Krivoshein @ 2021-09-15 21:19 UTC (permalink / raw)
  To: make-initrd

Привет!


01.09.2021 2:10, Alexey Gladkov пишет:
>> Если нужно пораньше фичу interactive (pseudo-gui), то вот: #283645. Она уже
>> давно оттестирована и не меняется. На днях с ней будут делаться регулярки, и
>> тестирование будет иметь более широкий охват на железе. Если всё вместе, то
>> уже работаю над этим всё свободное время, благо теперь у меня его больше.
>> Для обсуждения концепции работы с TTY'ми можем организовать конфколл, Антона
>> Мидикова позвать, надо ведь разные архитектуры учесть...
> Я только за. Пишите, когда у вас есть время и сможем организоваться.

Всё это время мы работали над тестированием и прилаживанием к m-p новой 
загрузки. Регулярки уже собираются с altboot. Основное всё работало 
ожидаемым образом, исправлялись какие-то мелочи для специфичных кейсов. 
Но вот сейчас удалось выявить два существенных бага, из-за которых мне 
придётся существенно переработать уже сделанное. ((

1. Проверка установщика на методах HTTP и FTP выявила тот факт, что я 
неправильно их реализовал, нужно грузить сквош, а не ISO'шник целиком.
2. Мы все надеялись обойтись пока без диалогов для настройки сети, 
обойтись имеющейся фичей network для поднятия сети. Оказалось, не 
получится. Если без диалогов ещё можно как-то пережить, то без 
переменных окружения, на которые ориентируется инсталлятор, не 
получится. Он смотрит метод загрузки и ищет переменные типа DNS_SERVER, 
DNS_SERVER2, DOMAINNAME, BOOTPROTO, IPADDR, NETMASK, NETWORK, BROADCAST, 
NETBITS, GATEWAY -- может и не все, но пропагатор их тоже экспортировал.

Так что мне ещё придётся делать перемычку между фичей network и altboot 
для обеспечения слоя совместимости со stage2, а также исправлять шаг 
download.

Кроме того, я вроде как нашёл способ и даже во многом реализовал 
возможность закрыть всё авто-тестами.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-09-15 21:19 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-21 19:14 [make-initrd] bootchain+altboot: у меня есть план Leonid Krivoshein
2021-08-22 19:29 ` Leonid Krivoshein
2021-08-23  9:29 ` Alexey Gladkov
2021-08-23 11:04   ` Leonid Krivoshein
2021-08-23 11:48     ` Alexey Gladkov
2021-08-24  1:16       ` Leonid Krivoshein
2021-08-30 17:14         ` Leonid Krivoshein
2021-08-30 18:13           ` Alexey Gladkov
2021-08-30 19:54             ` Leonid Krivoshein
2021-08-31  7:40               ` Alexey Gladkov
2021-08-31 22:02                 ` Leonid Krivoshein
2021-08-31 23:10                   ` Alexey Gladkov
2021-09-15 21:19                     ` Leonid Krivoshein
2021-08-23 11:19   ` Leonid Krivoshein

Make-initrd development discussion

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \
		make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com
	public-inbox-index make-initrd

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.make-initrd


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git