UIRD. Не техническое обсуждение

[sfs]

Еще раз. в initrd модули ядра есть?

Зависит от ядра и типа загрузки. С нашим ядром без сети - не нужны
Модули можно цеплять слоеным initrd

надо ли стараться чтобы их не было? ответьте кратко и я приму решение стоит ли дальше мне анализировать это дело или лучше другим заняться. Потому как было высказано ранее что недостаток uird в том что модули ядра внутри initrd.

Что анализируешь и какое решение ?

[neobht]

Разница есть в том, что ipxe умеет грузить ядра по http и тд.
Pxe - только по tftp. Это требует настраивать все это дело и заморачиваться.

[DdShurick]

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

Вы предпочитаете под каждое ядро собирать свой initrd? Путаницы не получится?
Насчёт http://ipxe.org/ , написано очень заманчиво, но настораживает

You can use iPXE to replace the existing PXE ROM on your network card

[neobht]

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

Собрал ядро - пересобрал образ initrd, загрузился. Тем более, что пользователю это все равно незаметно. У него запускается система и потом предоставляет набор нужных программ. Что лежит внутри - без разницы, если это работает стабильно.

На Роса уже забыл, когда что-либо не работало бы. Не система, а конфетка. Особенно в модульном исполнении.

[DdShurick]

Да. Собирать новый initrd под каждое ядро.

А мы как-раз от этого ушли.

[sfs]

Мы то ушли - но во всех дистрах это стандартная практика. Главное чтобы initrd собиралось штатными средствами.
По итогу моих экспериментов - не во всех дистрах это получается. Только из этих соображений я перешел на 3х ступенчатый initrd

[neobht]

Ага. Только собираете kernel*.pfs.
Но поскольку ядро делает Pro, то и модули ядра он. Так от чего вы ушли? И главное зачем? Ушли от того, что этим заморачивается он, а не вы, а вы можете спокойно писать свой init, не обращая внимания на модули?

Весьма странное решение. И главное - в нем нет смысла, кроме как переложить эту работу на другого. По факту - те же удобства, только размазаны по другим местам.

С таким же успехом можно и вовсе всю систему упаковать в ядро, как попытался идейно сделать Барри, пока на флешкаФС не подсел. А что? Вся базовая система в ядре, включая X. А софт уже модулями. Все равно ведь copy2ram позиционирование. Только это все становится негибким, хотя делается очень просто.

[neobht]

Мы то ушли - но во всех дистрах это стандартная практика. Главное чтобы initrd собиралось штатными средствами.
По итогу моих экспериментов - не во всех дистрах это получается. Только из этих соображений я перешел на 3х ступенчатый initrd

Решение - вместе с самим initrd поставлять портабельный сборщик. Делается достаточно просто при желании.

[sfs]

портабельный сборщик.

Т.е что-то еще кроме скриптов с гитхаба?

[neobht]

Добавить к ним еще урезанный dracut.

У меня это в планах. Чуток время посвободнее будет и займусь.

[Pro]

Ага. Только собираете kernel*.pfs.
Но поскольку ядро делает Pro, то и модули ядра он. Так от чего вы ушли? И главное зачем? Ушли от того, что этим заморачивается он, а не вы, а вы можете спокойно писать свой init, не обращая внимания на модули?

а вы меня не  отделяйте от разработчиков и все будет нормально. Что легче при обновлении ядра сделать один pfs с модулями или pfs плюс initrd? вы ведь не пихаете все модули ядра в initrd, значит и пакет с модулями все равно делаете. Даже если этот initrd генерируется автоматически, все равно процесс получается сложнее. А мы не любим усложнять. Давайте просто признаем что есть вроде бы возможность сделать проще.

[sfs]

Ну и "размер имеет значение" 

[RoDoN]

Так от чего вы ушли? И главное зачем?

В результате легко заменить ядро на другое, причем не обязательно на сделанное Pro, но и на ядра от porteus, TahrPup и некоторые др.

[neobht]

Так от чего вы ушли? И главное зачем?

В результате легко заменить ядро на другое, причем не обязательно на сделанное Pro, но и на ядра от porteus, TahrPup и некоторые др.

ровно также легко можно собрать initrd - на этапе, когда упаковываются модули ядра в pfs.

а вы меня не  отделяйте от разработчиков и все будет нормально. Что легче при обновлении ядра сделать один pfs с модулями или pfs плюс initrd? вы ведь не пихаете все модули ядра в initrd, значит и пакет с модулями все равно делаете. Даже если этот initrd генерируется автоматически, все равно процесс получается сложнее. А мы не любим усложнять. Давайте просто признаем что есть вроде бы возможность сделать проще.

Возможности сделать проще - нет. Либо ядро собирать с модулями необходимыми для загрузки на многообразии сетевых карт, либо эти модули включать в initrd. И так и так - модули будут включены. Либо статично и тянуться будут с ядром, либо подтягивать модули по сети - в этом случае, когда они в initrd это и происходит. Когда они в pfs подтянуть можно тоже, но надо будет их упаковать в фиктивный initrd. Это сложнее.

[DdShurick]

ровно также легко можно собрать initrd - на этапе, когда упаковываются модули ядра в pfs.

Типичный взгляд админа. Модуль kernel-`uname -r`.sfs подхватывается автоматически, а ваш initrd???.gz придётся вручную вписывать. Что для юзверя проще?

Возможности сделать проще - нет.

Возможности сделать проще всегда есть и чем проще, тем надёжнее.