From: Leonid Krivoshein <klark.devel@gmail.com> To: Alexey Gladkov <gladkov.alexey@gmail.com> Cc: "Андрей Черепанов" <cas@altlinux.org> Subject: Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd Date: Tue, 23 Apr 2019 13:00:02 -0000 Message-ID: <2220242a-9178-5c89-02a2-0623518585b6@gmail.com> (raw) In-Reply-To: <20180426102102.GH4066@comp-core-i7-2640m-0182e6> 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/ . Стоит сразу определиться: сетевая загрузка корня с NFS/FTP/HTTP возможна даже по вай-фаю, но PXE-загрузка ядра и initrd по вай-фаю невозможна, если не ошибаюсь. Исходя из этого стоит ли тащить в liveboot поддержку Wi-Fi? Что касается параметров ip=... и nfsroot=... -- тут я убеждён в обратном. Их нельзя как-либо использовать в initrd, потому что они предназначены для самого ядра и, если эти параметры указаны, ядро само их парсит и начинает поднимать сеть, искать и пытаться монтировать корень, итд... В случае успеха, до запуска initrd дело вообще не должно дойти. Однако наше ядро собирается без DHCP- и NFS- клиентов, как я полагаю, и поэтому мы можем видеть очень длительную задержку во время запуска и загрузки ядра с любым из этих параметров и с нулевым эффектом на выходе. По этой причине я бы не стал использовать в initrd параметры загрузки с такими названиями. Меня удивило их наличие в скриптах make-initrd после прочтения документации и проверки методом научного тыка. Поправьте, если ошибаюсь. Кроме того, я бы предложил использовать ещё один механизм для передачи параметров -- через соответствующий конфиг. Например, как это сделано тут: http://git.altlinux.org/people/klark/packages/deploy-project.git?p=deploy-project.git;a=blob;f=stage1/etc/deploy.conf -- просто, чтобы была возможность не только системных умолчаний, но и сборочных (при сборке образа initrd), чтобы не тащить большой список параметров в kernel cmdline. > Также нужно посмотреть etcnet на предмет его работы с > утилитами busybox и возможность использования в нём udhcp. Вот в этом мне видится большое противоречие. Для простых случаев достаточно ручного парсинга и утилиты ip, потому что etcnet много чего за собой потянет, особенно etcnet-full. > Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько > востребован функционал с nfs. Если востребован, то это будет ещё один > пласт работ. С ним не всё хорошо и толком разобраться пока не получилось. Удалось лишь добиться, чтобы хоть как-то по нему грузилось. При этом я могу видеть сегфолты в ядре на стороне сервера. Вообще не уверен, что nfsmount стоит использовать, хотя видел, что к ней вернулись из-за проблем с mount.nfs/mount.nfs4. Но у меня в скриптах сейчас со вторыми проблем меньше, propagator же умеет только nfsmount. Видимо придётся делить на NFSv3 и NFSv4, и разбираться с каждым по отдельности. > Также я занимаюсь анализом init-bottom перед похоронами этого скрипта. Про преемственность я уже говорил. Стоит позаботиться о полном сохранении совместимости для простоты перехода с пропагатора на liveboot, вплоть до полной поддержки его kernel cmdline. Иначе переход на liveboot будет сильно затруднён необходимостью правки неведанного числа пакетов, типа alterator-netinst и задача превратится в нерешаемую. * * * Подытожу. Возможности заняться написанием конкретной фичи в нужном формате в чистовом варианте в ближайший месяц-два у меня точно не будет. По основной работе буду заниматься схожими боданиями с начальной загрузкой по сети, и эти наработки как черновой материал можно будет потом подтащить в make-initrd. Особенно, если они пройдут обкатку в предполагаемом развёртывании на тысячах машин. Разница только в том, что мне нужно сделать хоть как-то по быстрому, чтобы заработало, и в том, что на сетевом ресурсе я ищу не корень stage2, а директорию с файлами, что почти на 95% перекрывает решаемую задачу, если не считать диалогов пропагатора. -- Best regards, Leonid Krivoshein.
next prev parent reply other threads:[~2019-04-23 13:00 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-23 13:00 ` Michael Shigorin 2019-04-23 13:00 ` Leonid Krivoshein 2019-04-23 13:00 ` Alexey Gladkov 2019-04-23 13:00 ` Leonid Krivoshein 2019-04-23 13:00 ` Alexey Gladkov 2019-04-23 13:00 ` Alexey Gladkov 2019-04-23 13:00 ` Leonid Krivoshein 2019-04-23 13:00 ` Alexey Gladkov 2019-04-23 13:00 ` Leonid Krivoshein 2019-04-23 13:00 ` Leonid Krivoshein [this message] 2019-04-23 13:00 ` Alexey Gladkov 2019-04-23 13:00 ` Leonid Krivoshein 2019-04-23 13:00 ` Alexey Gladkov 2019-04-23 13:00 ` Leonid Krivoshein 2019-04-23 13:00 ` Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2220242a-9178-5c89-02a2-0623518585b6@gmail.com \ --to=klark.devel@gmail.com \ --cc=cas@altlinux.org \ --cc=gladkov.alexey@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git