[make-initrd] I: pipeline feature

[make-initrd] I: pipeline feature

[Alexey Gladkov]

Привет!

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

Pipeline позволяет определить порядок стадий, которые нельзя завязать на
udev и инициализацию устройств.

Сейчас реализовано всего несколько таких стадий: getimage, mountfs,
overlayfs. Стадии могут повторяться т.е. смонтировать и объединить с
помощью overlayfs можно не один squashfs из скачанного образа, а несколько.
Скачать можно также несколько образов.

Пример cmdline:

root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
  getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
  mountfs=rescue

initrd не будет смотреть на локальные диски, а скачает образ, смонтирует
его как loopback, смонтирует поверх overlayfs и попробует загрузить из
него систему т.е. поискать там /sbin/init.

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

P.S. Документации пока минимум, потому что пока не всё ещё закончено.

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Michael Shigorin]

On Fri, May 08, 2020 at 01:40:12PM +0200, Alexey Gladkov wrote:
> root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
>   getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
>   mountfs=rescue

Ой :-)  Если что, это был эксперимент, из которого получилась фича
pid1 в mkimage-profiles и ещё несколько образов "одного актёра":
http://nightly.altlinux.org/sisyphus/just/pid1/

Спасибо, занятная фича.

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

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Fri, May 08, 2020 at 05:20:51PM +0300, Michael Shigorin wrote:
> On Fri, May 08, 2020 at 01:40:12PM +0200, Alexey Gladkov wrote:
> > root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
> >   getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
> >   mountfs=rescue
> 
> Ой :-)  Если что, это был эксперимент, из которого получилась фича
> pid1 в mkimage-profiles и ещё несколько образов "одного актёра":
> http://nightly.altlinux.org/sisyphus/just/pid1/

Да я для тестов взял его поскольку размер самый маленький ))

> Спасибо, занятная фича.

Это может быть кусочком замены m-i-propagator.

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

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


08.05.2020 14:40, Alexey Gladkov пишет:
> Привет!
>
> Я закоммитил новую фичу для поиска рута не основанного на локальных
> устройствах. Проблема в том, что make-initrd достаточно хорошо умеет
> работать с локальными устройствами, но если нужно скачать и смонтировать
> образ (или несколько их), то такие операции не вписываются в локальную
> схему.
>
> Pipeline позволяет определить порядок стадий, которые нельзя завязать на
> udev и инициализацию устройств.
>
> Сейчас реализовано всего несколько таких стадий: getimage, mountfs,
> overlayfs. Стадии могут повторяться т.е. смонтировать и объединить с
> помощью overlayfs можно не один squashfs из скачанного образа, а несколько.
> Скачать можно также несколько образов.
>
> Пример cmdline:
>
> root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
>    getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
>    mountfs=rescue

На самом деле фича офигенная, вот и пришёл кирдык пропагатору! :-)
Надо будет обязательно заюзать. Но пока вижу её только в мастере.


> initrd не будет смотреть на локальные диски, а скачает образ, смонтирует
> его как loopback, смонтирует поверх overlayfs и попробует загрузить из
> него систему т.е. поискать там /sbin/init.

Образ он скачает в ОЗУ, надо полагать? Будет ли при этом поддерживаться 
старый параметр lowmem? Или данный параметр следует считать устаревшим?

Возможно ли включить в pipeline стадию, которая будет дожидаться 
каких-то локальных дисков? Объясню, для чего это может быть полезным. 
Допустим, мы не просто загружаем удалённую систему, а сразу после 
загрузки она должна будет на локальный диск что-то начать записывать или 
наоборот, брать с него какие-то большие файлы. Или же, в этом нет 
необходимости, потому что pipeline и так хорошо взаимодействует с уже 
имеющейся конструкцией?


> Эта фича экспериментальная. Она ещё не закончена и, возможно, с ней может
> случиться что-то нехорошее в будущем.
>
> P.S. Документации пока минимум, потому что пока не всё ещё закончено.
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Sat, May 09, 2020 at 04:08:12PM +0300, Leonid Krivoshein wrote:
> > Пример cmdline:
> > 
> > root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
> >    getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
> >    mountfs=rescue
> 
> На самом деле фича офигенная, вот и пришёл кирдык пропагатору! :-)
> Надо будет обязательно заюзать. Но пока вижу её только в мастере.

Ну да, я же только на этой неделе написал это )) 

> > initrd не будет смотреть на локальные диски, а скачает образ, смонтирует
> > его как loopback, смонтирует поверх overlayfs и попробует загрузить из
> > него систему т.е. поискать там /sbin/init.
> 
> Образ он скачает в ОЗУ, надо полагать?

Пока да. А куда это может скачать initrd ?

> Будет ли при этом поддерживаться старый параметр lowmem? Или данный
> параметр следует считать устаревшим?

lowmem позволяет монтировать squashfs непосредственно с носителя. У меня
есть стадия mountfs и она монтирует всё что угодно. Пока эта стадия не
ждёт устройств, но если устройство (любое) уже существует, то его можно
смонтировать на этой стадии.

