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

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

[Leonid Krivoshein]

Добрый день!


Сегодня в узком кругу с разработчиками в очередной раз пришли к понимаю, 
что нам очень нужно заменить propagator на что-то более современное и 
менее глючное, полностью реализующее аналогичный функционал. Хотя бы к P9!

https://www.altlinux.org/Installer/common/propagator
https://www.altlinux.org/Make-initrd-propagator
http://git.altlinux.org/gears/p/propagator.git
http://git.altlinux.org/gears/m/make-initrd-propagator.git

propagator был написан в конце 90-х на Си. Он прописывается в initramfs 
и обеспечивает функционал начальной стадии загрузки: поиск корня 
Инсталлятора, LiveCD, Rescue, итд., в соответствии с указанными 
параметрами загрузки ядра, по результату диалога с пользователем, либо 
включая внутренний интеллект. Даже самые последние исправления не 
помогли устранить его врождённых дефектов: он продолжает "терять" флэшки 
на этапе загрузки даже не на самом новейшем оборудовании.

Алексей Гладков, автор и мэйнтейнер make-initrd, давно предлагал 
реализовать функционал пропагатора на скриптах, как отдельную фичу 
make-initrd. Назовём её условно "liveboot". Как я понимаю, Алексей готов 
и сейчас этим заняться, но у него есть сомнения, что его труды будут 
востребованы. Прошу отписаться всех разработчиков, заинтересованных в 
решении данной проблемы! Со своей стороны, по мере занятости, готов 
помочь legion@ написанием части когда диалогов, если такая помощь от 
меня потребуется, а также готов помочь совместными усилиями довести этот 
проект до стадии готовности, тестирования и в дальнейшем продвигать 
полученную альтернативу в качестве замены пропагатору по всей линейке 
наших дистрибутивов.

Если данную рассылку читает Арсений Масленников, хотелось бы отдельно 
услышать и его мнение: может что-то в этом направлении уже сделано? 
Может Арсений тоже сможет (захочет) присоединиться, если не к 
разработке, то хотя бы к тестированию? Наверняка среди разработчиков 
найдутся те, кто также сможет уделить время проекту (тестировать, 
ревьювить, итп)...


Добавлю от себя лично: в пакете propagotor есть два особенных скрипта. 
Первый init-bottom "очень дорог для нас". И критичен в плане 
совместимости. Его бы как-то по-максимуму сохранить. Второй -- 
mkmodpack. О нём в данном письме речи не идёт. liveboot может не 
дублировать функционал mkmodpack, поскольку я просил Алексея Гладкова 
реализовать отдельно аналогичную фичу в том же make-initrd (назовём её 
условно "universal-boot" или "preinstall-modules"), и он согласился.


-- 
Best regards,
Leonid Krivoshein.

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

[Alexey V. Vissarionov]

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

On 2018-04-10 22:49:30 +0300, Leonid Krivoshein wrote:

 > propagator был написан в конце 90-х на Си. Он прописывается в
 > initramfs и обеспечивает функционал начальной стадии загрузки:
 > поиск корня Инсталлятора, LiveCD, Rescue, итд., в соответствии
 > с указанными параметрами загрузки ядра, по результату диалога с
 > пользователем, либо включая внутренний интеллект. Даже самые
 > последние исправления не помогли устранить его врождённых
 > дефектов: он продолжает "терять" флэшки на этапе загрузки даже
 > не на самом новейшем оборудовании.

Коллеги, а вот кто может внятно объяснить, зачем вообще может быть
нужен initrd при загрузке с локального носителя (непосредственно
подключенного к компутеру)?

Когда загрузка происходила с двух дискет, на первой из которых
было основательно выпотрошенное ядро (чтобы поместилось в 1.2 Мб),
а на второй образ initrd с модулями (опять же, не со всеми, а
только для поддержки накопителей и сетевых карт) - да, это было
не просто оправдано, а единственным доступным решением. Я так в
1994 году слакварь на 486SX/4/210 ставил :-)

Когда появилась возможность загружаться с компакт-дисков (через
ElTorito, то есть в режиме эмуляции дискеты объемом 2.88 Мб) -
стало чуть полегче, но и этот объем приходилось тратить на модули
поддержки накопителей, ибо CD-приводы тех времен подключались не
только к IDE (как большинство тогдашних жестких дисков), но и ко
всяким экзотическим интерфейсам - например, звуковым картам или, в
более простых случаях, к SCSI-контроллерам и параллельным портам.

Где-то на рубеже веков произошли два события, которые папа Карла
(Маркс, разумеется) назвал бы переходом количества в качество:
во-первых, существенно подешевела память, а во-вторых очередной
периферийный интерфейс обрел очередную функцию - к еще недавно
"никакому" USB стало возможно подключать блочные устройства и
загружаться с них точно так же, как с жестких дисков.

Собственно, именно с этого момента появилась возможность собирать
ядро со вкомпилированной поддержкой самых популярных накопителей
и сетевых интерфейсов, а технология initrd переместилась на новое
место работы: сетевая загрузка Live-системы. А что, когда памяти
аж 256 Мб - почему бы не отдать половину под / на /dev/ram0 для
запуска установки или rescue-системы?

"Какое, милые, у нас \n Тысячелетье на дворе?"

Когда я задал вышепроцитированный вопрос Бориса Леонидыча команде
`date +%Y`, она выдала ответ "2018". То есть, родившиеся на ранее
упомянутом "рубеже веков" люди уже выросли и даже закончили школу,
а у нас до сих пор при локальной загрузке используется initrd...

Фу.

 > Добавлю от себя лично: в пакете propagotor есть два особенных
 > скрипта. Первый init-bottom "очень дорог для нас". И критичен
 > в плане совместимости. Его бы как-то по-максимуму сохранить.
 > Второй -- mkmodpack. О нём в данном письме речи не идёт.

А зачем?

Грузим ядро, оно находит корневой раздел по метке, монтирует его,
запускает init... Зачем для этого какие-то костыли?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

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

[Sergey Bolshakov]

>>>>> "Leonid" == Leonid Krivoshein <klark.devel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

 > Добрый день!
 > Сегодня в узком кругу с разработчиками в очередной раз пришли к
 > понимаю, что нам очень нужно заменить propagator на что-то более
 > современное и менее глючное, полностью реализующее аналогичный
 > функционал. Хотя бы к P9!

 > https://www.altlinux.org/Installer/common/propagator
 > https://www.altlinux.org/Make-initrd-propagator
 > http://git.altlinux.org/gears/p/propagator.git
 > http://git.altlinux.org/gears/m/make-initrd-propagator.git

 > propagator был написан в конце 90-х на Си. Он прописывается в
 > initramfs и обеспечивает функционал начальной стадии загрузки: поиск
 > корня Инсталлятора, LiveCD, Rescue, итд., в соответствии с указанными
 > параметрами загрузки ядра, по результату диалога с пользователем, либо
 > включая внутренний интеллект. Даже самые последние исправления не
 > помогли устранить его врождённых дефектов: он продолжает "терять"
 > флэшки на этапе загрузки даже не на самом новейшем оборудовании.

 > Алексей Гладков, автор и мэйнтейнер make-initrd, давно предлагал
 > реализовать функционал пропагатора на скриптах, как отдельную фичу
 > make-initrd. Назовём её условно "liveboot". Как я понимаю, Алексей
 > готов и сейчас этим заняться, но у него есть сомнения, что его труды
 > будут востребованы. Прошу отписаться всех разработчиков,
 > заинтересованных в решении данной проблемы! Со своей стороны, по мере
 > занятости, готов помочь legion@ написанием части когда диалогов, если
 > такая помощь от меня потребуется, а также готов помочь совместными
 > усилиями довести этот проект до стадии готовности, тестирования и в
 > дальнейшем продвигать полученную альтернативу в качестве замены
 > пропагатору по всей линейке наших дистрибутивов.

