Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Michael Shigorin]

On Wed, Apr 25, 2018 at 02:12:31PM +0200, Alexey Gladkov wrote:
> > > > На вчерашнее совещание я не попал, но на том, что было две
> > > > недели назад, говорили о пропагаторе в том же ключе. Вопрос
> > > > острый, хотим решить до P9.
> > > Когда будет P9 ?
> > По прикидкам -- летом.
> К этому сроку нормально переделать propagator получится разве
> что при наличии активной помощи.

Давайте ещё arseny@ к переписке подключим.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

Добрый день!


25.04.2018 18:44, Michael Shigorin пишет:
> On Wed, Apr 25, 2018 at 02:12:31PM +0200, Alexey Gladkov wrote:
>>>>> На вчерашнее совещание я не попал, но на том, что было две
>>>>> недели назад, говорили о пропагаторе в том же ключе. Вопрос
>>>>> острый, хотим решить до P9.
>>>> Когда будет P9 ?

Мне кажется, точных сроков никто не сможет сейчас назвать, даже aen@. Но 
мне эта информация недоступна тем более. Раз на собрании решили, что P9 
выйдет без пропагатаора, значит как минимум P9 не будет до тех пор, пока 
не будет liveboot! :)

>>> По прикидкам -- летом.
>> К этому сроку нормально переделать propagator получится разве
>> что при наличии активной помощи.

Меня на ближайший месяц очень экстренно запрягают разработкой деплоя. 
Если прошедшие дни дадут плоды, после этого ещё и в рабство как минимум 
на месяц в одно ведомство отправят. Будет очень сложно в таких условиях 
держать обещание. Но, поскольку цели смежные, можем работать в контакте, 
делать разные части. Отличия от деплоя небольшие. Могу выделить время и 
заранее нарисовать все диалоги пропагатора на скриптах, только мне 
кажется это лучше делать через ncursesw/dialog, а не newt/whiptail.

> Давайте ещё arseny@ к переписке подключим.
>

Только ЗА! Давно пора...


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov]

On Wed, Apr 25, 2018 at 11:45:03PM +0300, Leonid Krivoshein wrote:
> >>> По прикидкам -- летом.
> >> К этому сроку нормально переделать propagator получится разве
> >> что при наличии активной помощи.
> 
> Меня на ближайший месяц очень экстренно запрягают разработкой деплоя. 
> Если прошедшие дни дадут плоды, после этого ещё и в рабство как минимум 
> на месяц в одно ведомство отправят. Будет очень сложно в таких условиях 
> держать обещание. Но, поскольку цели смежные, можем работать в контакте, 
> делать разные части. Отличия от деплоя небольшие. Могу выделить время и 
> заранее нарисовать все диалоги пропагатора на скриптах, только мне 
> кажется это лучше делать через ncursesw/dialog, а не newt/whiptail.

Не-не-не. Это безусловно полезная вещь, но диалоги будут нужны потом. Я
говорил совсем о другой помощи.

> > Давайте ещё arseny@ к переписке подключим.
> >
> 
> Только ЗА! Давно пора...

Эм... Я не знаю этого человека. Но раз вы так подчёркиваете его участие,
то отнесусь к этому с сдержанным оптимизмом ))

-- 
Rgrds, legion

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

26.04.2018 11:35, Alexey Gladkov пишет:
> On Wed, Apr 25, 2018 at 11:45:03PM +0300, Leonid Krivoshein wrote:
>>>>> По прикидкам -- летом.
>>>> К этому сроку нормально переделать propagator получится разве
>>>> что при наличии активной помощи.
>> Меня на ближайший месяц очень экстренно запрягают разработкой деплоя.
>> Если прошедшие дни дадут плоды, после этого ещё и в рабство как минимум
>> на месяц в одно ведомство отправят. Будет очень сложно в таких условиях
>> держать обещание. Но, поскольку цели смежные, можем работать в контакте,
>> делать разные части. Отличия от деплоя небольшие. Могу выделить время и
>> заранее нарисовать все диалоги пропагатора на скриптах, только мне
>> кажется это лучше делать через ncursesw/dialog, а не newt/whiptail.
> Не-не-не. Это безусловно полезная вещь, но диалоги будут нужны потом. Я
> говорил совсем о другой помощи.


Говорили? Пока пытаюсь угадывать между строк. :) Вопрос востребованности 
liveboot и замены им пропагатора устаканили заблаговременно. А какого 
рода помощь тогда может ещё потребоваться? Ревью? Тестирование-обкатка? 
В любом случае две головы лучше, а шесть рук лучше втройне!


>
>>> Давайте ещё arseny@ к переписке подключим.
>>>
>> Только ЗА! Давно пора...
> Эм... Я не знаю этого человека. Но раз вы так подчёркиваете его участие,
> то отнесусь к этому с сдержанным оптимизмом ))

