forked from altcloud/mkimage-profiles
5427f3afdc
The issue at hand is that: /etc/tcb/USER/shadow gets USER:auth ownership (OK); /etc/tcb/USER/shadow- backup file is root:root (broken); /etc/tcb/USER/shadow.lock file is also root:root (broken). This is observed for all pseudousers created by package installation process within working chroots as well as for users created by deflogin feature; the problem is that e.g. echo USER:PASS | chpasswd will break. Looks like the cuplrit might be fakeroot/faked. |
||
---|---|---|
.. | ||
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)