Ура, у нас есть первая адаптация CLB под MI2: http://mak.complife.ru/MI2/clb.cpio Пока реализовано в виде дополнительной initramfs, совместимо с текущим initrd из master. Это преальфа, PoC и всё такое, но уже сейчас с его помощью можно полностью загрузить машину по сети. В частности, замечательно загружается squashfs, выдранный из regular-rescue: http://mak.complife.ru/MI2/rescue.squashfs Или, что приятнее, ливка из regular-xfce: http://mak.complife.ru/MI2/live.squashfs Леонид, что вы еще хотели от фичи liveboot? примерный initrd.mk: AUTODETECT = all FEATURES += network DISABLE_GUESS += ucode root MODULES_ADD += overlay squashfs loop (готовый initrd: http://mak.complife.ru/MI2/initrd-5.0.6-un-def-alt1.img) примерная cmdline: ip=eth0:dhcp4 clb_root=http://192.168.222.1/alt/rescue.squashfs Из замеченных общих минусов - перед переключением в общую систему стоит полностью гасить сеть. Иначе эффекты будут самые разнообразные - NM считает такой интерфейс unmanaged и не поднимает на нём подключение, rescue судя по всему вообще не инициализирует сеть (resolv.conf у него там очень весёлый внутри)
30.04.2019 02:34, Michael A. Kangin пишет: > Ура, у нас есть первая адаптация CLB под MI2: > http://mak.complife.ru/MI2/clb.cpio > Поздравляю! > Пока реализовано в виде дополнительной initramfs, совместимо с текущим > initrd из master. > > Это преальфа, PoC и всё такое, но уже сейчас с его помощью можно > полностью загрузить машину по сети. > > В частности, замечательно загружается squashfs, выдранный из > regular-rescue: http://mak.complife.ru/MI2/rescue.squashfs > > Или, что приятнее, ливка из regular-xfce: > http://mak.complife.ru/MI2/live.squashfs > > Леонид, что вы еще хотели от фичи liveboot? > Вообще хотелось бы загрузки с флэшек, с CD/DVD и по сети в объёме пропагатора, а для начала хотя бы один из протоколов реализовать, типа NFS. И мы говорили, что это будет штатной фишкой make-initrd. В любом случае нужно время, чтобы посмотреть код и въехать. Мне это интересно в любом случае. Возможно, Алексей хотел бы это реализовать как-то иначе. > > > примерный initrd.mk: > AUTODETECT = all > FEATURES += network > DISABLE_GUESS += ucode root > MODULES_ADD += overlay squashfs loop > (готовый initrd: http://mak.complife.ru/MI2/initrd-5.0.6-un-def-alt1.img) > > > примерная cmdline: > ip=eth0:dhcp4 clb_root=http://192.168.222.1/alt/rescue.squashfs > > > Из замеченных общих минусов - перед переключением в общую систему > стоит полностью гасить сеть. Иначе эффекты будут самые разнообразные - > NM считает такой интерфейс unmanaged и не поднимает на нём > подключение, rescue судя по всему вообще не инициализирует сеть > (resolv.conf у него там очень весёлый внутри) Да, даже в пропагаторе убирали похожий баг. stage2 поднимает сеть с чистого листа. Фича network должна уметь перед переходом в stage2 опускать всё ранее поднятое. Но тогда как быть с сетевой загрузкой? Либо stage2 должен быть заточен под такой stage1, либо мы сначала выкачиваем из сети всё необходимое, потом опускаем сеть и тогда уже переходим в stage2. -- Best regards, Leonid Krivoshein.
30.04.2019 02:34, Michael A. Kangin пишет:
> Леонид, что вы еще хотели от фичи liveboot?
>
Перечитал ещё раз на ВиКи про Colaboot. Концептуально -- да, очень
близко и даже интересно. Нужно время, чтобы пощупать и разобраться.
--
Best regards,
Leonid Krivoshein.
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...
On Tue, Apr 30, 2019 at 03:04:12PM +0200, Michael A. Kangin wrote:
> > Да, даже в пропагаторе убирали похожий баг. stage2 поднимает сеть с
> > чистого листа. Фича network должна уметь перед переходом в stage2
> > опускать всё ранее поднятое. Но тогда как быть с сетевой загрузкой? Либо
> > stage2 должен быть заточен под такой stage1, либо мы сначала выкачиваем
> > из сети всё необходимое, потом опускаем сеть и тогда уже переходим в
> > stage2.
>
> При кешировании образов в памяти - никаких проблем, опускаем сеть и
> пусть stage2 само разбирается.
>
> А вот без кеширования, с NFS это может быть действительно интересно.
> Возможно, из initrd стоит сгенерировать неких конфигов и подложить в
> rootfs для stage2. Проблема в том, что мы не можем быть уверенными, чем
> именно stage2 пользуется - etcnet, NM, systemd-networkd, whatever...
Так может мне не париться и сразу использовать NM в initrd ?
Я сделал фичу network поскольку не хотел писать конфигуратор сети. Мне
нужна была замена ipconfig.
FYI nm-initrd-generator(8)
--
Rgrds, legion
30.04.2019 22:21, Alexey Gladkov пишет: > On Tue, Apr 30, 2019 at 03:04:12PM +0200, Michael A. Kangin wrote: >>> Да, даже в пропагаторе убирали похожий баг. stage2 поднимает сеть с >>> чистого листа. Фича network должна уметь перед переходом в stage2 >>> опускать всё ранее поднятое. Но тогда как быть с сетевой загрузкой? Либо >>> stage2 должен быть заточен под такой stage1, либо мы сначала выкачиваем >>> из сети всё необходимое, потом опускаем сеть и тогда уже переходим в >>> stage2. >> При кешировании образов в памяти - никаких проблем, опускаем сеть и >> пусть stage2 само разбирается. >> >> А вот без кеширования, с NFS это может быть действительно интересно. >> Возможно, из initrd стоит сгенерировать неких конфигов и подложить в >> rootfs для stage2. Проблема в том, что мы не можем быть уверенными, чем >> именно stage2 пользуется - etcnet, NM, systemd-networkd, whatever... > Так может мне не париться и сразу использовать NM в initrd ? NM громоздок, только для простых случаев и вообще только для десктопов. Etcnet в нынешнем виде тоже не годится. Но в природе существует другая его реализация by sem@ и для dual-stack dhcp можно подтянуть именно её. Хотя наверное такие навороты в initrd пока излишни. Жаль, нет поддержки виртуальных фич, которые умели бы единообразно понимать cmdline и предоставлять одно и то же, типа network. Тогда базовая реализация network by legion@ в initrd покрывала бы 95% общих потребностей, и отказываться от неё совершенно незачем, к тому же в дополнение к этой базовой реализации мы хотели со временем подтянуть диалоги конфигурирования сети. > Я сделал фичу network поскольку не хотел писать конфигуратор сети. Мне > нужна была замена ipconfig. > > FYI nm-initrd-generator(8) > -- Best regards, Leonid Krivoshein.
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? Я что-то боюсь этого монстра, а главное, пока не вижу чем бы это помогло решить проблемы с наследованием сети в основной системе.