Арсений проявлял интерес к замене пропагатора скриптами. Им на ВМК МГУ с 
большой сетью он тоже покоя не даёт.))


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov]

[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

On Thu, Apr 26, 2018 at 12:04:58PM +0300, Leonid Krivoshein wrote:
> >> Меня на ближайший месяц очень экстренно запрягают разработкой деплоя.
> >> Если прошедшие дни дадут плоды, после этого ещё и в рабство как минимум
> >> на месяц в одно ведомство отправят. Будет очень сложно в таких условиях
> >> держать обещание. Но, поскольку цели смежные, можем работать в контакте,
> >> делать разные части. Отличия от деплоя небольшие. Могу выделить время и
> >> заранее нарисовать все диалоги пропагатора на скриптах, только мне
> >> кажется это лучше делать через ncursesw/dialog, а не newt/whiptail.
> > Не-не-не. Это безусловно полезная вещь, но диалоги будут нужны потом. Я
> > говорил совсем о другой помощи.
> 
> 
> Говорили? Пока пытаюсь угадывать между строк. :) Вопрос востребованности 
> liveboot и замены им пропагатора устаканили заблаговременно. А какого 
> рода помощь тогда может ещё потребоваться? Ревью? Тестирование-обкатка? 
> В любом случае две головы лучше, а шесть рук лучше втройне!

Мне нужна помощь в написании грамотных фичей. Сейчас мне нужна фича
настройки сети так как в make-initrd она ооочень условная и сделана через
утилиту ipconfig из klibc, которая, скажем так, очень стабильная.

Я разговаривал ldv, glebfm, wladmis и пришёл к выводу, что стоит
использовать etcnet в образе. Так что, нужно написать фичу для этого, плюс
придумать настройку в рантайме, плюс конвертер параметра `ip=` в
конфигурацию etcnet. Также нужно посмотреть etcnet на предмет его работы с
утилитами busybox и возможность использования в нём udhcp.

Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько
востребован функционал с nfs. Если востребован, то это будет ещё один
пласт работ.

Также я занимаюсь анализом init-bottom перед похоронами этого скрипта.

> >>> Давайте ещё arseny@ к переписке подключим.
> >>>
> >> Только ЗА! Давно пора...
> > Эм... Я не знаю этого человека. Но раз вы так подчёркиваете его участие,
> > то отнесусь к этому с сдержанным оптимизмом ))
> 
> Арсений проявлял интерес к замене пропагатора скриптами. Им на ВМК МГУ с 
> большой сетью он тоже покоя не даёт.))

Тогда добро пожаловать на борт! ))

-- 
Rgrds, agladkov


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov]

[-- Attachment #1: Type: text/plain, Size: 3691 bytes --]

On Thu, Apr 26, 2018 at 12:04:58PM +0300, Leonid Krivoshein wrote:
> >> Меня на ближайший месяц очень экстренно запрягают разработкой деплоя.
> >> Если прошедшие дни дадут плоды, после этого ещё и в рабство как минимум
> >> на месяц в одно ведомство отправят. Будет очень сложно в таких условиях
> >> держать обещание. Но, поскольку цели смежные, можем работать в контакте,
> >> делать разные части. Отличия от деплоя небольшие. Могу выделить время и
> >> заранее нарисовать все диалоги пропагатора на скриптах, только мне
> >> кажется это лучше делать через ncursesw/dialog, а не newt/whiptail.
> > Не-не-не. Это безусловно полезная вещь, но диалоги будут нужны потом. Я
> > говорил совсем о другой помощи.
> 
> 
> Говорили? Пока пытаюсь угадывать между строк. :) Вопрос востребованности 
> liveboot и замены им пропагатора устаканили заблаговременно. А какого 
> рода помощь тогда может ещё потребоваться? Ревью? Тестирование-обкатка? 
> В любом случае две головы лучше, а шесть рук лучше втройне!

Мне нужна помощь в написании грамотных фичей. Сейчас мне нужна фича
настройки сети так как в make-initrd она ооочень условная и сделана через
утилиту ipconfig из klibc, которая, скажем так, очень стабильная.

Я разговаривал ldv, glebfm, wladmis и пришёл к выводу, что стоит
использовать etcnet в образе. Так что, нужно написать фичу для этого, плюс
придумать настройку в рантайме, плюс конвертер параметра `ip=` в
конфигурацию etcnet. Также нужно посмотреть etcnet на предмет его работы с
утилитами busybox и возможность использования в нём udhcp.

Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько
востребован функционал с nfs. Если востребован, то это будет ещё один
пласт работ.

Также я занимаюсь анализом init-bottom перед похоронами этого скрипта.

