49b6291a40
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. |
||
---|---|---|
.. | ||
main | ||
rootfs | ||
stage1 | ||
stage2 | ||
Makefile | ||
README |
== 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)