Стадия getimage скачивает образ главным образом из сети. Его скачать можно
либо в RAM, либо на носитель, который уже будет смонтирован.

> Возможно ли включить в pipeline стадию, которая будет дожидаться каких-то
> локальных дисков?

Для того чтобы собрать недостающие хотелки я и опубликовал эту фичу.

Да, можно сделать стадию waitblock и параметром waitblock=SPEC.

> Объясню, для чего это может быть полезным. Допустим, мы не
> просто загружаем удалённую систему, а сразу после загрузки она должна будет
> на локальный диск что-то начать записывать или наоборот, брать с него
> какие-то большие файлы. Или же, в этом нет необходимости, потому что
> pipeline и так хорошо взаимодействует с уже имеющейся конструкцией?

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

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Sat, May 09, 2020 at 04:08:12PM +0300, Leonid Krivoshein wrote:
> Возможно ли включить в pipeline стадию, которая будет дожидаться каких-то
> локальных дисков?

Добавил в репозиторий плохо протестированный waitdev, который ждёт
указанное устройство.

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Fri, May 08, 2020 at 01:40:12PM +0200, Alexey Gladkov wrote:
> Привет!
> 
> Я закоммитил новую фичу для поиска рута не основанного на локальных
> устройствах. Проблема в том, что make-initrd достаточно хорошо умеет
> работать с локальными устройствами, но если нужно скачать и смонтировать
> образ (или несколько их), то такие операции не вписываются в локальную
> схему.
> 
> Pipeline позволяет определить порядок стадий, которые нельзя завязать на
> udev и инициализацию устройств.
> 
> Сейчас реализовано всего несколько таких стадий: getimage, mountfs,
> overlayfs. Стадии могут повторяться т.е. смонтировать и объединить с
> помощью overlayfs можно не один squashfs из скачанного образа, а несколько.
> Скачать можно также несколько образов.
> 
> Пример cmdline:
> 
> root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
>   getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
>   mountfs=rescue
> 
> initrd не будет смотреть на локальные диски, а скачает образ, смонтирует
> его как loopback, смонтирует поверх overlayfs и попробует загрузить из
> него систему т.е. поискать там /sbin/init.
> 
> Эта фича экспериментальная. Она ещё не закончена и, возможно, с ней может
> случиться что-то нехорошее в будущем.
> 
> P.S. Документации пока минимум, потому что пока не всё ещё закончено.

Исправил ошибки и теперь оно в каком-то виде точно работает. Сделал тест,
который берёт корень из squashfs из iso, который из /dev/cdrom.

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

Привет!


21.05.2020 16:36, Alexey Gladkov пишет:
> On Fri, May 08, 2020 at 01:40:12PM +0200, Alexey Gladkov wrote:
>> Привет!
>>
>> Я закоммитил новую фичу для поиска рута не основанного на локальных
>> устройствах. Проблема в том, что make-initrd достаточно хорошо умеет
>> работать с локальными устройствами, но если нужно скачать и смонтировать
>> образ (или несколько их), то такие операции не вписываются в локальную
>> схему.
>>
>> Pipeline позволяет определить порядок стадий, которые нельзя завязать на
>> udev и инициализацию устройств.
>>
>> Сейчас реализовано всего несколько таких стадий: getimage, mountfs,
>> overlayfs. Стадии могут повторяться т.е. смонтировать и объединить с
>> помощью overlayfs можно не один squashfs из скачанного образа, а несколько.
>> Скачать можно также несколько образов.
>>
>> Пример cmdline:
>>
>> root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
>>    getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
>>    mountfs=rescue
>>
>> initrd не будет смотреть на локальные диски, а скачает образ, смонтирует
>> его как loopback, смонтирует поверх overlayfs и попробует загрузить из
>> него систему т.е. поискать там /sbin/init.
>>
>> Эта фича экспериментальная. Она ещё не закончена и, возможно, с ней может
>> случиться что-то нехорошее в будущем.
>>
>> P.S. Документации пока минимум, потому что пока не всё ещё закончено.
> Исправил ошибки и теперь оно в каком-то виде точно работает. Сделал тест,
> который берёт корень из squashfs из iso, который из /dev/cdrom.
>