Я бы поддержал идею отказаться от трёхстадийного устройства
инсталлятора, упразднив первую (propagator etc) и переработав вторую
стадию в initramfs, по устройству минимально отличающуюся от
обычной rootfs (/sbin/init => /init и ещё пара мелочей).
Иными словами, не нужно заменять propagator на что-либо другое,
тем более ещё не существующее, когда, мне кажется, было бы достаточно
его просто выкинуть.

[rest skipped]

-- 

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

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey V Vissarionov <gremlin-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On 2018-04-10 22:49:30 +0300, Leonid Krivoshein wrote:
 >> propagator был написан в конце 90-х на Си. Он прописывается в
 >> initramfs и обеспечивает функционал начальной стадии загрузки:
 >> поиск корня Инсталлятора, LiveCD, Rescue, итд., в соответствии
 >> с указанными параметрами загрузки ядра, по результату диалога с
 >> пользователем, либо включая внутренний интеллект. Даже самые
 >> последние исправления не помогли устранить его врождённых
 >> дефектов: он продолжает "терять" флэшки на этапе загрузки даже
 >> не на самом новейшем оборудовании.

 > Коллеги, а вот кто может внятно объяснить, зачем вообще может быть
 > нужен initrd при загрузке с локального носителя (непосредственно
 > подключенного к компутеру)?

Множество причин, тысячи их.

-- 

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

[Alexey V. Vissarionov]

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

On 2018-04-11 11:52:18 +0300, Sergey Bolshakov wrote:

 >>> последние исправления не помогли устранить его врождённых
 >>> дефектов: он продолжает "терять" флэшки на этапе загрузки
 >>> даже не на самом новейшем оборудовании.

 >> Коллеги, а вот кто может внятно объяснить, зачем вообще
 >> может быть нужен initrd при загрузке с локального носителя
 >> (непосредственно подключенного к компутеру)?

 > Множество причин, тысячи их.

Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
причин из этих тысяч?

Ну, кроме очевидного варианта "наши деды так делали, и мы будем
делать точно так же" :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

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

[Anton Farygin]

11.04.2018 13:37, Alexey V. Vissarionov пишет:
> On 2018-04-11 11:52:18 +0300, Sergey Bolshakov wrote:
>
>   >>> последние исправления не помогли устранить его врождённых
>   >>> дефектов: он продолжает "терять" флэшки на этапе загрузки
>   >>> даже не на самом новейшем оборудовании.
>
>   >> Коллеги, а вот кто может внятно объяснить, зачем вообще
>   >> может быть нужен initrd при загрузке с локального носителя
>   >> (непосредственно подключенного к компутеру)?
>
>   > Множество причин, тысячи их.
>
> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
> причин из этих тысяч?
>
> Ну, кроме очевидного варианта "наши деды так делали, и мы будем
> делать точно так же"

В моём детстве ядро все компилировали статикой.

Это про дедов, если что.

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

[Mikhail Efremov]

On Tue, 10 Apr 2018 22:49:30 +0300 Leonid Krivoshein wrote:
> Алексей Гладков, автор и мэйнтейнер make-initrd, давно предлагал 
> реализовать функционал пропагатора на скриптах, как отдельную фичу 
> make-initrd. Назовём её условно "liveboot". Как я понимаю, Алексей готов 
> и сейчас этим заняться, но у него есть сомнения, что его труды будут 
> востребованы. Прошу отписаться всех разработчиков, заинтересованных в 
> решении данной проблемы! 

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

-- 
WBR, Mikhail Efremov

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

[Michael Shigorin]

On Wed, Apr 11, 2018 at 08:56:06PM +0300, Mikhail Efremov wrote:
> Писать нужно скорее тем, кто имеет возражения, если вдруг такие есть.
> Пропагатор нужно переписать, это очевидно тем, кто смотрел внутрь.
> Идея заменить его модулем для make-initrd выглядит вполне разумной.

+1

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

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Dmitry V. Levin]

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

On Wed, Apr 11, 2018 at 01:37:28PM +0300, Alexey V. Vissarionov wrote:
> On 2018-04-11 11:52:18 +0300, Sergey Bolshakov wrote:
[...]
>  >> Коллеги, а вот кто может внятно объяснить, зачем вообще
>  >> может быть нужен initrd при загрузке с локального носителя
>  >> (непосредственно подключенного к компутеру)?
> 
>  > Множество причин, тысячи их.
> 
> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
> причин из этих тысяч?

Даже при загрузке с локального носителя есть штатные конфигурации,
в которых ядро само не может смонтировать rootfs и запустить оттуда init,
например:
- драйвер локального носителя не вкомпилирован в ядро;
- драйвер файловой системы rootfs не вкомпилирован в ядро;
- требуются нетривиальные действия для подготовки rootfs к монтированию,
  не связанные с загрузкой модулей ядра, например, расшифровка устройства
  с помощью ключа, тем или иным способом полученного от оператора загрузки
  во время загрузки.


-- 
ldv

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

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey Shabalin]

11 апреля 2018 г., 21:24 пользователь Dmitry V. Levin
<ldv@altlinux.org> написал:
> On Wed, Apr 11, 2018 at 01:37:28PM +0300, Alexey V. Vissarionov wrote:
>> On 2018-04-11 11:52:18 +0300, Sergey Bolshakov wrote:
> [...]
>>  >> Коллеги, а вот кто может внятно объяснить, зачем вообще
>>  >> может быть нужен initrd при загрузке с локального носителя
>>  >> (непосредственно подключенного к компутеру)?
>>
>>  > Множество причин, тысячи их.
>>
>> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
>> причин из этих тысяч?
>
> Даже при загрузке с локального носителя есть штатные конфигурации,
> в которых ядро само не может смонтировать rootfs и запустить оттуда init,
> например:
> - драйвер локального носителя не вкомпилирован в ядро;

+1
И я буду сильно против, если кто-то попытается мне подсунуть ядро со
всеми возможными вкомпиленными в ядро модулями.
Тем более, некоторыми еще нужен firmware, например FC Qlogic. Их куда
вкомпиливать?

> - драйвер файловой системы rootfs не вкомпилирован в ядро;

+1
Мне вот нужен rootfs на 9pfs. Уверены, что его надо вкомпиливать в ядро?

> - требуются нетривиальные действия для подготовки rootfs к монтированию,
>   не связанные с загрузкой модулей ядра, например, расшифровка устройства
>   с помощью ключа, тем или иным способом полученного от оператора загрузки
>   во время загрузки.

Тут, я думаю, вообще возразить что-то тяжело.

И от себя еще один вариант использования.
Мне бывает нужно подсунуть свою таблицу acpi для ноутбука в виде dsdt файла.

Если ядро претендует на роль универсального, а не для конкретной
железки и конкретной цели использования, без initrd невозможно
обойтись.

