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> From: "Michael A. Kangin" Message-ID: Date: Tue, 30 Apr 2019 15:04:12 +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: <7631c83d-abb9-a2ec-e3e0-dfbce0c4d578@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: ru-RU Content-Transfer-Encoding: 8bit Subject: Re: [make-initrd] CLB 2 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: Tue, 30 Apr 2019 13:04:15 -0000 Archived-At: List-Archive: On 04/30/2019 02:35 PM, Leonid Krivoshein wrote: >> Леонид, что вы еще хотели от фичи liveboot? > Вообще хотелось бы загрузки с флэшек, с CD/DVD и по сети Это поддерживается, при необходимых модулях Можно обращаться к устройствам по их именам в /dev, по UUID и LABEL > в объёме пропагатора, там какой-то специальный объём или требования? > а для начала хотя бы один из протоколов реализовать, типа > NFS. Для NFSа нужно будет немного дописать функциональность (когда понятно будет, как фичи в ряд выстраиваться должны). Прочие протоколы (http/https/tftp) должны работать и сейчас. curl там еще imap поддерживает, но я не пробовал %) Мне кажется, еще интересным было бы поддерживать iSCSI, но там вроде ничего специального не требуется - блочное устройство как блочное устройство... CIFS, надеюсь, в initrd не нужен? > И мы говорили, что это будет штатной фишкой make-initrd. В любом > случае нужно время, чтобы посмотреть код и въехать. Мне это интересно в > любом случае. Возможно, Алексей хотел бы это реализовать как-то иначе. Программист я не настоящий, так что код там сугубо любительский. Наверное, сейчас хорошее время редизайнить его, libshell может быть заиспользовать.. >> Из замеченных общих минусов - перед переключением в общую систему >> стоит полностью гасить сеть. Иначе эффекты будут самые разнообразные - >> NM считает такой интерфейс unmanaged и не поднимает на нём >> подключение, rescue судя по всему вообще не инициализирует сеть >> (resolv.conf у него там очень весёлый внутри) > > Да, даже в пропагаторе убирали похожий баг. stage2 поднимает сеть с > чистого листа. Фича network должна уметь перед переходом в stage2 > опускать всё ранее поднятое. Но тогда как быть с сетевой загрузкой? Либо > stage2 должен быть заточен под такой stage1, либо мы сначала выкачиваем > из сети всё необходимое, потом опускаем сеть и тогда уже переходим в > stage2. При кешировании образов в памяти - никаких проблем, опускаем сеть и пусть stage2 само разбирается. А вот без кеширования, с NFS это может быть действительно интересно. Возможно, из initrd стоит сгенерировать неких конфигов и подложить в rootfs для stage2. Проблема в том, что мы не можем быть уверенными, чем именно stage2 пользуется - etcnet, NM, systemd-networkd, whatever...