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=-1.4 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 To: make-initrd@lists.altlinux.org References: <19e2c024-e30e-278a-6c33-0d233c9e2fdc@complife.ru> <7631c83d-abb9-a2ec-e3e0-dfbce0c4d578@gmail.com> <20190430192120.GG9023@dhcp129-178.brq.redhat.com> From: "Michael A. Kangin" Message-ID: <9e3ef776-e419-addf-4136-fb3ee4a41d29@complife.ru> Date: Wed, 1 May 2019 16:32:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190430192120.GG9023@dhcp129-178.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru-RU Content-Transfer-Encoding: 8bit Subject: Re: [make-initrd] Network-Manager 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: Wed, 01 May 2019 14:32:04 -0000 Archived-At: List-Archive: On 04/30/2019 09:21 PM, Alexey Gladkov wrote: >>> Да, даже в пропагаторе убирали похожий баг. stage2 поднимает сеть с >>> чистого листа. Фича network должна уметь перед переходом в stage2 >>> опускать всё ранее поднятое. Но тогда как быть с сетевой загрузкой? Либо >>> stage2 должен быть заточен под такой stage1, либо мы сначала выкачиваем >>> из сети всё необходимое, потом опускаем сеть и тогда уже переходим в >>> stage2. >> >> При кешировании образов в памяти - никаких проблем, опускаем сеть и >> пусть stage2 само разбирается. >> >> А вот без кеширования, с NFS это может быть действительно интересно. >> Возможно, из initrd стоит сгенерировать неких конфигов и подложить в >> rootfs для stage2. Проблема в том, что мы не можем быть уверенными, чем >> именно stage2 пользуется - etcnet, NM, systemd-networkd, whatever... По умолчанию нужно стараться сеть класть. Такое поведение и предпочтительнее, и будет покрывать подавляющее большинство сценариев использования. Сеть нужно сохранять только в случаях, когда rootfs смонтировано непосредственно по сети (iSCSI (iBFT), NFS, допустим CIFS), или если образ rootfs не кешируется, и монтируется непосредственно с сетевой шары. Это скорее всего будут довольно редкие случаи, и думается, пусть основная система сама разбирается, как ей обходиться с этими интерфейсами - попытка предугадать все возможные сценарии в initrd скорее всего будет трудоёмка и безблагодатна. Как решать, нужно ли оставлять сеть - спец. параметром, или угадывать на основе используемых фич, видно будет. Может, фича может заказать это, выставив какую-то переменную. То, что интерфейс выглядит unmanaged, может даже и правильно - начнёшь менеджить, рут отвалится. Из основной системы надо будет обязательно проверить, корректно ли продлевается DHCP-лиза, и нормально ли подхватываются переименованные интерфейсы. > > Так может мне не париться и сразу использовать NM в initrd ? > > FYI nm-initrd-generator(8) А это "an early instance of NetworkManager" - оно сколько всего за собой потянет? И насколько пристойно будет выглядеть внутри initrd? Я что-то боюсь этого монстра, а главное, пока не вижу чем бы это помогло решить проблемы с наследованием сети в основной системе.