> >>> Давайте ещё arseny@ к переписке подключим.
> >>>
> >> Только ЗА! Давно пора...
> > Эм... Я не знаю этого человека. Но раз вы так подчёркиваете его участие,
> > то отнесусь к этому с сдержанным оптимизмом ))
> 
> Арсений проявлял интерес к замене пропагатора скриптами. Им на ВМК МГУ с 
> большой сетью он тоже покоя не даёт.))

Тогда добро пожаловать на борт! ))

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

26.04.2018 13:21, Alexey Gladkov пишет:
> Мне нужна помощь в написании грамотных фичей. Сейчас мне нужна фича
> настройки сети так как в make-initrd она ооочень условная и сделана через
> утилиту ipconfig из klibc, которая, скажем так, очень стабильная.

Уже говорил, что пока более-менее я осилил make-initrd только из p8, 
надеюсь по фичам там нет больших отличий в v2+? Мне по-любому придётся 
разбираться с сетью, так что можно будет отталкиваться от моего 
чернового варианта, сделанного под задачи деплоя на скорую руку. Но на 
грамотную чистовую реализацию в виде конечной фичи пока не претендую. 
Если правильно понял, ipconfig лучше не использовать. Согласен, потому 
что лучше ip из пакета iproute2 -- его одного хватит для всех задач.


> Я разговаривал ldv, glebfm, wladmis и пришёл к выводу, что стоит
> использовать etcnet в образе.

Тоже об этом думал. Чтобы не изобретать велосипед, для более сложных 
случаев, конечно, можно. Но у нас ни один пакет с таким названием, а как 
минимум четыре.

> Так что, нужно написать фичу для этого, плюс
> придумать настройку в рантайме, плюс конвертер параметра `ip=` в
> конфигурацию etcnet.

Видел готовые реализации в Gentoo. Правда, не под etcnet, но диалоги 
готовые. Может получится перетащить что-то из этого. См.: 
http://www.reactivated.net/weblog/archives/2006/06/net-setup-enhancements/ 
. Стоит сразу определиться: сетевая загрузка корня с NFS/FTP/HTTP 
возможна даже по вай-фаю, но PXE-загрузка ядра и initrd по вай-фаю 
невозможна, если не ошибаюсь. Исходя из этого стоит ли тащить в liveboot 
поддержку Wi-Fi? Что касается параметров ip=... и nfsroot=... -- тут я 
убеждён в обратном. Их нельзя как-либо использовать в initrd, потому что 
они предназначены для самого ядра и, если эти параметры указаны, ядро 
само их парсит и начинает поднимать сеть, искать и пытаться монтировать 
корень, итд... В случае успеха, до запуска initrd дело вообще не должно 
дойти. Однако наше ядро собирается без DHCP- и NFS- клиентов, как я 
полагаю, и поэтому мы можем видеть очень длительную задержку во время 
запуска и загрузки ядра с любым из этих параметров и с нулевым эффектом 
на выходе. По этой причине я бы не стал использовать в initrd параметры 
загрузки с такими названиями. Меня удивило их наличие в скриптах 
make-initrd после прочтения документации и проверки методом научного 
тыка. Поправьте, если ошибаюсь. Кроме того, я бы предложил использовать 
ещё один механизм для передачи параметров -- через соответствующий 
конфиг. Например, как это сделано тут: 
http://git.altlinux.org/people/klark/packages/deploy-project.git?p=deploy-project.git;a=blob;f=stage1/etc/deploy.conf 
-- просто, чтобы была возможность не только системных умолчаний, но и 
сборочных (при сборке образа initrd), чтобы не тащить большой список 
параметров в kernel cmdline.


> Также нужно посмотреть etcnet на предмет его работы с
> утилитами busybox и возможность использования в нём udhcp.

Вот в этом мне видится большое противоречие. Для простых случаев 
достаточно ручного парсинга и утилиты ip, потому что etcnet много чего 
за собой потянет, особенно etcnet-full.


> Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько
> востребован функционал с nfs. Если востребован, то это будет ещё один
> пласт работ.

С ним не всё хорошо и толком разобраться пока не получилось. Удалось 
лишь добиться, чтобы хоть как-то по нему грузилось. При этом я могу 
видеть сегфолты в ядре на стороне сервера. Вообще не уверен, что 
nfsmount стоит использовать, хотя видел, что к ней вернулись из-за 
проблем с mount.nfs/mount.nfs4. Но у меня в скриптах сейчас со вторыми 
проблем меньше, propagator же умеет только nfsmount. Видимо придётся 
делить на NFSv3 и NFSv4, и разбираться с каждым по отдельности.


> Также я занимаюсь анализом init-bottom перед похоронами этого скрипта.

Про преемственность я уже говорил. Стоит позаботиться о полном 
сохранении совместимости для простоты перехода с пропагатора на 
liveboot, вплоть до полной поддержки его kernel cmdline. Иначе переход 
на liveboot будет сильно затруднён необходимостью правки неведанного 
числа пакетов, типа alterator-netinst и задача превратится в нерешаемую.