Получится ли использовать эту фичу, чтобы дождаться сборки других 
рейдов, не связанных с корневым разделом? Дело в том, что сейчас 
make-initrd всеми правдами может собрать рейд, на котором есть корневой 
раздел, но если на внешней корзине много дисков и там несколько более 
сложных рейдов, с корнем не связанных, они собраться не успевают до 
pivot_root, так что правила systemd во второй стадии загрузки их тоже не 
могут собрать, так как там стоит защита от состояния "inactive". Грубо 
говоря, в простом случае тут хватило бы какой-то простой задержки, иначе 
начальная загрузка ломает собираемость больших рейдов с данными.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 07:55:31PM +0300, Leonid Krivoshein wrote:
> Привет!
> 
> 
> 21.05.2020 16:36, Alexey Gladkov пишет:
> > On Fri, May 08, 2020 at 01:40:12PM +0200, Alexey Gladkov wrote:
> > > Привет!
> > > 
> > > Я закоммитил новую фичу для поиска рута не основанного на локальных
> > > устройствах. Проблема в том, что make-initrd достаточно хорошо умеет
> > > работать с локальными устройствами, но если нужно скачать и смонтировать
> > > образ (или несколько их), то такие операции не вписываются в локальную
> > > схему.
> > > 
> > > Pipeline позволяет определить порядок стадий, которые нельзя завязать на
> > > udev и инициализацию устройств.
> > > 
> > > Сейчас реализовано всего несколько таких стадий: getimage, mountfs,
> > > overlayfs. Стадии могут повторяться т.е. смонтировать и объединить с
> > > помощью overlayfs можно не один squashfs из скачанного образа, а несколько.
> > > Скачать можно также несколько образов.
> > > 
> > > Пример cmdline:
> > > 
> > > root=pipeline pipeline=getimage,mountfs,overlayfs,rootfs \
> > >    getimage=http://ftp.altlinux.org/pub/people/mike/iso/misc/vi-20140918-i586.iso \
> > >    mountfs=rescue
> > > 
> > > initrd не будет смотреть на локальные диски, а скачает образ, смонтирует
> > > его как loopback, смонтирует поверх overlayfs и попробует загрузить из
> > > него систему т.е. поискать там /sbin/init.
> > > 
> > > Эта фича экспериментальная. Она ещё не закончена и, возможно, с ней может
> > > случиться что-то нехорошее в будущем.
> > > 
> > > P.S. Документации пока минимум, потому что пока не всё ещё закончено.
> > Исправил ошибки и теперь оно в каком-то виде точно работает. Сделал тест,
> > который берёт корень из squashfs из iso, который из /dev/cdrom.
> > 
> 
> Получится ли использовать эту фичу, чтобы дождаться сборки других рейдов, не
> связанных с корневым разделом? Дело в том, что сейчас make-initrd всеми
> правдами может собрать рейд, на котором есть корневой раздел, но если на
> внешней корзине много дисков и там несколько более сложных рейдов, с корнем
> не связанных, они собраться не успевают до pivot_root, так что правила
> systemd во второй стадии загрузки их тоже не могут собрать, так как там
> стоит защита от состояния "inactive". Грубо говоря, в простом случае тут
> хватило бы какой-то простой задержки, иначе начальная загрузка ломает
> собираемость больших рейдов с данными.

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

Я не очень понял описанную проблему.

"Всеми правдами" это вы имеете в виду стандартные правила сборки рейда из
самого mdadm ?

Если не хватает времени, то есть rootdelay=X, который можно выставить хоть
в сутки. Также есть параметр raid-member-delay=X через который можно
отключить получение degraded raid. Правильное указание этих параметров
должно решать описанную проблему.

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

18.02.2021 20:38, Alexey Gladkov пишет:
> On Thu, Feb 18, 2021 at 07:55:31PM +0300, Leonid Krivoshein wrote:
>> Привет!
>>
>>
>> [...]
>> Получится ли использовать эту фичу, чтобы дождаться сборки других рейдов, не
>> связанных с корневым разделом? Дело в том, что сейчас make-initrd всеми
>> правдами может собрать рейд, на котором есть корневой раздел, но если на
>> внешней корзине много дисков и там несколько более сложных рейдов, с корнем
>> не связанных, они собраться не успевают до pivot_root, так что правила
>> systemd во второй стадии загрузки их тоже не могут собрать, так как там
>> стоит защита от состояния "inactive". Грубо говоря, в простом случае тут
>> хватило бы какой-то простой задержки, иначе начальная загрузка ломает
>> собираемость больших рейдов с данными.
> Эта фича не про рейды совсем.

Понял.


> Попросить make-initrd смонитровать не только
> корнефой раздел можно другими методами.

Отлично! Об этом смотри в самом конце..


> Я не очень понял описанную проблему.

https://bugzilla.altlinux.org/39695


> "Всеми правдами" это вы имеете в виду стандартные правила сборки рейда из
> самого mdadm ?

Имел ввиду, что в make-initrd есть "лекарство" для загрузки с read-only 
и деградированных рейдов, т.е. когда с ними не всё в порядке, но данные 
в принципе доступны. 
http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/handlers/md-raid-member/100-timeout;h=96e07da66ee6e7e0ecac6b34359e861a6c0d2d9b;hb=4731c727c756c15776a020780828fa5e33ddef7a

То есть, рейд с корнем он соберёт даже в довольно плохом случае.


> Если не хватает времени, то есть rootdelay=X, который можно выставить хоть
> в сутки. Также есть параметр raid-member-delay=X через который можно
> отключить получение degraded raid. Правильное указание этих параметров
> должно решать описанную проблему.