-- 
Alexey Shabalin

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

[Leonid Krivoshein]

11.04.2018 10:45, Alexey V. Vissarionov пишет:
> Коллеги, а вот кто может внятно объяснить, зачем вообще может быть
> нужен initrd при загрузке с локального носителя (непосредственно
> подключенного к компутеру)?

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_%D0%BA%D1%83%D1%80%D0%B8%D1%86%D1%8B_%D0%B8_%D1%8F%D0%B9%D1%86%D0%B0

Это же очевидно: чтобы смонтировать корневую файловую систему, 
необходимы модули для работы с диском и этой файловой системой, а для 
чтения модулей необходима файловая система, с которой этот модуль 
читается. :) В альте всё собирается модулями, а не зашивается в ядро. И 
в этом есть рациональное зерно (см. далее). Так делается по умолчанию и 
во всех известных мне дистрибутивах.


> Собственно, именно с этого момента появилась возможность собирать
> ядро со вкомпилированной поддержкой самых популярных накопителей
> и сетевых интерфейсов, а технология initrd переместилась на новое
> место работы: сетевая загрузка Live-системы. А что, когда памяти
> аж 256 Мб - почему бы не отдать половину под / на /dev/ram0 для
> запуска установки или rescue-системы?

И этой возможностью можно пользоваться, собирая ядро из исходников под 
конкретную систему, добавляя туда только то, что требуется лишь для этой 
системы. Нет смысла применять эту технологию во всех случаях по целому 
ряду причин, обусловленных, всё той же памятью, всё той же 
скоростью/эффективностью загрузки. И обеспечить возможность, о которой 
идёт речь, в binary-package-based дистрибутиве, наверное, хоть и 
возможно, но нерационально.

Кстати, раз речь о /dev/ram0, почему предлагается отказываться от stage1 
(initramfs) в пользу stage2 (ramdisk, традиционная загрузка корня, о 
которой далее говорит Сергей Большаков)? Ведь ядро понимает сжатый 
initramfs "из коробки". Причём это формат внутреннего кэша самого ядра. 
Эффективнее просто некуда. Никаких модулей дисков, файловых систем не 
требуется. Не говоря о том, что initramfs "из коробки" понимают все 
загрузчики. Его также можно вкомпилировать в само ядро. Простое любопытство.


>   > Добавлю от себя лично: в пакете propagotor есть два особенных
>   > скрипта. Первый init-bottom "очень дорог для нас". И критичен
>   > в плане совместимости. Его бы как-то по-максимуму сохранить.
>   > Второй -- mkmodpack. О нём в данном письме речи не идёт.
>
> А зачем?
>
> Грузим ядро, оно находит корневой раздел по метке, монтирует его,
> запускает init... Зачем для этого какие-то костыли?

http://git.altlinux.org/gears/m/make-initrd-propagator.git?p=make-initrd-propagator.git;a=blob;f=propagator/data/sbin/init-bottom;h=86d4e7b29095d5f5d8c85670c2e00e99894b7a9f;hb=bbcc4deda242a6fd48b6055be2e957df3db22819

init-bottom обеспечивает работу с read-only носителями, слоями aufs r/o 
и r/w, загрузкой по NFS, многими опциями пропагатора. Отрывая этот 
скрипт полностью, мы теряем возможность предложить со временем 
безболезненно перейти с пропагатора на make-initrd-liveboot.


-- 
Best regards,
Leonid Krivoshein.

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

[Leonid Krivoshein]

11.04.2018 11:49, Sergey Bolshakov пишет:
> Я бы поддержал идею отказаться от трёхстадийного устройства
> инсталлятора, упразднив первую (propagator etc) и переработав вторую
> стадию в initramfs, по устройству минимально отличающуюся от
> обычной rootfs (/sbin/init => /init и ещё пара мелочей).
> Иными словами, не нужно заменять propagator на что-либо другое,
> тем более ещё не существующее, когда, мне кажется, было бы достаточно
> его просто выкинуть.

Именно этим путём я пошёл, делая rescue-подобную минимальную систему в 
качестве чего-то, отдалённо напоминающее "инсталлятор по сети". Но в 
случае нашего обычного инсталлятора -- вариант "так себе". Потому что 
система с инсталлятором или LiveCD или Rescue (а речь о них обо всех в 
равной степени) "весят" сами по себе немало. Мы оптимизировали 
дублирование этого "веса", вынеся их в stage2 (на squashfs) и его сложив 
в корень загрузочного носителя (ISO Hybrid с поддержкой Legacy и EFI). А 
вот с ядром и initramfs так не выходит -- их приходится держать на 
установочном диске в двух экземплярах, каждый! Самая минимальная наша 
система Rescue (сквош, который Вы предлагаете перенести в initramfs) 
весит порядка 460Mb. А все остальные системы больше, особенно LiveCD.


-- 
Best regards,
Leonid Krivoshein.

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

[Leonid Krivoshein]

11.04.2018 23:02, Leonid Krivoshein пишет:
>
> 11.04.2018 11:49, Sergey Bolshakov пишет:
>> Я бы поддержал идею отказаться от трёхстадийного устройства
>> инсталлятора, упразднив первую (propagator etc) и переработав вторую
>> стадию в initramfs, по устройству минимально отличающуюся от
>> обычной rootfs (/sbin/init => /init и ещё пара мелочей).
>> Иными словами, не нужно заменять propagator на что-либо другое,
>> тем более ещё не существующее, когда, мне кажется, было бы достаточно
>> его просто выкинуть.
>
> Именно этим путём я пошёл, делая rescue-подобную минимальную систему в 
> качестве чего-то, отдалённо напоминающее "инсталлятор по сети". Но в 
> случае нашего обычного инсталлятора -- вариант "так себе". Потому что 
> система с инсталлятором или LiveCD или Rescue (а речь о них обо всех в 
> равной степени) "весят" сами по себе немало. Мы оптимизировали 
> дублирование этого "веса", вынеся их в stage2 (на squashfs) и его 
> сложив в корень загрузочного носителя (ISO Hybrid с поддержкой Legacy 
> и EFI). А вот с ядром и initramfs так не выходит -- их приходится 
> держать на установочном диске в двух экземплярах, каждый! Самая 
> минимальная наша система Rescue (сквош, который Вы предлагаете 
> перенести в initramfs) весит порядка 460Mb. А все остальные системы 
> больше, особенно LiveCD.
>

Немного подумав, решил озвучить идею. Проблема решаема, если отказаться 
от тех загрузчиков на ISO Hybrid, что используются сейчас, в пользу 
syslinux 6+. Тога можно сделать два конфигурационных файла для Legacy и 
EFI-загрузки, а вот ядро и initramfs сложить в одно место. Поправьте, 
если я ошибаюсь...


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Leonid Krivoshein]