* * *


Подытожу. Возможности заняться написанием конкретной фичи в нужном 
формате в чистовом варианте в ближайший месяц-два у меня точно не будет. 
По основной работе буду заниматься схожими боданиями с начальной 
загрузкой по сети, и эти наработки как черновой материал можно будет 
потом подтащить в make-initrd. Особенно, если они пройдут обкатку в 
предполагаемом развёртывании на тысячах машин. Разница только в том, что 
мне нужно сделать хоть как-то по быстрому, чтобы заработало, и в том, 
что на сетевом ресурсе я ищу не корень stage2, а директорию с файлами, 
что почти на 95% перекрывает решаемую задачу, если не считать диалогов 
пропагатора.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

26.04.2018 13:21, Alexey Gladkov пишет:
>> Арсений проявлял интерес к замене пропагатора скриптами. Им на ВМК МГУ с
>> большой сетью он тоже покоя не даёт.))
> Тогда добро пожаловать на борт! ))

Только сегодня от Георгия Курячего узнал, что Арсений приболел и к тому 
же готовится к большому экзамену, видимо потому и молчит -- сейчас ему 
не до нас...


* * *


Ещё пару слов о пропагаторе с Вашим кодом из make-initrd. В виртуалках 
QEMU и VirtualBox загрузка не сломалась, напротив, сеть теперь 
находится. С тем же эффектом мы проверили его на дюжине машин, найдя 
одну проблемную, где старый пропагатор запнулся с поиском флэшки, а 
новый нет. Ещё на одной машине по сети удалось загрузиться, даже 
несмотря на очень необычную ситуацию, когда сеть не пойми как работает, 
DHCP-сервер в железной CISCO, PXE-сервер в виртуалке VMware, а сетевая 
карта болтается соплёй от USB.

Тем не менее, к старому коду вопросы есть. Во-первых, судя по 
документации, udevadm control --reload-rules (теперь вроде так это 
называется) делать после запуска демона udevd необязательно. Во-вторых, 
сейчас задержка на поиск сетевой карты получилась 15 секунд (итераций), 
тогда как для CD-ROM/флэшек она составляет фактически 32+15 секунд 
(итераций) -- несправедливо! В-третьих, самый непонятный для меня вопрос 
с udevadm settle --timeout=5. Получается, мы просим его подождать 
появления железа с 5-секундным таймаутом и ждём после этого ещё 1 
секунду. Я так понимаю, чтобы отработали скрипты/правила udev'а после 
нахождения этого железа. Но сейчас мы чётко видим по-секундный временной 
отсчёт и получается, что типовая флэшка обнаруживается примерно на 6-7 
секунде (итерации), т.е. никаких 6 секунд на итерацию не уходит, как 
будто вызов udevadm settle происходит за 0 секунд. Вот это мне не очень 
понятно, почему же тогда только на 6-7 секунде и почему не срабатывает 
--timeout=5? В отличии от пропагатора, в make-initrd задержка стоит в 
1/10 секунды в бесконечном цикле с общим ограничением по времени. Но в 
целом, получается, что Ваш код более рабочий, а я не очень хорошо знаю 
udev, если честно...


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov]

On Thu, Apr 26, 2018 at 11:24:04PM +0300, Leonid Krivoshein wrote:
> 
> 26.04.2018 13:21, Alexey Gladkov пишет:
> > Мне нужна помощь в написании грамотных фичей. Сейчас мне нужна фича
> > настройки сети так как в make-initrd она ооочень условная и сделана через
> > утилиту ipconfig из klibc, которая, скажем так, очень стабильная.
> 
> Уже говорил, что пока более-менее я осилил make-initrd только из p8, 
> надеюсь по фичам там нет больших отличий в v2+?

Концептуально нет. В остальном есть.

> Мне по-любому придётся 
> разбираться с сетью, так что можно будет отталкиваться от моего 
> чернового варианта, сделанного под задачи деплоя на скорую руку. Но на 
> грамотную чистовую реализацию в виде конечной фичи пока не претендую. 
> Если правильно понял, ipconfig лучше не использовать. Согласен, потому 
> что лучше ip из пакета iproute2 -- его одного хватит для всех задач.

Я не хочу реализовывать свою систему управления сетью.

> > Я разговаривал ldv, glebfm, wladmis и пришёл к выводу, что стоит
> > использовать etcnet в образе.
> 
> Тоже об этом думал. Чтобы не изобретать велосипед, для более сложных 
> случаев, конечно, можно. Но у нас ни один пакет с таким названием, а как 
> минимум четыре.

Вы, видимо, не разбирались с ним. Скрипты там одни.