Не помогло (см. в баге). Уже немного разобрался, почему так происходит и 
даже придумал временный объезд. Возможно, простой способ ПРАВИЛЬНО 
решить проблему -- иметь два _РАЗНЫХ_ /etc/mdadm.conf на такие случаи, 
когда рейды используются не для корня. Главное, чтобы эти рейды с 
данными не начинал собирать интеллект в initramfs (ограничить 
DEVICES=...), тогда в обычной системе правила udev сами его соберут.

Сейчас проблема в том, что процесс assembly запускается, но успевает 
отрабатывать лишь для простого RAID1 с корнем, а остальные RAID6 с кучей 
дисков просто не успевают собраться и, как я полагаю, состояние inactive 
во второй стадии мешает их собрать штатным правилам udev. Грубо говоря, 
наличие второго конфига типа /etc/mdadm-initrd.conf решило бы проблему 
-- если такой файл есть, тянут в initramfs его, если нет, тянуть обычный 
конфиг.

Однако, есть одно сомнение: make-initrd монтирует только корень или 
что-то ещё из /etc/fstab? Если он монтирует всё, то предложенный 
воркэраунд не поможет. Тогда хорошо бы скармливать какими-нибудь 
параметрами, каких ещё дисков (событий) следует дождаться до pivot_root...


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 09:18:46PM +0300, Leonid Krivoshein wrote:
> 
> 18.02.2021 20:38, Alexey Gladkov пишет:
> > On Thu, Feb 18, 2021 at 07:55:31PM +0300, Leonid Krivoshein wrote:
> > > Привет!
> > > 
> > > 
> > > [...]
> > > Получится ли использовать эту фичу, чтобы дождаться сборки других рейдов, не
> > > связанных с корневым разделом? Дело в том, что сейчас make-initrd всеми
> > > правдами может собрать рейд, на котором есть корневой раздел, но если на
> > > внешней корзине много дисков и там несколько более сложных рейдов, с корнем
> > > не связанных, они собраться не успевают до pivot_root, так что правила
> > > systemd во второй стадии загрузки их тоже не могут собрать, так как там
> > > стоит защита от состояния "inactive". Грубо говоря, в простом случае тут
> > > хватило бы какой-то простой задержки, иначе начальная загрузка ломает
> > > собираемость больших рейдов с данными.
> > Эта фича не про рейды совсем.
> 
> Понял.
> 
> 
> > Попросить make-initrd смонитровать не только
> > корнефой раздел можно другими методами.
> 
> Отлично! Об этом смотри в самом конце..
> 
> 
> > Я не очень понял описанную проблему.
> 
> https://bugzilla.altlinux.org/39695
> 
> 
> > "Всеми правдами" это вы имеете в виду стандартные правила сборки рейда из
> > самого mdadm ?
> 
> Имел ввиду, что в make-initrd есть "лекарство" для загрузки с read-only и
> деградированных рейдов, т.е. когда с ними не всё в порядке, но данные в
> принципе доступны. http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/handlers/md-raid-member/100-timeout;h=96e07da66ee6e7e0ecac6b34359e861a6c0d2d9b;hb=4731c727c756c15776a020780828fa5e33ddef7a
> 
> То есть, рейд с корнем он соберёт даже в довольно плохом случае.
> 
> 
> > Если не хватает времени, то есть rootdelay=X, который можно выставить хоть
> > в сутки. Также есть параметр raid-member-delay=X через который можно
> > отключить получение degraded raid. Правильное указание этих параметров
> > должно решать описанную проблему.
> 
> Не помогло (см. в баге).

Это не помогло так как initrd не ждал эти разделы [1] и как только корень
был смонтирован, то сразу же загрузка пошла дальше. Можно указать, чтобы
монтировал все указанные рейды, но тогда initrd их смонтирует. Это
конечно не то, что ожидается.

Проблема в том, что mdadm.conf берётся из системы и содержит все рейды.

> Уже немного разобрался, почему так происходит и
> даже придумал временный объезд. Возможно, простой способ ПРАВИЛЬНО решить
> проблему -- иметь два _РАЗНЫХ_ /etc/mdadm.conf на такие случаи, когда рейды
> используются не для корня. Главное, чтобы эти рейды с данными не начинал
> собирать интеллект в initramfs (ограничить DEVICES=...), тогда в обычной
> системе правила udev сами его соберут.

Я тоже мыслю в эту сторону [2].  Я подумываю о том, как бы сгенерировать
mdadm.conf только для MOUNTPOINTS.  К сожалению, я не уверен, что это
можно хорошо сделать. Именно поэтому я и не сделал этого сразу для фичи
mdadm.

> Сейчас проблема в том, что процесс assembly запускается, но успевает
> отрабатывать лишь для простого RAID1 с корнем, а остальные RAID6 с кучей
> дисков просто не успевают собраться и, как я полагаю, состояние inactive во
> второй стадии мешает их собрать штатным правилам udev. Грубо говоря, наличие
> второго конфига типа /etc/mdadm-initrd.conf решило бы проблему -- если такой
> файл есть, тянут в initramfs его, если нет, тянуть обычный конфиг.

