mkimage-profiles

History

Michael Shigorin 49b6291a40 kernel, stage1: don't provide r8168.ko by default It conflicts with r8169.ko inobviously. The whole mess looks like this: - r8169.ko doesn't work for all of Realtek 8111/8168/8169 mutations - r8168.ko works with some of the chips r8169.ko doesn't - r8168.ko also works with many chips r8169.ko works with - r8169.ko is provided by kernel-image package (thus default) - r8168.ko is provided by kernel-modules-r8168 package (optional) - kernel-modules-r8168 package requires r8168-blacklist package - r8168-blacklist package is a one-liner that blacklists r8169.ko - STAGE1_KMODULES wouldn't include r8168 (std-def) or rtl8168 (led-ws) - sub.in/stage1/modules would mention r8168.ko (m-p-d: r8169.ko) So a LiveCD built with use/kernel/net might work with RTL8111/8110 just fine when booted live but fail to automatically load the module when installed onto hard drive; manual modprobe r8169 would work though. NB: some of the chips (those available to me) would work just fine both ways -- this has contributed to fixing this that late. Bottom line: do not install backup/kludge drivers overriding main ones by default! Thanks sem@ for providing the crucial hint.		2014-03-17 21:22:29 +04:00
..
main
rootfs
stage1	kernel, stage1: don't provide r8168.ko by default	2014-03-17 21:22:29 +04:00
stage2
Makefile
README

README

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

== sub.in ==

Этот каталог содержит субпрофили; содержимое затребованных
(названия которых содержатся в значении переменной SUBPROFILES,
которую заполняют цели sub/* -- см. lib/sugar.mk) будет
скопировано в корневой каталог формируемого профиля.

Просьба ответственно относиться к изменению существующих субпрофилей
и вдумчиво -- к созданию новых; возможно, достаточно всего лишь
оформить нужное новой фичей (см. features.in/).

Обратите внимание: поскольку сборка частей дистрибутивного образа
и происходит в каталогах субпрофилей, то повторное использование
одного простого субпрофиля в рамках сгенерированного профиля штатным
образом невозможно.  Если требуется создать несколько близких по
реализации субпрофилей, изучите stage2 и задействующие его фичи.

Краткое описание существующих вариантов (см. соотв. README):

* rootfs является особым случаем, который используется при
  формировании файловых систем, предназначенных для пользователя
  (т.е. корень LiveCD, образа VM, ...)

* stage1: propagator и загрузчик (совместно с фичей syslinux);
  типично требуется для инсталяторов, live- и rescue-образов,
  но может использоваться без добавления таковых в образ,
  обеспечивая сетевую загрузку второй стадии

* stage2: наиболее сложный технологически субпрофиль, поскольку
  он является только базовым для получения ряда итоговых частей
  дистрибутива (install2, live, rescue); задействуется для этого
  только опосредованно через use/stage2/* и модифицирует stage1
  в силу наличия связи между ними (в stage1 попадает образ ядра
  и firmware, в stage2 -- соответствующие модули)

* main: пакетная база, укладываемая на образ (NB: поскольку рабочий
  чрут в этом случае не содержит ничего, кроме пакетов, добавлять
  что-либо в image-scripts.d смысла нет, только в scripts.d)

README Unescape Escape

README