> > Так что, нужно написать фичу для этого, плюс
> > придумать настройку в рантайме, плюс конвертер параметра `ip=` в
> > конфигурацию etcnet.
> 
> Видел готовые реализации в Gentoo. Правда, не под etcnet, но диалоги 
> готовые. Может получится перетащить что-то из этого. См.: 
> http://www.reactivated.net/weblog/archives/2006/06/net-setup-enhancements/ 

Это диалоги для настройки сети. Если их нельзя взять "как есть", то их
придётся дорабатывать под систему конфигурации сети и как следствие
придётся взять эту подсистему из gentoo. Если её нельзя использовать
отдельно от gentoo (а скорее всего так и есть), это будет форк, а я не
хочу разрабатывать свою систему управления сетью.

> . Стоит сразу определиться: сетевая загрузка корня с NFS/FTP/HTTP 
> возможна даже по вай-фаю, но PXE-загрузка ядра и initrd по вай-фаю 
> невозможна, если не ошибаюсь. Исходя из этого стоит ли тащить в liveboot 
> поддержку Wi-Fi?

Нужно сделать так, чтобы была возможность расширения функционала. Даже
если сейчас это не нужно, то уверен, что рано или поздно появится некто,
хотящий корень по HTTPS-over-Wifi.

> Что касается параметров ip=... и nfsroot=... -- тут я 
> убеждён в обратном. Их нельзя как-либо использовать в initrd, потому что 
> они предназначены для самого ядра и, если эти параметры указаны, ядро 
> само их парсит и начинает поднимать сеть, искать и пытаться монтировать 
> корень, итд...

Вы неправы. Это _уже_ используется и используется это очень давно.
Поддержка этих параметров есть и она должна сохраниться для обратной
совместимости.

В качестве троллического отступления хочу напомнить, что параметр root=
тоже разбирается ядром.

> В случае успеха, до запуска initrd дело вообще не должно 
> дойти. Однако наше ядро собирается без DHCP- и NFS- клиентов, как я 
> полагаю, и поэтому мы можем видеть очень длительную задержку во время 
> запуска и загрузки ядра с любым из этих параметров и с нулевым эффектом 
> на выходе. По этой причине я бы не стал использовать в initrd параметры 
> загрузки с такими названиями. Меня удивило их наличие в скриптах 
> make-initrd после прочтения документации и проверки методом научного 
> тыка. Поправьте, если ошибаюсь.

Повторюсь, это очень старые параметры. Proof:

http://git.altlinux.org/gears/m/mkinitrd.git?p=mkinitrd.git;a=blob;f=init.sh#l82
http://git.altlinux.org/gears/m/mkinitrd.git?p=mkinitrd.git;a=blob;f=init.sh#l94

> Кроме того, я бы предложил использовать 
> ещё один механизм для передачи параметров -- через соответствующий 
> конфиг. Например, как это сделано тут: 
> http://git.altlinux.org/people/klark/packages/deploy-project.git?p=deploy-project.git;a=blob;f=stage1/etc/deploy.conf 
> -- просто, чтобы была возможность не только системных умолчаний, но и 
> сборочных (при сборке образа initrd), чтобы не тащить большой список 
> параметров в kernel cmdline.

Да, это правильно. Такой механизм уже используется в makе-initrd для
корня.

> > Также нужно посмотреть etcnet на предмет его работы с
> > утилитами busybox и возможность использования в нём udhcp.
> 
> Вот в этом мне видится большое противоречие. Для простых случаев 
> достаточно ручного парсинга и утилиты ip, потому что etcnet много чего 
> за собой потянет, особенно etcnet-full.

Он модульный. В идеале я хотел бы, чтобы фича etcnet была не монолитной.

> > Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько
> > востребован функционал с nfs. Если востребован, то это будет ещё один
> > пласт работ.
> 
> С ним не всё хорошо и толком разобраться пока не получилось. Удалось 
> лишь добиться, чтобы хоть как-то по нему грузилось. При этом я могу 
> видеть сегфолты в ядре на стороне сервера. Вообще не уверен, что 
> nfsmount стоит использовать, хотя видел, что к ней вернулись из-за 
> проблем с mount.nfs/mount.nfs4. Но у меня в скриптах сейчас со вторыми 
> проблем меньше, propagator же умеет только nfsmount. Видимо придётся 
> делить на NFSv3 и NFSv4, и разбираться с каждым по отдельности.

Вот поэтому вопрос открыт ))

> > Также я занимаюсь анализом init-bottom перед похоронами этого скрипта.
> 
> Про преемственность я уже говорил. Стоит позаботиться о полном 
> сохранении совместимости 

О какой совместимости вы говорите ? О параметрах cmdline ? Они разумеется
останутся как были.

> Подытожу. Возможности заняться написанием конкретной фичи в нужном 
> формате в чистовом варианте в ближайший месяц-два у меня точно не будет. 