Я согласен. Вопрос в том, как получить конфиг для mountpoints'а.

> Однако, есть одно сомнение: make-initrd монтирует только корень или что-то
> ещё из /etc/fstab?

make-initrd генерирует себе fstab с тем, что его попросили смонтировать.
Соответственно ждёт он всех из своего fstab (если не сказали rootonly при
загрузке).

> Если он монтирует всё, то предложенный воркэраунд не
> поможет. Тогда хорошо бы скармливать какими-нибудь параметрами, каких ещё
> дисков (событий) следует дождаться до pivot_root...

[1] https://github.com/osboot/make-initrd/blob/master/data/lib/initrd/boot/scripts/mountpoints
[2] https://bugzilla.altlinux.org/show_bug.cgi?id=29831
[3] https://github.com/osboot/make-initrd/blob/master/features/rootfs/bin/create-fstab

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

18.02.2021 22:37, Alexey Gladkov пишет:
> On Thu, Feb 18, 2021 at 09:18:46PM +0300, Leonid Krivoshein wrote:
>> 18.02.2021 20:38, Alexey Gladkov пишет:
>>> On Thu, Feb 18, 2021 at 07:55:31PM +0300, Leonid Krivoshein wrote:
>>>> Привет!
>>>>
>>>>
>>>> [...]
>>>> Получится ли использовать эту фичу, чтобы дождаться сборки других рейдов, не
>>>> связанных с корневым разделом? Дело в том, что сейчас make-initrd всеми
>>>> правдами может собрать рейд, на котором есть корневой раздел, но если на
>>>> внешней корзине много дисков и там несколько более сложных рейдов, с корнем
>>>> не связанных, они собраться не успевают до pivot_root, так что правила
>>>> systemd во второй стадии загрузки их тоже не могут собрать, так как там
>>>> стоит защита от состояния "inactive". Грубо говоря, в простом случае тут
>>>> хватило бы какой-то простой задержки, иначе начальная загрузка ломает
>>>> собираемость больших рейдов с данными.
>>> Эта фича не про рейды совсем.
>> Понял.
>>
>>
>>> Попросить make-initrd смонитровать не только
>>> корнефой раздел можно другими методами.
>> Отлично! Об этом смотри в самом конце..
>>
>>
>>> Я не очень понял описанную проблему.
>> https://bugzilla.altlinux.org/39695
>>
>>
>>> "Всеми правдами" это вы имеете в виду стандартные правила сборки рейда из
>>> самого mdadm ?
>> Имел ввиду, что в make-initrd есть "лекарство" для загрузки с read-only и
>> деградированных рейдов, т.е. когда с ними не всё в порядке, но данные в
>> принципе доступны. http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/handlers/md-raid-member/100-timeout;h=96e07da66ee6e7e0ecac6b34359e861a6c0d2d9b;hb=4731c727c756c15776a020780828fa5e33ddef7a
>>
>> То есть, рейд с корнем он соберёт даже в довольно плохом случае.
>>
>>
>>> Если не хватает времени, то есть rootdelay=X, который можно выставить хоть
>>> в сутки. Также есть параметр raid-member-delay=X через который можно
>>> отключить получение degraded raid. Правильное указание этих параметров
>>> должно решать описанную проблему.
>> Не помогло (см. в баге).
> Это не помогло так как initrd не ждал эти разделы [1] и как только корень
> был смонтирован, то сразу же загрузка пошла дальше. Можно указать, чтобы
> монтировал все указанные рейды, но тогда initrd их смонтирует. Это
> конечно не то, что ожидается.

Почему, вполне годное решение. А как это указать? Добавить mountpoints= 
к параметрам загрузки?


> Проблема в том, что mdadm.conf берётся из системы и содержит все рейды.
>
>> Уже немного разобрался, почему так происходит и
>> даже придумал временный объезд. Возможно, простой способ ПРАВИЛЬНО решить
>> проблему -- иметь два _РАЗНЫХ_ /etc/mdadm.conf на такие случаи, когда рейды
>> используются не для корня. Главное, чтобы эти рейды с данными не начинал
>> собирать интеллект в initramfs (ограничить DEVICES=...), тогда в обычной
>> системе правила udev сами его соберут.
> Я тоже мыслю в эту сторону [2].  Я подумываю о том, как бы сгенерировать
> mdadm.conf только для MOUNTPOINTS.  К сожалению, я не уверен, что это
> можно хорошо сделать. Именно поэтому я и не сделал этого сразу для фичи
> mdadm.

Поэтому я и предложил затягивать в initramfs один из двух файлов:

/etc/mdadm-initrd.conf (если есть, то его)
/etc/mdadm.conf (fallback)

Пусть болит голова у админов))


