From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Resent-From: Michael Shigorin Resent-Date: Tue, 23 Apr 2019 16:00:02 +0300 Resent-Message-ID: <20190423130002.GI18867@imap.altlinux.org> Resent-To: make-initrd@lists.altlinux.org Envelope-to: ar@cs.msu.ru Delivery-date: Fri, 27 Apr 2018 01:28:52 +0300 From: Alexey Gladkov To: Leonid Krivoshein Message-ID: <20180426222845.GL4066@comp-core-i7-2640m-0182e6> References: <20180425085417.GA4066@comp-core-i7-2640m-0182e6> <20180425100924.GY4026@imap.altlinux.org> <20180425121231.GB4066@comp-core-i7-2640m-0182e6> <20180425154402.GC4026@imap.altlinux.org> <20180426083554.GE4066@comp-core-i7-2640m-0182e6> <8f210a29-13c8-0714-3bd5-6a69a5f1cb57@gmail.com> <20180426101604.GG4066@comp-core-i7-2640m-0182e6> <20180426102102.GH4066@comp-core-i7-2640m-0182e6> <2220242a-9178-5c89-02a2-0623518585b6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2220242a-9178-5c89-02a2-0623518585b6@gmail.com> X-SA-Exim-Connect-IP: 194.107.17.36 X-SA-Exim-Mail-From: gladkov.alexey@gmail.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.cs.msu.ru X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.cs.msu.ru) Cc: =?utf-8?B?0JDQvdC00YDQtdC5INCn0LXRgNC10L/QsNC90L7Qsg==?= Subject: Re: [make-initrd] =?utf-8?b?RndkOiBSZTogW2RldmVsXSDQl9Cw0L/RgNC+0YEg?= =?utf-8?b?0L3QsCDRhNC40YfRgyBsaXZlYm9vdCDQsiBtYWtlLWluaXRyZA==?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 23 Apr 2019 13:00:02 -0000 X-Original-Date: Fri, 27 Apr 2018 00:28:45 +0200 X-List-Received-Date: Tue, 23 Apr 2019 13:00:02 -0000 Archived-At: List-Archive: On Thu, Apr 26, 2018 at 11:24:04PM +0300, Leonid Krivoshein wrote: > > 26.04.2018 13:21, Alexey Gladkov пишет: > > Мне нужна помощь в написании грамотных фичей. Сейчас мне нужна фича > > настройки сети так как в make-initrd она ооочень условная и сделана через > > утилиту ipconfig из klibc, которая, скажем так, очень стабильная. > > Уже говорил, что пока более-менее я осилил make-initrd только из p8, > надеюсь по фичам там нет больших отличий в v2+? Концептуально нет. В остальном есть. > Мне по-любому придётся > разбираться с сетью, так что можно будет отталкиваться от моего > чернового варианта, сделанного под задачи деплоя на скорую руку. Но на > грамотную чистовую реализацию в виде конечной фичи пока не претендую. > Если правильно понял, ipconfig лучше не использовать. Согласен, потому > что лучше ip из пакета iproute2 -- его одного хватит для всех задач. Я не хочу реализовывать свою систему управления сетью. > > Я разговаривал ldv, glebfm, wladmis и пришёл к выводу, что стоит > > использовать etcnet в образе. > > Тоже об этом думал. Чтобы не изобретать велосипед, для более сложных > случаев, конечно, можно. Но у нас ни один пакет с таким названием, а как > минимум четыре. Вы, видимо, не разбирались с ним. Скрипты там одни. > > Так что, нужно написать фичу для этого, плюс > > придумать настройку в рантайме, плюс конвертер параметра `ip=` в > > конфигурацию etcnet. > > Видел готовые реализации в Gentoo. Правда, не под etcnet, но диалоги > готовые. Может получится перетащить что-то из этого. См.: > http://www.reactivated.net/weblog/archives/2006/06/net-setup-enhancements/ Это диалоги для настройки сети. Если их нельзя взять "как есть", то их придётся дорабатывать под систему конфигурации сети и как следствие придётся взять эту подсистему из gentoo. Если её нельзя использовать отдельно от gentoo (а скорее всего так и есть), это будет форк, а я не хочу разрабатывать свою систему управления сетью. > . Стоит сразу определиться: сетевая загрузка корня с NFS/FTP/HTTP > возможна даже по вай-фаю, но PXE-загрузка ядра и initrd по вай-фаю > невозможна, если не ошибаюсь. Исходя из этого стоит ли тащить в liveboot > поддержку Wi-Fi? Нужно сделать так, чтобы была возможность расширения функционала. Даже если сейчас это не нужно, то уверен, что рано или поздно появится некто, хотящий корень по HTTPS-over-Wifi. > Что касается параметров ip=... и nfsroot=... -- тут я > убеждён в обратном. Их нельзя как-либо использовать в initrd, потому что > они предназначены для самого ядра и, если эти параметры указаны, ядро > само их парсит и начинает поднимать сеть, искать и пытаться монтировать > корень, итд... Вы неправы. Это _уже_ используется и используется это очень давно. Поддержка этих параметров есть и она должна сохраниться для обратной совместимости. В качестве троллического отступления хочу напомнить, что параметр root= тоже разбирается ядром. > В случае успеха, до запуска initrd дело вообще не должно > дойти. Однако наше ядро собирается без DHCP- и NFS- клиентов, как я > полагаю, и поэтому мы можем видеть очень длительную задержку во время > запуска и загрузки ядра с любым из этих параметров и с нулевым эффектом > на выходе. По этой причине я бы не стал использовать в initrd параметры > загрузки с такими названиями. Меня удивило их наличие в скриптах > make-initrd после прочтения документации и проверки методом научного > тыка. Поправьте, если ошибаюсь. Повторюсь, это очень старые параметры. Proof: http://git.altlinux.org/gears/m/mkinitrd.git?p=mkinitrd.git;a=blob;f=init.sh#l82 http://git.altlinux.org/gears/m/mkinitrd.git?p=mkinitrd.git;a=blob;f=init.sh#l94 > Кроме того, я бы предложил использовать > ещё один механизм для передачи параметров -- через соответствующий > конфиг. Например, как это сделано тут: > http://git.altlinux.org/people/klark/packages/deploy-project.git?p=deploy-project.git;a=blob;f=stage1/etc/deploy.conf > -- просто, чтобы была возможность не только системных умолчаний, но и > сборочных (при сборке образа initrd), чтобы не тащить большой список > параметров в kernel cmdline. Да, это правильно. Такой механизм уже используется в makе-initrd для корня. > > Также нужно посмотреть etcnet на предмет его работы с > > утилитами busybox и возможность использования в нём udhcp. > > Вот в этом мне видится большое противоречие. Для простых случаев > достаточно ручного парсинга и утилиты ip, потому что etcnet много чего > за собой потянет, особенно etcnet-full. Он модульный. В идеале я хотел бы, чтобы фича etcnet была не монолитной. > > Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько > > востребован функционал с nfs. Если востребован, то это будет ещё один > > пласт работ. > > С ним не всё хорошо и толком разобраться пока не получилось. Удалось > лишь добиться, чтобы хоть как-то по нему грузилось. При этом я могу > видеть сегфолты в ядре на стороне сервера. Вообще не уверен, что > nfsmount стоит использовать, хотя видел, что к ней вернулись из-за > проблем с mount.nfs/mount.nfs4. Но у меня в скриптах сейчас со вторыми > проблем меньше, propagator же умеет только nfsmount. Видимо придётся > делить на NFSv3 и NFSv4, и разбираться с каждым по отдельности. Вот поэтому вопрос открыт )) > > Также я занимаюсь анализом init-bottom перед похоронами этого скрипта. > > Про преемственность я уже говорил. Стоит позаботиться о полном > сохранении совместимости О какой совместимости вы говорите ? О параметрах cmdline ? Они разумеется останутся как были. > Подытожу. Возможности заняться написанием конкретной фичи в нужном > формате в чистовом варианте в ближайший месяц-два у меня точно не будет. Я собственно не настаиваю. Я просто поставил всех заинтересованных в известность о том, что нужно, чтобы "успеть к P9". А дальше решайте сами. Мне некуда торопиться и я буду реализовывать, что задумал чтобы в make-initrd появился функционал аналогичный propagator. Когда такой функционал появится, тогда можно будет закопать propagator. Если у меня на его реализацию уйдёт год, то значит через год его можно будет закопать. > По основной работе буду заниматься схожими боданиями с начальной > загрузкой по сети, и эти наработки как черновой материал можно будет > потом подтащить в make-initrd. При всём уважении я не приму код, который решает какую-то частную задачу. Этот подход был использован при разработке propagator. Он весь состоит из решений частных задач. Кроме того, мне некуда торопиться. Есть время для нормального проектирования. -- Rgrds, legion