Я собственно не настаиваю. Я просто поставил всех заинтересованных в
известность о том, что нужно, чтобы "успеть к P9". А дальше решайте сами.
Мне некуда торопиться и я буду реализовывать, что задумал чтобы в
make-initrd появился функционал аналогичный propagator. Когда такой
функционал появится, тогда можно будет закопать propagator. Если у меня на
его реализацию уйдёт год, то значит через год его можно будет закопать.

> По основной работе буду заниматься схожими боданиями с начальной 
> загрузкой по сети, и эти наработки как черновой материал можно будет 
> потом подтащить в make-initrd.

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

Кроме того, мне некуда торопиться. Есть время для нормального
проектирования.

-- 
Rgrds, legion

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

27.04.2018 02:11, Alexey Gladkov пишет:
>> Тем не менее, к старому коду вопросы есть.
> make-initrd-0.8.x ?

В основном, да, но отдельные моменты касались старого кода в 
пропагаторе. Имел ввиду, что Ваш код я перетащил сюда:

http://git.altlinux.org/people/klark/packages/propagator.git?p=propagator.git;a=blob;f=udev.c#l89

И это очень помогло, да!


>> Во-первых, судя по документации, udevadm control --reload-rules (теперь
>> вроде так это называется) делать после запуска демона udevd
>> необязательно.
> Ну нужно. А кто его делает ?

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/lib/initrd/modules/050-udev;h=87c6f129dceaa56a6e59948b82fb9d592c964b64;hb=cf8fa26df84bf8d845c4df6df4aa86df24c7372d

udevadm control --reload >/dev/null 2>&1 ||:

Я поменял на --reload-rules, так как просто --reload больше нет.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov]

On Fri, Apr 27, 2018 at 12:26:09AM +0300, Leonid Krivoshein wrote:
> Ещё пару слов о пропагаторе с Вашим кодом из make-initrd. В виртуалках 
> QEMU и VirtualBox загрузка не сломалась, напротив, сеть теперь 
> находится.

Рад слышать.

> С тем же эффектом мы проверили его на дюжине машин, найдя 
> одну проблемную, где старый пропагатор запнулся с поиском флэшки, а 
> новый нет. Ещё на одной машине по сети удалось загрузиться, даже 
> несмотря на очень необычную ситуацию, когда сеть не пойми как работает, 
> DHCP-сервер в железной CISCO, PXE-сервер в виртуалке VMware, а сетевая 
> карта болтается соплёй от USB.

Скорее всего это из-за того, что ipconfig использует очень старый dhcp,
который руками разбирается.

> Тем не менее, к старому коду вопросы есть.

make-initrd-0.8.x ?

> Во-первых, судя по документации, udevadm control --reload-rules (теперь
> вроде так это называется) делать после запуска демона udevd
> необязательно.

Ну нужно. А кто его делает ?

> Во-вторых, сейчас задержка на поиск сетевой карты получилась 15 секунд
> (итераций), тогда как для CD-ROM/флэшек она составляет фактически 32+15
> секунд (итераций) -- несправедливо!

Я не считал итерации. Возможно.

> В-третьих, самый непонятный для меня вопрос 
> с udevadm settle --timeout=5. Получается, мы просим его подождать 
> появления железа с 5-секундным таймаутом

Этот таймаут на очередь, чтобы не ждать слишком долго.

> Я так понимаю, чтобы отработали скрипты/правила udev'а после 
> нахождения этого железа.

Нет. Это просто ожидание инициализации железа после загрузки модуля ядра.
Если всё проинициализируется раньше, то `udevadm settle` выйдет раньше
таймаута.

> В отличии от пропагатора, в make-initrd задержка стоит в 
> 1/10 секунды в бесконечном цикле с общим ограничением по времени. Но в 
> целом, получается, что Ваш код более рабочий, а я не очень хорошо знаю 
> udev, если честно...

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

Остальной код реагирует на определённые эвенты. Но мы не знаем, когда
появятся условия для монтирования корня. Поэтому там бесконечный цикл.

-- 
Rgrds, legion

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

Тогда предлагаю опустить пока технические детали и определиться с основным:


27.04.2018 01:28, Alexey Gladkov пишет:
> On Thu, Apr 26, 2018 at 11:24:04PM +0300, Leonid Krivoshein wrote:
>> Подытожу. Возможности заняться написанием конкретной фичи в нужном
>> формате в чистовом варианте в ближайший месяц-два у меня точно не будет.
> Я собственно не настаиваю. Я просто поставил всех заинтересованных в
> известность о том, что нужно, чтобы "успеть к P9". А дальше решайте сами.
> Мне некуда торопиться и я буду реализовывать, что задумал чтобы в
> make-initrd появился функционал аналогичный propagator. Когда такой
> функционал появится, тогда можно будет закопать propagator. Если у меня на
> его реализацию уйдёт год, то значит через год его можно будет закопать.
>
>> По основной работе буду заниматься схожими боданиями с начальной
>> загрузкой по сети, и эти наработки как черновой материал можно будет
>> потом подтащить в make-initrd.
> При всём уважении я не приму код, который решает какую-то частную задачу.
> Этот подход был использован при разработке propagator. Он весь состоит из
> решений частных задач.
>
> Кроме того, мне некуда торопиться. Есть время для нормального
> проектирования.