>> Сейчас проблема в том, что процесс assembly запускается, но успевает
>> отрабатывать лишь для простого RAID1 с корнем, а остальные RAID6 с кучей
>> дисков просто не успевают собраться и, как я полагаю, состояние inactive во
>> второй стадии мешает их собрать штатным правилам udev. Грубо говоря, наличие
>> второго конфига типа /etc/mdadm-initrd.conf решило бы проблему -- если такой
>> файл есть, тянут в initramfs его, если нет, тянуть обычный конфиг.
> Я согласен. Вопрос в том, как получить конфиг для mountpoints'а.
>
>> Однако, есть одно сомнение: make-initrd монтирует только корень или что-то
>> ещё из /etc/fstab?
> make-initrd генерирует себе fstab с тем, что его попросили смонтировать.
> Соответственно ждёт он всех из своего fstab (если не сказали rootonly при
> загрузке).
>
>> Если он монтирует всё, то предложенный воркэраунд не
>> поможет. Тогда хорошо бы скармливать какими-нибудь параметрами, каких ещё
>> дисков (событий) следует дождаться до pivot_root...
> [1] https://github.com/osboot/make-initrd/blob/master/data/lib/initrd/boot/scripts/mountpoints
> [2] https://bugzilla.altlinux.org/show_bug.cgi?id=29831
> [3] https://github.com/osboot/make-initrd/blob/master/features/rootfs/bin/create-fstab
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 11:29:04PM +0300, Leonid Krivoshein wrote:
> > Это не помогло так как initrd не ждал эти разделы [1] и как только корень
> > был смонтирован, то сразу же загрузка пошла дальше. Можно указать, чтобы
> > монтировал все указанные рейды, но тогда initrd их смонтирует. Это
> > конечно не то, что ожидается.
> 
> Почему, вполне годное решение. А как это указать? Добавить mountpoints= к
> параметрам загрузки?

Сейчас при загрузке можно только переопределить параметры корня [1].
Дополнительные точки можно указать двумя способами:

* Добавить параметр x-initrd-mount в опции в fstab;
* Просто сделать добавить нужную точку монтирования в MOUNTPOINTS.
  Например: MOUNTPOINTS += /boot

> > > Уже немного разобрался, почему так происходит и
> > > даже придумал временный объезд. Возможно, простой способ ПРАВИЛЬНО решить
> > > проблему -- иметь два _РАЗНЫХ_ /etc/mdadm.conf на такие случаи, когда рейды
> > > используются не для корня. Главное, чтобы эти рейды с данными не начинал
> > > собирать интеллект в initramfs (ограничить DEVICES=...), тогда в обычной
> > > системе правила udev сами его соберут.
> > Я тоже мыслю в эту сторону [2].  Я подумываю о том, как бы сгенерировать
> > mdadm.conf только для MOUNTPOINTS.  К сожалению, я не уверен, что это
> > можно хорошо сделать. Именно поэтому я и не сделал этого сразу для фичи
> > mdadm.
> 
> Поэтому я и предложил затягивать в initramfs один из двух файлов:
> 
> /etc/mdadm-initrd.conf (если есть, то его)
> /etc/mdadm.conf (fallback)

Как быстрое решение это может сработать. Нужно только удостовериться, что
это решит упомянутые в треде баги. Мне в одной из багов говорят, что
специальный mdadm.conf не помогает с RAID1.

> Пусть болит голова у админов))

На этих товарищей я бы не надеялся ))

[1] https://github.com/osboot/make-initrd/blob/master/data/etc/rc.d/init.d/fstab#L84

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

19.02.2021 13:49, Alexey Gladkov пишет:
> On Thu, Feb 18, 2021 at 11:29:04PM +0300, Leonid Krivoshein wrote:
>>> Это не помогло так как initrd не ждал эти разделы [1] и как только корень
>>> был смонтирован, то сразу же загрузка пошла дальше. Можно указать, чтобы
>>> монтировал все указанные рейды, но тогда initrd их смонтирует. Это
>>> конечно не то, что ожидается.
>> Почему, вполне годное решение. А как это указать? Добавить mountpoints= к
>> параметрам загрузки?
> Сейчас при загрузке можно только переопределить параметры корня [1].
> Дополнительные точки можно указать двумя способами:
>
> * Добавить параметр x-initrd-mount в опции в fstab;
> * Просто сделать добавить нужную точку монтирования в MOUNTPOINTS.
>    Например: MOUNTPOINTS += /boot

Ага, спасибо! То, что надо...