11.04.2018 22:18, Alexey Shabalin пишет:
> 11 апреля 2018 г., 21:24 пользователь Dmitry V. Levin
> <ldv@altlinux.org> написал:
>> On Wed, Apr 11, 2018 at 01:37:28PM +0300, Alexey V. Vissarionov wrote:
>>> On 2018-04-11 11:52:18 +0300, Sergey Bolshakov wrote:
>> [...]
>>>   >> Коллеги, а вот кто может внятно объяснить, зачем вообще
>>>   >> может быть нужен initrd при загрузке с локального носителя
>>>   >> (непосредственно подключенного к компутеру)?
>>>
>>>   > Множество причин, тысячи их.
>>>
>>> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
>>> причин из этих тысяч?
>> Даже при загрузке с локального носителя есть штатные конфигурации,
>> в которых ядро само не может смонтировать rootfs и запустить оттуда init,
>> например:
>> - драйвер локального носителя не вкомпилирован в ядро;
> +1
> И я буду сильно против, если кто-то попытается мне подсунуть ядро со
> всеми возможными вкомпиленными в ядро модулями.
> Тем более, некоторыми еще нужен firmware, например FC Qlogic. Их куда
> вкомпиливать?
>
>> - драйвер файловой системы rootfs не вкомпилирован в ядро;
> +1
> Мне вот нужен rootfs на 9pfs. Уверены, что его надо вкомпиливать в ядро?
>
>> - требуются нетривиальные действия для подготовки rootfs к монтированию,
>>    не связанные с загрузкой модулей ядра, например, расшифровка устройства
>>    с помощью ключа, тем или иным способом полученного от оператора загрузки
>>    во время загрузки.
> Тут, я думаю, вообще возразить что-то тяжело.
>
> И от себя еще один вариант использования.

Технологию выгрузки/загрузки модулей "на лету", которую обычно применяют 
на десктопах для всяких alsa-tools, wifi-модулей после просыпания, иначе 
с ними ядро нормально не работает, понятное дело, в случае носителей 
применяется редко, даже для hotplug. Тем не менее, меня эта техника 
выручала в случаях жёсткого зависания в пространстве ядра на критически 
важных системах, когда всё глухо висло при обращении к одному из дисков. 
Если модуль вкомпилирован -- только полная перезагрузка и простой.


> Мне бывает нужно подсунуть свою таблицу acpi для ноутбука в виде dsdt файла.
>
> Если ядро претендует на роль универсального, а не для конкретной
> железки и конкретной цели использования, без initrd невозможно
> обойтись.
>

-- 
Best regards,
Leonid Krivoshein.

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Leonid Krivoshein]

11.04.2018 22:18, Alexey Shabalin пишет:
> 11 апреля 2018 г., 21:24 пользователь Dmitry V. Levin
> <ldv@altlinux.org> написал:
>> - требуются нетривиальные действия для подготовки rootfs к монтированию,
>>    не связанные с загрузкой модулей ядра, например, расшифровка устройства
>>    с помощью ключа, тем или иным способом полученного от оператора загрузки
>>    во время загрузки.
> Тут, я думаю, вообще возразить что-то тяжело.
>
> И от себя еще один вариант использования.

Или скажем некоторые товарищи захотят корень на ZFS, которую, в отличие 
от btrfs, мы при всём желании в составе ядра включить не сможем. 
Конечно, неправильно поддерживать такие капризы, но с initrd это штатно 
реализуемо нашим дистрибутивами.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey V. Vissarionov]

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

On 2018-04-11 21:24:18 +0300, Dmitry V. Levin wrote:

 >>>> Коллеги, а вот кто может внятно объяснить, зачем вообще
 >>>> может быть нужен initrd при загрузке с локального носителя
 >>>> (непосредственно подключенного к компутеру)?
 >>> Множество причин, тысячи их.
 >> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
 >> причин из этих тысяч?

 > Даже при загрузке с локального носителя есть штатные
 > конфигурации, в которых ядро само не может смонтировать rootfs и
 > запустить оттуда init, например:
 > - драйвер локального носителя не вкомпилирован в ядро;
 > - драйвер файловой системы rootfs не вкомпилирован в ядро;

Дим, ну самому-то не смешно?

Локальный носитель в 90% случаев (у меня, конечно, выборка весьма
средненькая, даже пары тысяч хостов не наберется) - либо жесткий
диск на platform AHCI SATA, либо USB mass storage, подключенный к
одному из четырех типов УПШ-хостов: OHCI, UHCI, EHCI или недавно
появившемуся XHCI для USB3. Размер соответствующих ядерных модулей
составляет 417+75 == 492 килобайта.

Размер ядерного модуля ext4 (который поддерживает ext2 и ext3) -
447 килобайтов. Корневой раздел с файловой системой, отличной от
ext[34], мне встретился ровно один раз, и его история, по словам
тамошнего админа, была такова: "приехал новый сервер, пока было не
срочно - решил поэкспериментировать, а потом гавкнулся один из
боевых серверов и нужно было заменить его в течение %u минут - вот
с тех пор и трудится" (надеюсь, от замены специального технического
термина на эвфемизм "гавкнулся" смысл цитаты не сильно исказился).

Вышеприведенные цифири я получил в процессе сборки ядра 4.16 (да,
есть и более свежее, но это уже было развернуто у меня в ~/tmp для
генерации патча именно под эту версию и тестовой сборки). Вот еще
одна цифирь:

gremlin@evil:~/tmp/linux-4.16 > strip vmlinux.o
gremlin@evil:~/tmp/linux-4.16 > lh vmlinux.o
-rw------- 1 gremlin users 36M апр 12 10:38 vmlinux.o
gremlin@evil:~/tmp/linux-4.16 > lh arch/x86/boot/bzImage
-rw------- 1 gremlin users 12M апр 12 10:29 arch/x86/boot/bzImage

Ну да, цифирей тут две, но они отражают два важных свойства ядра -
сколько оно займет в памяти (первая, 36 мегабайтов) и сколько места
ему понадобится в корневом разделе (вторая, 12 мегабайтов). Памяти,
понятное дело, в процессе работы потребуется где-то в полтора раза
больше (полсотни мегабайтов), но тут мне хочется снова процитировать
Б.Л.Пастернака: "Какое, милые, у нас тысячелетье на дворе?" - благо,
ответом на вопрос поэта вполне может служить `head -1 /proc/meminfo`

Так что даже совместно эти два примера с трудом дотягивают даже до
одной причины из обещанных тысяч (или из запрошенного десятка).

 > - требуются нетривиальные действия для подготовки rootfs к
 > монтированию, не связанные с загрузкой модулей ядра, например,
 > расшифровка устройства с помощью ключа, тем или иным способом
 > полученного от оператора загрузки во время загрузки.

Вот это уже чуть более интересный пример, а решаемая задача вполне
может считаться типовой. Да, зашифрованные разделы бывают - я лично
рекомендую всем защищать как минимум /home; уточню, что это особенно
актуально для серверов, ибо позволяет "взлететь" с незашифрованного
корневого раздела, где кроме ~root/.ssh/authorized_keys в принципе
нет ничего интересного, да и его содержимое никакой практической
ценности не представляет. Единственный риск, который сохраняется при
таком подходе к защите - компрометация ОС в незашифрованном корневом
разделе, но сделать это незаметно крайне сложно и очень дорого, ущерб
минимален (равен стоимости рабочего времени, потраченного на установку
чистой системы), а вероятность исчезающе мала, что очевидным образом
помещает этот риск в левый верхний угол оценочной таблицы (low severity,
low probability).

Для рабочих станций (особенно ноутбуков, которые могут быть украдены),
действительно, можно использовать описанный тобой способ, но у него
есть существенный недостаток: он требует загрузки с внешнего носителя
(иначе ничем принципиально не отличается от варианта с незашифрованным
корнем), что порождает два дополнительных требования по защите
1. флешки - от утраты традиционным способом или опять же компрометации;
2. компутера - от загрузки с чужой флешки.