Мне тоже нравится писать большие, правильные и качественные вещи. К 
сожалению, текущая ситуация заставляет сделать нечто близкое и даже 
больший объём работ в течении всего одного месяца. При этом, 
действительно решая частную задачу. Это можно и нужно использовать. 
Чтобы сделать хорошо и правильно, порою приходится сначала делать 
черновой вариант. Написать хоть что-то, чтобы понять, как оно работает. 
Тогда уже приходят в голову мысли об оптимизации, систематизации, 
идеологической красоте и правильности. Другими словами, проектирование 
начинается после "разведки боем". Возможно, я просто "неправильный 
программист" и живу вопреки правил о циклах разработки. :)

Не предлагаю принимать в make-initrd-liveboot конкретный код, но 
вымученный последующим внедрением на тысячах железок опыт вполне можно 
учесть при проектировании. Это всё что, что я пока могу предложить. Не 
исключено, что к этой задаче я смогу подключиться плотнее позже, но 
обещать и загадывать заранее сейчас не хотелось бы...


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov]

On Fri, Apr 27, 2018 at 11:31:47PM +0300, Leonid Krivoshein wrote:
> Тогда предлагаю опустить пока технические детали и определиться с основным:
> 
> 
> 27.04.2018 01:28, Alexey Gladkov пишет:
> > On Thu, Apr 26, 2018 at 11:24:04PM +0300, Leonid Krivoshein wrote:
> >> Подытожу. Возможности заняться написанием конкретной фичи в нужном
> >> формате в чистовом варианте в ближайший месяц-два у меня точно не будет.
> > Я собственно не настаиваю. Я просто поставил всех заинтересованных в
> > известность о том, что нужно, чтобы "успеть к P9". А дальше решайте сами.
> > Мне некуда торопиться и я буду реализовывать, что задумал чтобы в
> > make-initrd появился функционал аналогичный propagator. Когда такой
> > функционал появится, тогда можно будет закопать propagator. Если у меня на
> > его реализацию уйдёт год, то значит через год его можно будет закопать.
> >
> >> По основной работе буду заниматься схожими боданиями с начальной
> >> загрузкой по сети, и эти наработки как черновой материал можно будет
> >> потом подтащить в make-initrd.
> > При всём уважении я не приму код, который решает какую-то частную задачу.
> > Этот подход был использован при разработке propagator. Он весь состоит из
> > решений частных задач.
> >
> > Кроме того, мне некуда торопиться. Есть время для нормального
> > проектирования.
> 
> Мне тоже нравится писать большие, правильные и качественные вещи. К 
> сожалению, текущая ситуация заставляет сделать нечто близкое и даже 
> больший объём работ в течении всего одного месяца. При этом, 
> действительно решая частную задачу. Это можно и нужно использовать. 
> Чтобы сделать хорошо и правильно, порою приходится сначала делать 
> черновой вариант. Написать хоть что-то, чтобы понять, как оно работает. 
> Тогда уже приходят в голову мысли об оптимизации, систематизации, 
> идеологической красоте и правильности. Другими словами, проектирование 
> начинается после "разведки боем". Возможно, я просто "неправильный 
> программист" и живу вопреки правил о циклах разработки. :)

То о чём говорил я это не циклы разработки. Я долгое время занимаюсь
разработкой софта. У меня были проекты проприоритарных сервисов, открытых
сервисов, закрытых и открытых "коробочных" решения для заказчиков. И то,
что я знаю из опыта, это то что непродуманные наколеночные решения
помогают достичь цели в краткосрочной перспективе, но потом это очень
больно аукается... вплоть до потери клиента. Поверьте, я не собираюсь вас
учить делать дела. Вы можете решать ваши задачи так как вы считаете
нужным, но не надо мне рассказывать про тысячи железок.

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

Сизиф (другие репозитории я не поддерживаю по определённым причинам) не
такой проект, где цель внедрения фичи прямо сейчас важнее всего.

> Не предлагаю принимать в make-initrd-liveboot конкретный код,

Вы можете сделать такой пакет в любой удобный для решения вашей задачи
момент. Это не первая фича, которая к мне не будет иметь отношения. Я не
буду вас останавливать ))

То что делаю сейчас я, делается в make-initrd. Именно в нём не хватает
гибкости в определённых местах.

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

Я понимаю и ни в коем случае ничего не прошу. У всех свои задачи.

-- 
Rgrds, legion

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Leonid Krivoshein]

Приветствую!