>>>> Уже немного разобрался, почему так происходит и
>>>> даже придумал временный объезд. Возможно, простой способ ПРАВИЛЬНО решить
>>>> проблему -- иметь два _РАЗНЫХ_ /etc/mdadm.conf на такие случаи, когда рейды
>>>> используются не для корня. Главное, чтобы эти рейды с данными не начинал
>>>> собирать интеллект в initramfs (ограничить DEVICES=...), тогда в обычной
>>>> системе правила udev сами его соберут.
>>> Я тоже мыслю в эту сторону [2].  Я подумываю о том, как бы сгенерировать
>>> mdadm.conf только для MOUNTPOINTS.  К сожалению, я не уверен, что это
>>> можно хорошо сделать. Именно поэтому я и не сделал этого сразу для фичи
>>> mdadm.
>> Поэтому я и предложил затягивать в initramfs один из двух файлов:
>>
>> /etc/mdadm-initrd.conf (если есть, то его)
>> /etc/mdadm.conf (fallback)
> Как быстрое решение это может сработать. Нужно только удостовериться, что
> это решит упомянутые в треде баги. Мне в одной из багов говорят, что
> специальный mdadm.conf не помогает с RAID1.

Там возможно упущено:

-DEVICE = partitions
+DEVICE = /dev/ROOTDEVS

далее запуск make-initrd

Плюс к тому: до перезапуска я бы руками отмонтировал /boot и остановил 
его рейд. Иначе он тоже может натыкаться на inactive во второй стадии 
загрузки.

Если его загрузчик собирает массив, чтобы загрузить ядро/initrd, не 
удивительно, что этот рейд "грязный". Мне кажется, ему поможет 
"лекарство" для второй стадии, подобное тому, что есть в initramfs. Но 
мы его пока не реализовали. :-) Сначала я бы провёл диагностику в режиме 
forensic.


>> Пусть болит голова у админов))
> На этих товарищей я бы не надеялся ))
>
> [1] https://github.com/osboot/make-initrd/blob/master/data/etc/rc.d/init.d/fstab#L84
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

19.02.2021 13:49, Alexey Gladkov пишет:
> [...]
>> Поэтому я и предложил затягивать в initramfs один из двух файлов:
>>
>> /etc/mdadm-initrd.conf (если есть, то его)
>> /etc/mdadm.conf (fallback)
> Как быстрое решение это может сработать. Нужно только удостовериться, что
> это решит упомянутые в треде баги.

Да, решило: https://bugzilla.altlinux.org/show_bug.cgi?id=39695#c9

Причём, что удивительно, там хоть нет и нет inactive, но есть resync 
после ребута, значит какие-то костылики udev-rules уже работают во 
второй стадии.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Sat, Feb 20, 2021 at 12:58:03PM +0300, Leonid Krivoshein wrote:
> 
> 19.02.2021 13:49, Alexey Gladkov пишет:
> > [...]
> > > Поэтому я и предложил затягивать в initramfs один из двух файлов:
> > > 
> > > /etc/mdadm-initrd.conf (если есть, то его)
> > > /etc/mdadm.conf (fallback)
> > Как быстрое решение это может сработать. Нужно только удостовериться, что
> > это решит упомянутые в треде баги.
> 
> Да, решило: https://bugzilla.altlinux.org/show_bug.cgi?id=39695#c9
> 
> Причём, что удивительно, там хоть нет и нет inactive, но есть resync после
> ребута, значит какие-то костылики udev-rules уже работают во второй стадии.

Есть подозрение, что для создания mdadm.conf достаточно:

mddev=$(findmnt -n -o SOURCE "$mountpoint")
mdadm --verbose --detail --scan "$mddev" > mdadm.conf

Можно придумать такую последовательность:

1. Если есть /etc/mdadm-initrd.conf, то берём его.
2. Если в /etc/mdadm.conf только один ARRAY, то можно брать его.
3. Если ARRAY в /etc/mdadm.conf больше одного, то генерируем свой.

или же можно просто пропустить второй шаг и если нет mdadm-initrd.conf, то
сразу генерировать конфиг.

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Leonid Krivoshein]

20.02.2021 13:31, Alexey Gladkov пишет:
> On Sat, Feb 20, 2021 at 12:58:03PM +0300, Leonid Krivoshein wrote:
>> 19.02.2021 13:49, Alexey Gladkov пишет:
>>> [...]
>>>> Поэтому я и предложил затягивать в initramfs один из двух файлов:
>>>>
>>>> /etc/mdadm-initrd.conf (если есть, то его)
>>>> /etc/mdadm.conf (fallback)
>>> Как быстрое решение это может сработать. Нужно только удостовериться, что
>>> это решит упомянутые в треде баги.
>> Да, решило: https://bugzilla.altlinux.org/show_bug.cgi?id=39695#c9
>>
>> Причём, что удивительно, там хоть нет и нет inactive, но есть resync после
>> ребута, значит какие-то костылики udev-rules уже работают во второй стадии.
> Есть подозрение, что для создания mdadm.conf достаточно:
>
> mddev=$(findmnt -n -o SOURCE "$mountpoint")
> mdadm --verbose --detail --scan "$mddev" > mdadm.conf

Видимо тут опечатка:

... >> mdadm.conf


> Можно придумать такую последовательность:
>
> 1. Если есть /etc/mdadm-initrd.conf, то берём его.
> 2. Если в /etc/mdadm.conf только один ARRAY, то можно брать его.
> 3. Если ARRAY в /etc/mdadm.conf больше одного, то генерируем свой.

