From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gladkov.alexey@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
 sa.local.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,
 FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no
 version=3.4.1
Date: Thu, 18 Feb 2021 20:37:04 +0100
From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: make-initrd@lists.altlinux.org
Message-ID: <20210218193704.zfa6fl4j75il7xw7@example.org>
References: <20200508114012.jgbjpdksisxryfg4@comp-core-i7-2640m-0182e6>
 <20200521133617.aekvybv5mgpqkvmd@comp-core-i7-2640m-0182e6>
 <88e0982a-556a-55eb-7cf2-e4bfb5fea450@gmail.com>
 <20210218173722.dkyamp42c6gpdigk@example.org>
 <21e48a26-3031-1ffa-cf83-3c524c20cf52@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <21e48a26-3031-1ffa-cf83-3c524c20cf52@gmail.com>
Subject: Re: [make-initrd] I: pipeline feature
X-BeenThere: make-initrd@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: make-initrd@lists.altlinux.org
List-Id: <make-initrd.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/make-initrd>,
 <mailto:make-initrd-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/make-initrd>
List-Post: <mailto:make-initrd@lists.altlinux.org>
List-Help: <mailto:make-initrd-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/make-initrd>,
 <mailto:make-initrd-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 19:37:16 -0000
Archived-At: <http://lore.altlinux.org/make-initrd/20210218193704.zfa6fl4j75il7xw7@example.org/>
List-Archive: <http://lore.altlinux.org/make-initrd/>

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