/home/dev_modules/dhcpcd-6.9.4_XZM - каталог?Да.
Монтировали его в другой каталог и сжали?В данном случае создал двухслойную aufs с точкой монтирования /mnt/data и всё вместе сжал в squashfs.
двухслойную aufsТеперь замысел понятен
mount -t aufs -o dirs=/dir1=rw:/dir2=ro aufs /mnt/2layerКакой тогда смысл в ro?Если монтировать каталоги, то смысла нет, всё можно монтировать rw, в данном случае ro потому что /initrd/bundles/base - точка монтирования модуля Richy-219-base.xzm
не могу придумать, как автоматически генерировать команду монтирования aufs, набирать такую команду вручную....бр-р-р ???В консоле никак это будет не удобно. Сделать монтирование всех папок в корне указанной или из конфига со списком папок
В консоле никак это будет не удобно.Это минус.
переписать pfsmerge-dirТут не только dir но и модули, подключенные и неподключенные. Переписывать надо pfsedit. Разбирать модули таким образом тоже можно.
Пока не могу придумать, как автоматически генерировать команду монтирования aufs, набирать такую команду вручную....бр-р-р ???Посмотрите мой squashfs тестер. Там это как раз сделано.
Где тут нажать что + добавить :) ?Слева. Под "Репутация"
Там это как раз сделано.Нет, это не то. Я имел в виду команду создания новой aufs.
# mount -t aufs -o dirs=/mnt/$dev/edit/=rw:/path/dir1/=ro:/path/dir2/=ro aufs /initrd/aufs Нет, это не то. Я имел в виду команду создания новой aufs.Там именно новая aufs при том что количество и имена папок заранее не известны. То что надо. Разве нет?
То что надо.В моём init сделано похоже, только с разделением выше|ниже. У вас подразумевается, что все точки монтирования|каталоги в одном месте. На практике обычно приходится добавлять в модуль извне. Пока мысль такая:
создать новую aufs из двух слоёв, пустой каталог edit и выбранный для редактирования в bundles модуль.А если мы не из bundles берем? Вообще aufs из одной папки тоже работает.
А если мы не из bundles берем?Тогда сначала монтируем, а потом берём.
Вообще aufs из одной папки тоже работает.Знаю. Можно и так. Вариантов море.
Обнаружил очень большой плюс, не искажаются права на файлы и каталоги.Плюсы в общем очевидны, главное, чтоб серьезных минусов не всплыло :)
Давайте стандартизируем точки монтирования aufs и edit.Не уверен, что нужно. Это же временная точка, после работы надо удалять все временное включая и точки монтирования. Может что-то типа /tmp/aufs$$, за одно застрахуемся от проблемы с двумя параллельно запущенными pfsmerge
$SYSMNT/aufs ?
А добавить pfs в контейнер.pfs по тому же принципу похоже еще проще :)Да. Монтируем два слоя, из точки монтирования запаковываем.
Минус пока один, верхний слой либо tmpfs, либо физический раздел.Тут ничего не сделать, но наверное надо это детектить и выдать ошибку
/tmp/aufs$$
Извлечение пакета из составного модуля на примере пакета Print.xzm:
без искажения прав на каталоги и файлы.Сейчас в pfsextract адские костыли для этого
Я готовНакорябать новых костылей :)
Pfsmerge и pfsmrge-dir при такой реализации одно и тоже процентов на 80.Не вопрос. Главное чтобы хотя бы имеющийся функционал не урезать
Здесь принцип другой и проще написать новое с нуляЕсли ключи будут те же - переписывайте (т.е. в рамках пфс)
Какой итог - поговорили и разошлись?Добью squashtest возьмусь за что скажете. Не хочется бросать на пол пути.
поговорили и разошлись?Если я разойдусь, мало не покажется :D
Какой итогИтог ещё не вызрел...
Мне кажется надо отдельно сделать создание временной aufs, отдельно монтирование слоёв в эту aufs, отдельно сжатие.Функциями в Libpfs и потом использовать везде - хорошая идея. Только много переделок
Итог ещё не вызрел...Мне кажется надо свести все описанные действия к двум скриптам pfsmerge pfsextract, если нарисуются общие куски (временный aufs например) их в libpfs, сборку модуля всегда делать mkpfs ключи сжатия одинаковые для всех трех будут.
Делать скрипт на каждое действие "от и до", обязательно где-то будет неудобно, и костылики могут потребоваться.
Мне кажется надо отдельно сделать создание временной aufs, отдельно монтирование слоёв в эту aufs, отдельно сжатие.
свести все описанные действия к двум скриптам pfsmerge pfsextractда
свести все описанные действия к двум скриптам pfsmerge pfsextractПопробуйте, у меня как-то не вытанцовывается. Но в любом случае начинать надо с создания aufs, это общая часть, поэтому mkaufs лучше отдельным скриптом.
все описанные действия к двум скриптам pfsmerge pfsextractЯ понял "все описанные действия " - это что связано с составными модулями, а не вообще все
Что еще упустил?вроде нет
Нужна ли?Если и да - не в первую очередь
Чтобы ничего не ломать и не страдать от "долгостроя"Я был готов заняться pfsmerge-dir. Теперь по итогу в непонятках - толи ждать Дядю Шурика толи чего
pfsextract aufs ни к чемуА вы пересоберите cups, будет ли он после этого работать?
ждать Дядю ШурикаИ ловить идеи на лету.
Я был готов заняться pfsmerge-dir. Теперь по итогу в непонятках - толи ждать Дядю Шурика толи чегоТак то все есть и никуда не спешим. Можно писать медленно, с чувством с толком с расстановкой, не заменяя пока в мастер ветке.
А вы пересоберите cups, будет ли он после этого работать?А что произойдет с правами если смонтирую модуль и распакую на ext3 к примеру? Я может не догоняю чего.
если смонтирую модуль и распакую на ext31) Если распаковывать, зачем монтировать?
1) Если распаковывать, зачем монтировать?А если мне не все файлы нужны, а только один пакет по списку из /etc/packages?
rsync -a например
Можно бы rsync, но очень бы не хотелосьАргументируйте.
Аргументируйте.rsync не хотелось бы т.к. жирный и больше ни для чего не используется
Если c mount получитсяПочему в будущем времени? Оно вчера уже получилось.
Оно вчера уже получилось.В моем понимании "получилось" - это переделанные на гите pfsextract|merge и пр.
Я так и не понял Вы впрягаетель в переделку или опять альтернативаНе волнуйтесь, ежели чего украдем :)
опять альтернативаАга, артельнапиво :)