Разумный алгоритм! Вопрос лишь в том, как в п.3 выбрать нужный массив.


> или же можно просто пропустить второй шаг и если нет mdadm-initrd.conf, то
> сразу генерировать конфиг.

Как я понимаю, сейчас не для всех MOUNTPOINTS дотягиваются нужные модули 
в initramfs, это уже другой баг с /boot.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] I: pipeline feature

[Alexey Gladkov]

On Sat, Feb 20, 2021 at 02:05:01PM +0300, Leonid Krivoshein wrote:
> 
> 20.02.2021 13:31, Alexey Gladkov пишет:
> > On Sat, Feb 20, 2021 at 12:58:03PM +0300, Leonid Krivoshein wrote:
> > > 19.02.2021 13:49, Alexey Gladkov пишет:
> > > > [...]
> > > > > Поэтому я и предложил затягивать в initramfs один из двух файлов:
> > > > > 
> > > > > /etc/mdadm-initrd.conf (если есть, то его)
> > > > > /etc/mdadm.conf (fallback)
> > > > Как быстрое решение это может сработать. Нужно только удостовериться, что
> > > > это решит упомянутые в треде баги.
> > > Да, решило: https://bugzilla.altlinux.org/show_bug.cgi?id=39695#c9
> > > 
> > > Причём, что удивительно, там хоть нет и нет inactive, но есть resync после
> > > ребута, значит какие-то костылики udev-rules уже работают во второй стадии.
> > Есть подозрение, что для создания mdadm.conf достаточно:
> > 
> > mddev=$(findmnt -n -o SOURCE "$mountpoint")
> > mdadm --verbose --detail --scan "$mddev" > mdadm.conf
> 
> Видимо тут опечатка:
> 
> ... >> mdadm.conf

Нет. Это будет весь конфиг.

Посмотрев на вывод mdadm, я бы ещё чуть-чуть отредактировал вывод.

mdadm --verbose --detail --scan "$mddev" |
	tr '\n' ' ' |
	sed -r \
		-e 's/^(.*[[:space:]])devices=[^[:space:]]+([[:space:]].*)$/\1\2/' \
		-e 's/^(.*[[:space:]])name=\(none\):[^[:space:]]+([[:space:]].*)$/\1\2/'

В devices указываются файлы устройств, что не очень хорошо. Можно также
добавить первой строчкой:

echo 'DEVICE partitions'

> > Можно придумать такую последовательность:
> > 
> > 1. Если есть /etc/mdadm-initrd.conf, то берём его.
> > 2. Если в /etc/mdadm.conf только один ARRAY, то можно брать его.
> > 3. Если ARRAY в /etc/mdadm.conf больше одного, то генерируем свой.
> 
> Разумный алгоритм! Вопрос лишь в том, как в п.3 выбрать нужный массив.

Выбрать как раз совсем не сложно. Мы же определяем, что нашли raid в
цепочке [1]. В "$SYSFS_PATH$1"/dev есть major:minor устройства. Далее
можно просто посмотреть findmnt -n -o MAJ:MIN,SOURCE и найти устройство,
если не хочется делать mknod. А далее будет работать уже указанный код.

> > или же можно просто пропустить второй шаг и если нет mdadm-initrd.conf, то
> > сразу генерировать конфиг.
> 
> Как я понимаю, сейчас не для всех MOUNTPOINTS дотягиваются нужные модули в
> initramfs, это уже другой баг с /boot.

Для всех [2]. Иначе в MOUNTPOINTS не было бы никакого смысла. Вот только
никто не просил make-initrd искать модули рейда для /boot.

Я пока не сделал тест и не могу с уверенностью утверждать, но мне кажется,
что mdadm и его udev-правила как-то учитывают, описанный в mdadm.conf
/boot.

[1] https://github.com/osboot/make-initrd/blob/master/features/mdadm/guess/device
[2] https://github.com/osboot/make-initrd/blob/master/guess/root/action#L180

-- 
Rgrds, legion

Re: [make-initrd] I: pipeline feature

[Michael Shigorin]

On Sat, Feb 20, 2021 at 11:31:51AM +0100, Alexey Gladkov wrote:
> Есть подозрение, что для создания mdadm.conf достаточно:
> 
> mddev=$(findmnt -n -o SOURCE "$mountpoint")
> mdadm --verbose --detail --scan "$mddev" > mdadm.conf
> 
> Можно придумать такую последовательность:
> 
> 1. Если есть /etc/mdadm-initrd.conf, то берём его.
> 2. Если в /etc/mdadm.conf только один ARRAY, то можно брать его.
> 3. Если ARRAY в /etc/mdadm.conf больше одного, то генерируем свой.
> 
> или же можно просто пропустить второй шаг и если нет
> mdadm-initrd.conf, то сразу генерировать конфиг.

(я тут сбоку тихонько морально поддерживаю,
припоминая, как несколько лет назад возился
со схожими вопросами)

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