02.05.2018 23:40, Alexey Gladkov пишет:
> Привет!
>
> Я поговорил тут с lioka насчёт make-initrd, mkinitrd, etcnet и propagator.
> И внезапно выяснилось, что ни о каких планах на счёт propagator и
> make-initrd он не знает и более того, он считает, что он не нужен с всеми
> его squashfs/aufs. Он очень всему этому удивлялся и желал мне удачи.
>
> Похоже на "вчерашнее совещание" не попали не только вы, а целесообразность
> этих работ не так уж очевидно "всем". Кажется всё опять как всегда.

1) Если речь о Большакове, он действительно не в Москве. В Обнинске 
Антон Фарыгин просил о том же.
2) В курсе всех технических деталей только те, кто в копии этого письма.
3) В курсе планов по смене пропагатора на make-initrd-liveboot только 
те, кто подписан на devel@. Если там кто и не читает большие письма, по 
крайне мере, это сообщение просто не могли пропустить: 
https://lists.altlinux.org/pipermail/devel/2018-April/204307.html
4) Возможно к Вам (к нам) присоединится Михаил Кангин, который делал 
make-initrd-colaboot. Имел с ним большую переписку. Пока не уверен, что 
от него можно ожидать помощи, но его планы во многом перекликаются с нашими.
5) squashfs+aufs, в принципе, достаточны в том месте, где они сейчас 
используются, хотя есть сомнения относительно актуальности/поддержки 
aufs. Но наши разработчики про overlayfs высказывались скептически ещё 
несколько месяцев назад. Михаил Кангин как раз её активно использует и 
проблем не наблюдает. Про аналог в Debian/Ubuntu я уже упоминал -- 
overlayroot.


> On Wed, Apr 25, 2018 at 07:40:00AM +0300, Leonid Krivoshein wrote:
>> Алексей, добрый день!
>>
>>
>> На вчерашнее совещание я не попал, но на том, что было две недели назад,
>> говорили о пропагаторе в том же ключе. Вопрос острый, хотим решить до
>> P9. Из тех, кого нет в Москве, Антон Фарыгин просил Вас о том же в
>> багзилле. По слухам, на вчерашнем совещании решили ещё и mkinitrd
>> выкинуть, Глеб говорит, что он уже 10 лет, как не используется. Мне,
>> поскольку надо ехать быстро и сейчас, пришлось чинить пропагатор в
>> экстренном порядке, не дожидаясь liveboot. Так что действительно будем
>> все очень признательны!..
>>
>>
>>
>> -------- Перенаправленное сообщение --------
>> Тема: 	Re: [devel] Запрос на фичу liveboot в make-initrd
>> Дата: 	Tue, 24 Apr 2018 14:28:34 +0000
>> От: 	Aleksey Novodvorsky <aen@altlinux.ru>
>> Отвечать: 	ALT Linux Team development discussions
>> <devel@lists.altlinux.org>
>> Кому: 	ALT Linux Team development discussions <devel@lists.altlinux.org>
>>
>>
>>
>> вт, 10 апр. 2018 г., 22:49 Leonid Krivoshein <klark.devel@gmail.com
>> <mailto:klark.devel@gmail.com>>:
>>
>>      ...
>>      Алексей Гладков, автор и мэйнтейнер make-initrd, давно предлагал
>>      реализовать функционал пропагатора на скриптах, как отдельную фичу
>>      make-initrd. Назовём её условно "liveboot". Как я понимаю, Алексей готов
>>      и сейчас этим заняться, но у него есть сомнения, что его труды будут
>>      востребованы.
>>
>>
>>
>> Сегодня обсудили на совещании. liveboot всем очень нужен, будем
>> признательны Алексею.
>>
>> Rgrds, Алексей
>>
>>
>>
>> -- 
>> Best regards,
>> Leonid Krivoshein.
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Michael Shigorin]

On Thu, May 03, 2018 at 02:27:12AM +0300, Leonid Krivoshein wrote:
> 5) squashfs+aufs, в принципе, достаточны в том месте,
> где они сейчас используются, хотя есть сомнения относительно
> актуальности/поддержки aufs. Но наши разработчики про overlayfs
> высказывались скептически ещё несколько месяцев назад.

Я бы сейчас ориентировался на overlayfs и по возможности писал
так, чтобы не заблокировать добавление aufs при надобности --
это позволит закрыть наиболее широкий спектр задач и ядер
(в т.ч. уже установленных).

Разница в варианте полной замены там примерно такая:
http://git.altlinux.org/people/lakostis/packages/?p=make-initrd-propagator.git;a=commitdiff;h=85c2eab965c0f6d46311102a77a96de243ebad9c
(этот патч тогда не забрали ровно потому, что вместо добавления
поддержки происходит замена, а сесть и внимательно разобрать
как минимум у меня не хватало цельного кусочка времени).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info