From: Leonid Krivoshein <klark.devel@gmail.com> To: devel@lists.altlinux.org Subject: Re: [devel] Модульный initrd.img Date: Sun, 6 May 2018 21:25:08 +0300 Message-ID: <61310192-890b-1f93-a05c-09afb4a8efdd@gmail.com> (raw) In-Reply-To: <daa20300-c2f2-529c-7ac6-1934dbe119e4@complife.ru> Добрый вечер! 06.05.2018 19:55, Michael A. Kangin пишет: > Здравствуйте! > > Не секрет, хотя и не широкоизвестно, что популярные загрузчики > позволяют указывать несколько cpio-образов, которые при загрузке будут > объединены в памяти в единую initramfs. > Равно как и то, что склеить initrd можно из нескольких кусков уже на этапе генерации. Если не ошибаюсь, наш mkmodpack создаёт отдельный кусок с модулями ядра. > Этим можно воспользоваться, и разделить текущий монолитный initrd.img > на отдельные образы - собственно сам initrd, early-микрокод, и модули > ядра [с фирмварью]. > Если не ошибаюсь, ucode для initel/amd у нас тоже сейчас отделён. Цена вопроса в любом из вариантов -- выравнивание кусков по 4Кб границам, если не ошибаюсь, они склеиваются не встык, а должны выравниваться по границам размера страницы. > Зачем это может быть нужно? > - ускорение генерации новых initrd при установке нового ядра. Если > микрокод и само тело initrd остаётся такими же, достаточно только > быстренько слепить образ с новыми модулями. Это значит капитально переделывать инструмент генерации initrd, другие дистрибутивные инструменты, которые это должны поддерживать. Ради чего? Так ли уж долго генерируется initrd? И ведь нужно ещё вести учёт того, что менялось, а что нет. > - уменьшение суммарного размера микрокода / разных вариантов initrd / > разных версий ядра. Например, мы выносим микрокод отдельным образом - > и нам не нужно включать его в каждую новую версию initrd, которую мы > делаем. Если мы генерим себе -debug initrd, то достаточно сделать > крохотный diff-образ с bash / lsmod / whatever, а модули и основной > initrd у нас уже есть. Мы можем предложить загрузить на выбор std-def > и un-def, причём разница (кроме самих vmlinuz'ов) будет достаточно > небольшая, архивы из десятка модулей ядра. Для решения конкретных задач всё равно будут пары ядро+initrd, а любые попытки приведут к небольшому увеличению конечного образа, но не наоборот. > - возможность оперативно фиксить уже существующий initrd, добавив > сбоку в отдельном образе или недостающий модуль, или конфиг там какой > со скриптом. Чтобы его оперативно пофиксить сейчас достаточно сказать make-initrd. > - возможность полностью отвязать сам initrd от версии ядра. И иметь > возможность загрузить систему с, например, RHEL-овским ядром, но нашим > initrd, не ломая никакой совместимости. > make-initrd умеет класть в образ initramfs любые файлы и сейчас. > Минимальная поддержка, необходимая в initrd для сторонних образов с > модулями - вызов "depmod -a" перед загрузкой модулей, например, в > стадии pre-udev. Если сторонние образы содержат что-то другое, то и > поддержки особой не надо. > Сейчас автоугадав взаимных зависимостей модулей работает на этапе генерации initrd. Чего же хорошего в переносе этой длительной операции на этап КАЖДОЙ (!) загрузки машины? > Возможно, удалось бы сделать продвинутую поддержку сторонних модулей, > чтобы выносить из основного тела отдельные фичи. Плимут просто > напрашивается, например. > Так и сейчас чтобы сгенерировать initrd с определёнными фичами или наоборот, без них, достаточно подправить /etc/initrd.mk и сказать make-initrd. Именно так можно избавиться от плимута, к примеру. > Вот пара вполне работающих примеров: > > syslinux с семейством (iso, pxe): > ======================= > LABEL test-modular-initrd > MENU LABEL Test modular initrd > KERNEL clb/vmlinuz > INITRD clb/microcode.img,clb/initrd-thin.img,clb/supermicro_boot.modules > APPEND root=http://xxxxx/rescue-base-sm.manifest rootdelay=5 > ======================= > Работает как с legacy bios, так и с uefi. > > grub2: > ======================= > ... > echo 'Loading Linux 4.9.71-std-def-alt0.M80P.1 ...' > linux /boot/vmlinuz-4.9.71-std-def-alt0.M80P.1 > root=UUID=a397ac93-3b06-4023-83e4-18b29a28b033 ro quiet > resume=/dev/disk/by-uuid/6481d48d-8403-4049-adfc-87e94b950361 panic=30 > splash > echo 'Loading initial ramdisk ...' > initrd /boot/microcode.img > /boot/initrd-4.9.71-std-def-alt0.M80P.1-thin.img /boot/modules.img > ======================= > c uefi не пробовал. > > Так же, не знаю, умеют ли это хитрые uefi-загрузчики типа refind'а. Даже если не умеет загрузчик, куски можно склеить заранее. И получить всё тот же монолитный initrd. Но зачем? Ведь в конечном итоге для решения конкретной задачи эти куски попадают на обработку всё равно уже в склееном виде. -- Best regards, Leonid Krivoshein.
next prev parent reply other threads:[~2018-05-06 18:25 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-06 16:55 Michael A. Kangin 2018-05-06 18:25 ` Leonid Krivoshein [this message] 2018-05-06 19:34 ` Michael A. Kangin 2018-05-06 23:50 ` Leonid Krivoshein 2018-05-07 11:52 ` Michael A. Kangin 2018-05-07 23:34 ` Leonid Krivoshein 2018-05-07 22:56 ` [devel] Fwd: " Leonid Krivoshein
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=61310192-890b-1f93-a05c-09afb4a8efdd@gmail.com \ --to=klark.devel@gmail.com \ --cc=devel@lists.altlinux.org \ /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
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/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 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git