В общем случае вариант с криптозащитой /home является предпочтительным,
поэтому я остановил свой выбор именно на нем. Что и остальным советую.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey V. Vissarionov]

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

On 2018-04-11 22:18:39 +0300, Alexey Shabalin wrote:

 >>>>> Коллеги, а вот кто может внятно объяснить, зачем вообще
 >>>>> может быть нужен initrd при загрузке с локального носителя
 >>>>> (непосредственно подключенного к компутеру)?
 >>>> Множество причин, тысячи их.
 >>> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
 >>> причин из этих тысяч?
 >> Даже при загрузке с локального носителя есть штатные
 >> конфигурации, в которых ядро само не может смонтировать rootfs и
 >> запустить оттуда init, например: - драйвер локального носителя
 >> не вкомпилирован в ядро;
 > +1 И я буду сильно против, если кто-то попытается мне подсунуть
 > ядро со всеми возможными вкомпиленными в ядро модулями.

Зачем со всеми-то? Здесь прекрасно соблюдается правило 80/20 - работу
80% всего железа обеспечивают 20% ядерного кода.

 > Тем более, некоторыми еще нужен firmware, например FC Qlogic.
 > Их куда вкомпиливать?

Ты не поверишь - вкомпилированные модули тоже умеют грузить firmware
из userspace. Я серьезно. Могу даже показать: втыкаю в УПШ железяку
(WiFi-свистульку), говорю dmesg и вижу что-то вроде "Автоматическая
загрузка /lib/firmware/... - загружена версия 1.2.3".

Впрочем, как раз такие модули есть смысл держать в /lib/modules

 >> - драйвер файловой системы rootfs не вкомпилирован в ядро;
 > +1 Мне вот нужен rootfs на 9pfs.

Это реальная задача или так, разговор поддержать?
Вопрос не риторический, мне для статистики.

 > Уверены, что его надо вкомпиливать в ядро?

Именно корень? "Не верю!" // (ц) К.С.Станиславский

/home - сколько угодно, но корень...
Кстати, а грузиться оно откуда будет?

 >> - требуются нетривиальные действия для подготовки rootfs к
 >> монтированию, не связанные с загрузкой модулей ядра, например,
 >> расшифровка устройства с помощью ключа, тем или иным способом
 >> полученного от оператора загрузки во время загрузки.
 > Тут, я думаю, вообще возразить что-то тяжело.

См. мой ответ ldv@

 > И от себя еще один вариант использования.  Мне бывает нужно
 > подсунуть свою таблицу acpi для ноутбука в виде dsdt файла.

Список моделей таких ноутбуков - в президиум! Желательно с
пометками, какие из них умеют делать это через EFI, какие нет.

 > Если ядро претендует на роль универсального, а не для
 > конкретной железки и конкретной цели использования, без initrd
 > невозможно обойтись.

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

Я уже, наверное, могу спорить на пиво, что собранное мной свежее
ядро безо всякого initrd взлетит с полной поддержкой загрузочного
накопителя (где корень и /lib/modules) на любом писюшном железе,
выпущенном за прошедшие 3 года - с 2015 по 2018 год. Если что, про
серверы с EFI-only загрузкой знаю, они мне уже не особо интересны
(сейчас у криворуких админов это величайшая проблема: железо
требует инициализации средствами EFI, без которой превращается в
тыкву; решение - не откатываться на CSM, а пользоваться EFI, но им
страшно и непривычно).

2 all: если что, принимаю приглашения :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey V. Vissarionov]

On 2018-04-12 00:21:54 +0300, Leonid Krivoshein wrote:

 > Технологию выгрузки/загрузки модулей "на лету", которую
 > обычно применяют на десктопах для всяких alsa-tools, wifi-модулей
 > после просыпания, иначе с ними ядро нормально не работает,
 > понятное дело, в случае носителей применяется редко, даже для
 > hotplug. Тем не менее, меня эта техника выручала в случаях жёсткого
 > зависания в пространстве ядра на критически важных системах,
 > когда всё глухо висло при обращении к одному из дисков. Если
 > модуль вкомпилирован -- только полная перезагрузка и простой.

Звук, WiFi и прочую экзотику вполне реально грузить из /lib/modules
после загрузки ядра и монтирования корня. Вопрос был про initrd, а
не про модули :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey V. Vissarionov]

On 2018-04-12 00:27:18 +0300, Leonid Krivoshein wrote:

 > Или скажем некоторые товарищи захотят корень на ZFS, которую,
 > в отличие от btrfs, мы при всём желании в составе ядра включить
 > не сможем. Конечно, неправильно поддерживать такие капризы,
 > но с initrd это штатно реализуемо нашим дистрибутивами.

/моя апплодирует стоя: эвфемизм "капризы" для обозначения "усер
сам не понимает, что ему нужно" - это прекрасно.

Но тут опять же возникает традиционный сельскохозяйственный
вопрос: на кой хрен ZFS на корне? Корню вполне достаточно ext3
(даже не ext4), а для хранения данных (особенно таких, которым
требуется ZFS) все же принято монтировать отдельные файловые
системы.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey Gladkov]

On Thu, Apr 12, 2018 at 01:41:39PM +0300, Игорь Андросов wrote:
> Добрый день!
> 
> Я может что-то пропустил, или путаю, или не понимаю, но:
> initrd нужен для создания минимально необходимого загрузочного окружения,
> почему именно оно нужно (сеть, шифрование, диски и тд) вопрос несколько иной
> На текущий момент он вроде со своей задачей справляется
> При необходимости можно собрать initrd в той конфигурации которая требуется
> под конкретную задачу, и вот тут я перестаю понимать подход: "На кой хрен,
> у меня в моей выборке" и тд, у людей есть разные задачи и этот механизм их
> успешно решает, какой бы экзотической, или капризом, на чужой взгляд,
> задача не являлась.
> 
> И тут, вдруг, предлагается отказаться от такого механизма, заменив его
> универсальной сборкой ядра, которая возможно будет всегда работать,
> засунуть свои задачи и решения куда-то, потому что кто-то решил что этот
> механизм не нужен потому что он не нужен решившему.

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

> Вот что это - оторвать работающее, прикрутить возможно работающее, и я пока
> не понимаю какие положительные моменты от такого?

Не возможно собрать такое ядро, которое покроет достаточное количество
инсталляций. Это фантазии.

> 12 апреля 2018 г., 12:52 пользователь Alexey V. Vissarionov <
> gremlin@altlinux.org> написал:
> 
> > On 2018-04-12 00:27:18 +0300, Leonid Krivoshein wrote:
> >
> >  > Или скажем некоторые товарищи захотят корень на ZFS, которую,
> >  > в отличие от btrfs, мы при всём желании в составе ядра включить
> >  > не сможем. Конечно, неправильно поддерживать такие капризы,
> >  > но с initrd это штатно реализуемо нашим дистрибутивами.
> >
> > /моя апплодирует стоя: эвфемизм "капризы" для обозначения "усер
> > сам не понимает, что ему нужно" - это прекрасно.
> >
> > Но тут опять же возникает традиционный сельскохозяйственный
> > вопрос: на кой хрен ZFS на корне? Корню вполне достаточно ext3
> > (даже не ext4), а для хранения данных (особенно таких, которым
> > требуется ZFS) все же принято монтировать отдельные файловые
> > системы.
> >
> >
> > --
> > Alexey V. Vissarionov
> > gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
> > GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> >
> 
> 
> 
> -- 
> С уважением Игорь.

> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


-- 
Rgrds, legion

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Alexey Shabalin]

12 апреля 2018 г., 12:31 пользователь Alexey V. Vissarionov
<gremlin@altlinux.org> написал:
> On 2018-04-11 22:18:39 +0300, Alexey Shabalin wrote:
>
>  >>>>> Коллеги, а вот кто может внятно объяснить, зачем вообще
>  >>>>> может быть нужен initrd при загрузке с локального носителя
>  >>>>> (непосредственно подключенного к компутеру)?
>  >>>> Множество причин, тысячи их.
>  >>> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток
>  >>> причин из этих тысяч?
>  >> Даже при загрузке с локального носителя есть штатные
>  >> конфигурации, в которых ядро само не может смонтировать rootfs и
>  >> запустить оттуда init, например: - драйвер локального носителя
>  >> не вкомпилирован в ядро;
>  > +1 И я буду сильно против, если кто-то попытается мне подсунуть
>  > ядро со всеми возможными вкомпиленными в ядро модулями.
>
> Зачем со всеми-то? Здесь прекрасно соблюдается правило 80/20 - работу
> 80% всего железа обеспечивают 20% ядерного кода.

что-то я тут не догнал. ты предлагаешь выбросить еще и 80% кода ядра?

>  > Тем более, некоторыми еще нужен firmware, например FC Qlogic.
>  > Их куда вкомпиливать?
>
> Ты не поверишь - вкомпилированные модули тоже умеют грузить firmware
> из userspace. Я серьезно. Могу даже показать: втыкаю в УПШ железяку
> (WiFi-свистульку), говорю dmesg и вижу что-то вроде "Автоматическая
> загрузка /lib/firmware/... - загружена версия 1.2.3".

Я говорю о firmware, нужном для rootfs, а не для wifi-свистулек.
Специально указал на Fiber Channel Qlogic.

>
> Впрочем, как раз такие модули есть смысл держать в /lib/modules
>
>  >> - драйвер файловой системы rootfs не вкомпилирован в ядро;
>  > +1 Мне вот нужен rootfs на 9pfs.
>
> Это реальная задача или так, разговор поддержать?
> Вопрос не риторический, мне для статистики.

Да, это реальная задача.
Запуск виртуалки qemu без образа, а указав ядро, initrd, и директорию
для rootfs.
Типа "контейнер", но с kvm.
Смотри runV, rkt, kvm-tools.

>  > Уверены, что его надо вкомпиливать в ядро?
>
> Именно корень? "Не верю!" // (ц) К.С.Станиславский

именно корень.

> /home - сколько угодно, но корень...
> Кстати, а грузиться оно откуда будет?

с ядра и initrd, указанного в параметрах qemu.

>  >> - требуются нетривиальные действия для подготовки rootfs к
>  >> монтированию, не связанные с загрузкой модулей ядра, например,
>  >> расшифровка устройства с помощью ключа, тем или иным способом
>  >> полученного от оператора загрузки во время загрузки.
>  > Тут, я думаю, вообще возразить что-то тяжело.
>
> См. мой ответ ldv@
>
>  > И от себя еще один вариант использования.  Мне бывает нужно
>  > подсунуть свою таблицу acpi для ноутбука в виде dsdt файла.
>
> Список моделей таких ноутбуков - в президиум! Желательно с
> пометками, какие из них умеют делать это через EFI, какие нет.

У меня ноут Sony 2009 года выпуска, никаких EFI нет. Но он работает и
меня вполне устраивает.
Часть проблем решается именно правкой acpi таблиц, которые надо
подсунуть в момент загрузки ядра.

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

> Я уже, наверное, могу спорить на пиво, что собранное мной свежее
> ядро безо всякого initrd взлетит с полной поддержкой загрузочного
> накопителя (где корень и /lib/modules) на любом писюшном железе,
> выпущенном за прошедшие 3 года - с 2015 по 2018 год. Если что, про
> серверы с EFI-only загрузкой знаю, они мне уже не особо интересны
> (сейчас у криворуких админов это величайшая проблема: железо
> требует инициализации средствами EFI, без которой превращается в
> тыкву; решение - не откатываться на CSM, а пользоваться EFI, но им
> страшно и непривычно).

Почему я ради вашей прихоти должен через 3 года менять железо? Оно
меня вполне устраивает.

> 2 all: если что, принимаю приглашения :-)

-- 
Alexey Shabalin

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

[Alexey V. Vissarionov]

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

On 2018-04-11 22:41:11 +0300, Leonid Krivoshein wrote:

 >> Коллеги, а вот кто может внятно объяснить, зачем вообще
 >> может быть нужен initrd при загрузке с локального носителя
 >> (непосредственно подключенного к компутеру)?
 > Это же очевидно: чтобы смонтировать корневую файловую систему,
 > необходимы модули для работы с диском и этой файловой системой,

Досюда все правильно.

 > а для чтения модулей необходима файловая система, с которой
 > этот модуль читается. :)

Ну и что мешает вкомпилировать в ядро поддержку наиболее типового
железа? Да и вообще - всех модулей, у которых при вкомпилячивании
в ядро появляется дополнительная функциональность (так, например,
CONFIG_MD_RAID{0,1,10,456}=y дает включить CONFIG_MD_AUTODETECT,
который, в свою очередь, позволяет держать корень на зеркале безо
всяких костылей). Ы?

 > В альте всё собирается модулями, а не зашивается в ядро.

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

Ну и самое главное: вкомпилячивание в ядро самых востребованных
модулей не отменяет CONFIG_MODULES=y и CONFIG_BLK_DEV_INITRD=y -
они прекрасно уживаются в одном ядре.

 > И в этом есть рациональное зерно (см. далее). Так делается по
 > умолчанию и во всех известных мне дистрибутивах.

Ага... в шляпе - "мы так делаем с 1994 года", у всех остальных -
"в шляпе делают так, значит и мы будем делать так" :-)

 >> Собственно, именно с этого момента появилась возможность
 >> собирать ядро со вкомпилированной поддержкой самых
 >> популярных накопителей и сетевых интерфейсов, а технология
 >> initrd переместилась на новое место работы: сетевая загрузка
 >> Live-системы. А что, когда памяти аж 256 Мб - почему бы не
 >> отдать половину под / на /dev/ram0 для запуска установки или
 >> rescue-системы?
 > И этой возможностью можно пользоваться, собирая ядро
 > из исходников под конкретную систему, добавляя туда
 > только то, что требуется лишь для этой системы. Нет
 > смысла применять эту технологию во всех случаях по целому
 > ряду причин, обусловленных, всё той же памятью, всё той же
 > скоростью/эффективностью загрузки. И обеспечить возможность,
 > о которой идёт речь, в binary-package-based дистрибутиве,
 > наверное, хоть и возможно, но нерационально.

Какой возможностью? Загрузкой по сети? Да ей уже давно успешно
пользуются все, кому не лень...

А с установкой все становится совсем просто: загрузились откуда
угодно (например, по сети), смонтировали целевой носитель,
сказали rpmdb --root $TARGETDIR --initdb и поехали ставить пакеты
через rpm --root $TARGETDIR -Uvh ...

