From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=WavSdrFBS6nS6h8byxPlONTZJJxtEIApwo0Utd9PXrw=; b=t9S+h7u1Nb8ENiv8RS9cd8LnJcC+F+hx3JLQOc0sdzXbzA8NXjofG+UXZK/D9qxfVh R6DiE/vmnq7bKUP/JTBuitCAWLJxmIFoT+JldVUK6dh1WdTiCba0RIBoxXJJKV05Bc+J mEqIRdPtuWq/bP+MlmzD9uFJWoTuxUlDkMCTEdQA9DfapwXKsROcxegUAGp/nm7pZ+Qz j7U9/2gQpACGx5Kw9CXafVQ+YEOnjH8Ne8zxUdvqzFyI2htqMq6d6HZARA4mBOQ4piYR IqEWHO00Ws3FCUmnTYTE5TePkvDoj+Xsgxrq4BYelebpCNwOdKm54qMurYEvyu5sb4pY ihHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WavSdrFBS6nS6h8byxPlONTZJJxtEIApwo0Utd9PXrw=; b=Y7f+XN5iQ36JK5olMyAE0lkbnmuYksUadvHEwyb49Isj1/AktkB+VYp1BFUcLkxxEn J37+s1sqGXnWw24i/WZ9jGG1/QqnwxYxDtBZA+G1EaJ3R6Bq+DepOStVXI+G12R03OBj lqpkzXhEfJBpEVdWsCO7IT0tWPWgPeow4yCohqo/EC4llEE0MSEd4rBfJCsh1A9OFBAo arebAdh7WJQd9lVyoq2C6K5JtPT+22KlPdFxhdv9EMkNl1wZvUcgQaH03xsrJaPkpsHB vSxM8LTI5jnVlGDsGa7s+t0wTSR7CiPKvqCGYGSqam1NUuVrXaVUJreEENnJ5MSLUITi nMLg== X-Gm-Message-State: AOAM5314nTaFNHzKrqNxQwitgCBivJd+8ZlF+xzdlLTxHv0ilQKpb6UM tZBoDPMhtUD72zWmN7vyKWDGZydh138= X-Google-Smtp-Source: ABdhPJxW7h5hzdvk3M5z/JLbHmPkfgj7KjseR7kUlR4cNHgYcfI9U+zwLkFsj9UE34VIP+bLyNw9gQ== X-Received: by 2002:a2e:730d:: with SMTP id o13mr3200194ljc.396.1613672327956; Thu, 18 Feb 2021 10:18:47 -0800 (PST) To: make-initrd@lists.altlinux.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> From: Leonid Krivoshein Message-ID: <21e48a26-3031-1ffa-cf83-3c524c20cf52@gmail.com> Date: Thu, 18 Feb 2021 21:18:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210218173722.dkyamp42c6gpdigk@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 18:18:50 -0000 Archived-At: List-Archive: 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.