Я так в датацентре серверы запускал: грузчики притащили, техники
в стойку поставили и провода воткнули, оно по PXE загрузилось,
само систему втащило, в нее перегрузилось, нужный VLAN подхватило,
адрес получило - все, машина готова к работе, хотя я ее в глаза
не видел :-)

 > Кстати, раз речь о /dev/ram0, почему предлагается отказываться
 > от stage1 (initramfs) в пользу stage2 (ramdisk, традиционная
 > загрузка корня, о которой далее говорит Сергей Большаков)?

/dev/ram0 хорош тем, что позволяет, например, поставить пакеты
в загруженную по сети live-систему - в корне для этого можно
оставить место. Ну да, памяти оно сожрет чуть больше... да и пусть
с ней - в современных компутерах ее много.

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

Как сказал председатель Мао, "bai hua qifang, bai jia zhengming" -
"пусть расцветают сто цветов, пусть соперничают сто школ". Кому что
больше нравится - пусть то и пользуют, ядро поддерживает оба этих
варианта.

 >>> Добавлю от себя лично: в пакете propagotor есть два особенных
 >>> скрипта. Первый init-bottom "очень дорог для нас". И критичен
 >>> в плане совместимости. Его бы как-то по-максимуму сохранить.
 >>> Второй -- mkmodpack. О нём в данном письме речи не идёт.
 >> А зачем? Грузим ядро, оно находит корневой раздел по метке,
 >> монтирует его, запускает init... Зачем для этого какие-то
 >> костыли?
 > init-bottom обеспечивает работу с read-only носителями, слоями
 > aufs r/o и r/w, загрузкой по NFS, многими опциями пропагатора.

Я правильно понимаю, что речь прежде всего об унификации этой работы?
Тогда возникает другой вопрос: а нужна ли она? Или лучше использовать
более специализированные инструменты для работы с разными носителями?

Впрочем, загрузка live-системы и установка системы на компутер - это
хоть и взаимосвязанные, но все же отдельные задачи.

 > Отрывая этот скрипт полностью, мы теряем возможность предложить со
 > временем безболезненно перейти с пропагатора на make-initrd-liveboot.

А если не отрывать полностью, но попробовать обойтись без него там,
где это возможно?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

Re: [devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

[Anton Farygin]

12.04.2018 13:41, Игорь Андросов пишет:
>
> И тут, вдруг, предлагается отказаться от такого механизма, заменив его 
> универсальной сборкой ядра, которая возможно будет всегда работать, 
> засунуть свои задачи и решения куда-то, потому что кто-то решил что 
> этот механизм не нужен потому что он не нужен решившему.

не слушайте гремлина, он часто свои желания отображает за ваши потребности.

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

[Leonid Krivoshein]

12.04.2018 16:33, Alexey V. Vissarionov пишет:
> On 2018-04-11 22:41:11 +0300, Leonid Krivoshein wrote:
>
>   >> Коллеги, а вот кто может внятно объяснить, зачем вообще
>   >> может быть нужен initrd при загрузке с локального носителя
>   >> (непосредственно подключенного к компутеру)?

Уже отсюда всё неправильно! Стоило сразу заметить, что в случае 
пропагатора в initrd, носитель не всегда является локальным. Он как раз 
обеспечивает и сетевую загрузку, и загрузку с read-only носителей, 
подключенных локально, но съёмных. И создавать для этих случаев разные 
варианты ядер и инсталляторов смысла нет. Propagator, будучи в initrd, 
может задавать вопросы, откуда ставить систему. Ты можешь вкомпилировать 
в ядро вопросы пропагатора (1й стадии установщика)? :) Был упущен 
аргумент о том, что сейчас stage2 вынесена в корень установочного 
носителя, тогда как ядро с initrd находятся на нём в двух экземплярах.


>   > Это же очевидно: чтобы смонтировать корневую файловую систему,
>   > необходимы модули для работы с диском и этой файловой системой,
>
> Досюда все правильно.
>
>   > а для чтения модулей необходима файловая система, с которой
>   > этот модуль читается. :)
>
> Ну и что мешает вкомпилировать в ядро поддержку наиболее типового
> железа? Да и вообще - всех модулей, у которых при вкомпилячивании
> в ядро появляется дополнительная функциональность (так, например,
> CONFIG_MD_RAID{0,1,10,456}=y дает включить CONFIG_MD_AUTODETECT,
> который, в свою очередь, позволяет держать корень на зеркале безо
> всяких костылей). Ы?

Я бы скорее назвал два случая, весьма специфичных, для которых имеет 
смысл что-либо вкомпилировать в ядро: загрузка с md-raid без /boot (ух, 
ещё бы админов к этому приучить) и загрузка с корня на NFS, когда в ядро 
вкомпилируется даже свой DHCP-клиент. Но это такие крайние случаи, под 
которые не стоит ориентировать мэйнстрим.

Обсуждаемая проблема состоит в том, что нынешняя stage1 
Установщика/LiveCD/Rescue покрывает 95-98% железа, причём с нареканиями, 
к тому же требует "ухаживать" за файлами со списком модулей в m-p. Внеся 
изменения в алгоритм подбора модулей в соответствии устанавливаемому 
ядру, достаточных для загрузки на 99.9% железа, мы избавим себя от 
необходимости периодически ревьювить текстовый список модулей/регэкспов. 
Заменив пропагатор более надёжным решением, избавимся от нареканий и 
глюков. Это две разные задачи, но они об одном. Потому что не уследив 
вовремя за модулями, мы собрали более новое ядро без поддержки железа, 
которое там появилось, и у людей "не взлетело". Даже в этом году 
обращались (загрузка по PXE, облом на e1000e в более старом p7).

Твой вопрос: что мешает вкомпилировать в ядро поддержку наиболее 
типового железа?

1. Такой задачи не стоит. Нужно покрыть 100% железа, а не 80%. Потому 
что речь об общем, дистрибутивном, а не узко-специфичном решении. 
Простой пример "хитрого" железа, где так просто "не взлетит" -- Dell 
Latitude X1 с очень необычным съёмным DVD-приводом.

2. Каждый модуль что-то весит. А есть модули, требующие ещё и фирмварь. 
Чем больше модулей, тем ядро будет больше весить. Мало того, при каждой 
загрузке будет выполняться probe для каждого вкомпиляченного модуля, что 
замедлит процесс загрузки. Ну, так ведь наши деды никуда не торопились, 
да? :) Хотя сейчас, может, что-то изменилось и это работает иначе, не 
знаю. Понимаю, что MFM/RLL дискам место в музее истории, однако IDE 
найдутся даже в моём хозяйстве, а до относительно недавних пор 
использовал внешний ATAPI/CD-привод, подключавшийся к LPT-порту! Про 
нюансы с разными вариантами IDE, думаю, ты знаешь. И вот, если есть 
сомнения:

https://www.kernel.org/doc/Documentation/driver-model/platform.txt

3. Весьма неудобно держать/собирать десятки ядер под разные задачи. У 
нас их и так уже достаточно. Тогда как есть простой механизм -- одно 
ядро, один набор модулей в initrd.

4. Если загрузка модуля может быть перекрыта через blacklist, вызывая 
проблемы на конкретном железе, то как быть с вкомпиляченным модулем? 
Ядро менять?

5. Ещё несколько лет назад (не знаю, как сейчас), на ряде ноутбуков 
загрузиться по вай-фаю без ndiswrapper с виндовыми дровами было 
невозможно. Виндовые дрова тоже в ядро будем вкомпилячивать? :)

Этот список можно продолжать очень долго. И без того много букв! Ничто 
не мешает оптимизировать набор модулей под конкретную машину. Более 
того, по умолчанию у нас так и делается в процессе установки. Ничто не 
мешает собирать людям ядра с нужными им модулями под свои 
узко-специфичные задачи. Но мы здесь говорим совершенно о другом. Не 
стоит путать общее и частное. По моему глубокому убеждению, вообще всё 
равно, где находятся модули -- в ядре или в initrd с точки зрения 
"взлетит или не взлетит". Главное, чтобы они были. initramfs 
поддерживается ядром и не требует поддержки со стороны железа, 
одновременно обеспечивая общий, простой, удобный и модульный подход.


> Ага... в шляпе - "мы так делаем с 1994 года", у всех остальных -
> "в шляпе делают так, значит и мы будем делать так" :-)

-->

>   > Кстати, раз речь о /dev/ram0, почему предлагается отказываться
>   > от stage1 (initramfs) в пользу stage2 (ramdisk, традиционная
>   > загрузка корня, о которой далее говорит Сергей Большаков)?
>
> /dev/ram0 хорош тем, что позволяет, например, поставить пакеты
> в загруженную по сети live-систему - в корне для этого можно
> оставить место. Ну да, памяти оно сожрет чуть больше... да и пусть
> с ней - в современных компутерах ее много.

А я думал, потому что так деды делали! :) Вообще-то initrd это 
усовершенствованный ramdisk. Если у тебя там будет rpm, apt, и даже 
Synaptic с иксами, ставь туда, что хочешь. В отличии от ramdisk, не надо 
указывать размер, он ничем неограничен. Чем действительно может быть 
полезен /dev/ram0 -- для организации промежуточной стадии stage2, когда 
реальный корень распаковывается в RAM из файла, который лежит где-то там...


>   >>> Добавлю от себя лично: в пакете propagotor есть два особенных
>   >>> скрипта. Первый init-bottom "очень дорог для нас". И критичен
>   >>> в плане совместимости. Его бы как-то по-максимуму сохранить.
>   >>> Второй -- mkmodpack. О нём в данном письме речи не идёт.
>   >> А зачем? Грузим ядро, оно находит корневой раздел по метке,
>   >> монтирует его, запускает init... Зачем для этого какие-то
>   >> костыли?
>   > init-bottom обеспечивает работу с read-only носителями, слоями
>   > aufs r/o и r/w, загрузкой по NFS, многими опциями пропагатора.
>
> Я правильно понимаю, что речь прежде всего об унификации этой работы?
> Тогда возникает другой вопрос: а нужна ли она? Или лучше использовать
> более специализированные инструменты для работы с разными носителями?

Скорее "семейные традиции". К примеру, в Debian/Ubuntu -- iniramfs-tools 
+ liveboot и ещё с недавних пор overlayroot (оно немного для другого). А 
у нас ранее remount_rw и доселе init-bottom. Что это и зачем -- всё есть 
в коде и на ВиКи. Альт унифицировал в одном гибридном ISO Legacy и EFI 
загрузку, да ещё и по сети. С учётом выпускаемого числа дистрибутивов, 
стартеркитов и регулярок, это вполне оправдано.


> Впрочем, загрузка live-системы и установка системы на компутер - это
> хоть и взаимосвязанные, но все же отдельные задачи.

Но не с точки зрения организации процесса начальной загрузки. Она у нас 
в stage1 одинакова для всех.


>   > Отрывая этот скрипт полностью, мы теряем возможность предложить со
>   > временем безболезненно перейти с пропагатора на make-initrd-liveboot.
>
> А если не отрывать полностью, но попробовать обойтись без него там,
> где это возможно?

С учётом ограниченного числа его применений, мне сложно представить, как 
без него можно обойтись в тех местах, где он сейчас используется. А в 
других местах его нет, равно как и пропагатора.


-- 
Best regards,
Leonid Krivoshein.

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

[Anton V. Boyarshinov]

On Wed, 11 Apr 2018 10:45:42 +0300 Alexey V. Vissarionov wrote:

> а на второй образ initrd с модулями (опять же, не со всеми, а
> только для поддержки накопителей и сетевых карт) - да, это было
> не просто оправдано, а единственным доступным решением. Я так в
> 1994 году слакварь на 486SX/4/210 ставил :-)
В 1994 году ядро Linux не поддерживало загружемых модулей. На первой
дискете было ядро, а на второй -- rootfs установщика.

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

[Anton V. Boyarshinov]

> Немного подумав, решил озвучить идею. Проблема решаема, если отказаться 
> от тех загрузчиков на ISO Hybrid, что используются сейчас, в пользу 
> syslinux 6+. Тога можно сделать два конфигурационных файла для Legacy и 
> EFI-загрузки, а вот ядро и initramfs сложить в одно место. Поправьте, 
> если я ошибаюсь...
Ядро и initramfs можно просто захардлинкать -- iso9660 это позволяет

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

[Leonid Krivoshein]

13.04.2018 13:07, Anton V. Boyarshinov пишет:
>> Немного подумав, решил озвучить идею. Проблема решаема, если отказаться
>> от тех загрузчиков на ISO Hybrid, что используются сейчас, в пользу
>> syslinux 6+. Тога можно сделать два конфигурационных файла для Legacy и
>> EFI-загрузки, а вот ядро и initramfs сложить в одно место. Поправьте,
>> если я ошибаюсь...
> Ядро и initramfs можно просто захардлинкать -- iso9660 это позволяет
>

В пределах файловой системы -- да. Интересно, почему тогда у нас не 
слинковано? Эту тему хорошо mike@ знает.


-- 
Best regards,
Leonid Krivoshein.

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

[Michael Shigorin]

On Sun, Apr 15, 2018 at 01:32:45AM +0300, Leonid Krivoshein wrote:
> >> Немного подумав, решил озвучить идею. Проблема решаема, если
> >> отказаться от тех загрузчиков на ISO Hybrid, что
> >> используются сейчас, в пользу syslinux 6+. Тога можно
> >> сделать два конфигурационных файла для Legacy и
> >> EFI-загрузки, а вот ядро и initramfs сложить в одно место.
> >> Поправьте, если я ошибаюсь...
> > Ядро и initramfs можно просто захардлинкать -- iso9660 это позволяет
> В пределах файловой системы -- да. Интересно, почему тогда у
> нас не слинковано? Эту тему хорошо mike@ знает.

Потому что там eltorito -- это отдельный fat32-образ.

Сколько я с этим намучился и сколько, поди, икалось
горе-орхитекторам "новой фирмвари", забившим в спеку
fat32 и оставившим "на усмотрение" iso9660...

Конкретно с refind можно сделать ещё один подход
к загрузке его драйвера, но, если не изменяет память,
там получался unzip.zip (iso9660_x64.efi на iso9660)
либо не вытанцевал пути (что осложнялось проблемами
с более новым gnu-efi, которые как-то на эти самые
пути тогда влияли -- помнится, на CWD по умолчанию).
Ну и получалась бы жёсткая привязка к refind,
чего не хотелось.

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