Drake2xzm

  1. Переделал я drake2xzm на работу в pfs.
    Но форматы сделал

MODULEFORMAT=’*.pfs *.xzm ’

Но kdialog понимает эту переменную. А при запуске kdialog из mdialog проходит только * .pfs
И activate, deactivate, gactivate пришлось править.

  1. Вот всем хорош rpmdrake2xzm и я уже обновляю систему, запуская его из drake2xzm
    Но модули надо писать последовательно.
    Потом через pfs можно эти модули объединить
    А ведь хорошо было бы если rpmdrake2xzm сразу бы все писал в один модуль
    Если модуль стал слишком большой, то выбираешь другой.
    Это можно сделать и не так сложно а нельзя ли для этого использовать сервисы pfs ?

Это вам зачем?
Расширение pfs вообще не нужно. Везде xzm.
Оставьте pfs паппирусам :slight_smile:)

Для обновлений можно попробовать использовать sync2layer, pfsrebuild или syschanges . Еще можно chroot2pfs, ему можно передать не только команду, но и скрипт и собирать он будет относительно тех модулей которые вы ему подсунете для базы чрута. То есть если делаете модуль с обновлениями, а в качестве базы у вас исо магеи, то в модуль попадут все обновления, а если в качестве базы исо плюс предыдущие обновления, то будет модуль только с новейшими обновами. Модули для чрута можно задать по маске, списком или списком из файла.

Еще у chroot2pfs есть такая же фишка как у urpm2xzm с автопересборкой.
То есть если у вас модуль собран командой:

chroot2pfs -o opera.xzm --command urpmi opera 

то для обновления этого модуля достаточно

chroot2pfs opera.xzm

Если ничего не путаю :slight_smile:

А pfs в МагОС обновленная ?
Пробовал использовать mkpfs вместо dir2xzm то теней при сборке модуля вообще нет
Если в pfs включить тени стр 223

mount -t aufs -o shwh,br:/$SYSMNT/changes$N/=rw aufs /$SYSMNT/aufs$N && echo “$SYSMNT/aufs$N” || return 1

То выключить тени не могу в mkpfs
Ни mkpfs -w ни mkpfs --wh
А сюдя по - http://forum.puppyrus.org/index.php?topic=21253.0
Проблема уже решенная

В сборке магос pfs-utils из ветки v4, обновляю раз в пару-тройку месяцев. То есть если отстает то на пару месяцев. В следующей сборке будут свежие.
По остальному вообще не понял. Что вы там включаете в pfs? Это библиотека функций для остальных скриптов.

Что бы в сохраняемом образе в mkpfs тени сохранились надо их сначала смонтировать с тенями в aufs. Вот я в pfs и добавил монтирование теней. А так mkpfs тени игнорирует.

Сама сборка у меня без теней а сис-изменения пишутся с тенями.
Допустим надо удалить включенный сервис из системы удаляешь и в /memory/changes появляется тень и ее то и надо сохранить. Конечно правильнее выключать сервис при старте системы через MagOS.ini Но ведь это еще надо донести тем кто захочет попробовать сборку. А с сохранением теней получается максимальное соответствие с тем же drakconf из Магеи у меня.
Почистить систему то же нет проблем. Удаляешь все что нужно и выключаешься.

PS
А как на форуме обновить pfs - http://forum.puppyrus.org/index.php?board=176.0
Или это сборку надо скачивать ?

А что разве при подключении модуля с тенями с pfsload тени не работают?
Покажите последовательно что вы делаете, прямо командамию

Заберите скрипты с гитхаба pfs-utils и замените ими одноименные в /usr/lib/magos.

Вроде понял о чем вы. Просто видимо никому в голову не приходило то, что при сборке модуля в источниках уже могут быть тени :slight_smile:
Предлагаю написать в форум паппирус, будет ваш первый вклад в общее дело :slight_smile: Да и вообще надо бы прикинуть не сломает ли чего нибудь.
Тут еще момент в том, что с ключем -l тени не будут учтены, но сами файлы теней в модуль попадут, то есть с -l и без итоговый модуль будет отличаться, это не хорошо.

Ильфат уже начал тему про тени - http://forum.puppyrus.org/index.php?topic=21253.0
И вроде что то уже решено.
При монтировании системы корень root без теней
Все изменения пишутся в /memory/changes. И это уже каталог с тенями
Если при записи /memory/changes тени не учитывать то часть инфы о системе теряется
А именно что удалено.
Поэтому у меня модули сборки без теней а модули сис-изменения с тенями
Это позволило обычный МагОС приблизить к обычной штатной системе
Работаешь как в обычно и можно использовать те же инструменты
Конечно в теории это красиво но вроде неудобств в своей сборке я не испытываю

В Drake2xzm (за основу взят rpmdrake2xzm) выполняет задачи :slight_smile:

  • установка пакетов, обновлений в модуль - rpmdrake2xzm
  • Монтирование образа от LiveDVD для обновления и правки
    Можно модульную сборку сделать в виде одного образа
  • Правка установленных модулей. И тут то и вылазит модуль с тенями
    Вообще то я установленные модули монтирую в /memory/tmp/root_br и здесь появляется необходимость монтирования root_br но с тенями. Но может смонтировать его в
    /memory/tmp/changes и обойтись без нештатной работы root_br ?
    Попробовать надо еще раз

А у меня что то не то получилось. Я в drake2xzm заменил dir2xzm на mkpfs
И drake2xzm уже сформировал свои root_br(уже с тенями) и changes.
Но mkpfs уже готовый root_br видимо куда то смонтировал опять и получился модуль уже без теней
Получается неправильно я использовал mkpfs

mkpfs для сборки модуля создает свою ауфс, это нужно для сборки модуля из нескольких источников. Для склейки, проще говоря. Кстати, именно в это место вы и внесли звои правки в pfs :slight_smile: Кроме mkpfs этот код используют и другие утилиты. Чтобы отключить такое поведение и просто запаковать папку как делает dir2xzm есть ключик -l для mkpfs. Для сохранения теней -w. То есть mkpfs -l -w папка. Попробуйте.
То что начал Ильфат по теме теней должно работать, с ключами только разберитесь. Я думал ваша проблема в том, что при сборке ауфс для mkpfs и прочих pfs утилит не учитываются тени. А Ильфат писал о том, что тени в итоговый модуль не попадают.

  1. Странно но команда mkpfs -l -w папка заработала теперь как аналог dir2xzm
    Странно потому что в help написано - " -w - не включать AUFS тени "
    Но теперь ели я редактирую модуль без теней в drake2xzm то пишется образ без теней.
    Если я редактирую модуль с тенями в drake2xzm то пишется образ с тенями
  2. Предполагаю что если я буду объединять два модуля с тенями через mkpfs, то теней в записанном модуле не будет
    В drake2xzm с тенями скрипт разбирается при монтировании образа aufs

wha=""
[ -f “$DISK”/.wh…wh.aufs ] && wha=“shwh”
mount -t aufs -o $wha,br:$mod_br=rw:$DISK=ro aufs $root_br

Можно доработать в скрипте pfs команду mkaufs
И pfs будет автоматически распознавать модуль с тенями и монтировать образ aufs с тенями
Если обычные модули то теней не будет
Но я еще не пробовал
Только если объединять модуль без теней и модуль с тенями - это путаница будет
И этот вариант вероятно надо исключить и что то придумать что бы pfs сразу различало
модуль с тенями и модуль без теней
Может интерактвность наладить (Xdialog или kdialog) для выбора модулей ?

PS
Смотрел GitHub для pfs - https://github.com/pfs-utils/pfs-utils
И даже скачал, но извините за бестолковость ничего не понял
Там вроде по другому все сделано

Вы просто не то взяли.

Ни в коем случае. Это чисто консольные утилиты. Сверху можно городить любые гуи, здесь только ключи.

Раньше так и было. Видимо не исправили. Надо не забыть.

Тут вот какая штука. Учесть тени при монтировании внутренней ауфс для mkpfs можно. Даже по умолчанию наверное можно. Но. Итоговый модуль делается из точки монтирования ауфс, а там теней нет.
Ну то есть если вы склеиваите mkpfs два модуля и во втором есть тень, которая накрывает файл из первого модуля, то можно сделать чтоб в итоговом модуля этого файла не было. Может и сейчас так, не разбирался. Но сделать чтоб в итоговый модуль попала тень не получится, без обходных костылей.
Попробуйте начать тему в форуме паппирус, только объясните подробнее, на примере, а то объяснять это не Ваш конек :))

З.Ы. http://wiki.puppyrus.org/puppyrus/pr218/pfs3

Тут еще один момент.
Для Росы, по моим данным, надо полную rpm-базу писать
Для Магеи достаточно /var/lib/rpm/Packages
В MagOS.ini ввел переменную (по умолчанию no)

RPMDBCLEANE=no

Сама п/прога

clear_rpm()
{
#if [ -d “$xzm_br/var/lib/rpm” ] ;then
rm -rf “$xzm_br”/var/cache/urpmi/rpms/* “$xzm_br”/var/cache/urpmi/partial/* “$xzm_br”/var/cache/urpmi/headers/* “$xzm_br”/var/cache/urpmi/mirrors.cache
rm -rf “$xzm_br”/var/cache/urpmi/.metalink “$xzm_br”/var/cache/ldconfig/aux-cache
rm -rf “$xzm_br”/etc/sysconfig/network-scripts/ifcfg-e* “$xzm_br”/etc/sysconfig/network-scripts/ifcfg-p* “$xzm_br”/etc/sysconfig/network-scripts/ifcfg-w*
rm -rf “$xzm_br”/var/lib/preload/preload.state “$xzm_br”/var/lib/rpm/.rpm.lock “$xzm_br”/var/lib/rpm/.RPMLOCK
rm -rf “$xzm_br”/var/lib/rpm/.??* “$xzm_br”/var/lib/rpm/?wh?*
RPMDB="$xzm_br"/var/lib/rpm/??*
for a in ls -dr $RPMDB; do
#echo “a=$a”
if [ “${a##/}" != “Packages” -a "${a##/}” != “alternatives” -a “${a##*/}” != “modules” ] ;then
rm -rf $a
fi
done
#fi
}

Где xzm_br=mod_br
Т е теперь выбор за юзером

Если вы это для пфс-утилс предлагаете, то нет. Там не должно быть ничего привязанного к конкретному дистру.

Я про чистку rpm-базы. Вроде сохранение полной rpm-базы это и есть привязка к Росе
Непонятно. В сборке MagOS rpm-база представлена одним /var/lib/rpm/ Packages
И при старте системы rpm-база инициализируется
У меня же в drak2xzm, для Росы, получилось что надо сохранять полную rpm-базу
Если сохранять только /var/lib/rpm/ Packages то rpm-база не открывается

В пфс-утилс нет ни чистки базы ни ее оставления, там вообще нет ничего про рпм равно как и про deb и прочее.

То есть если вы хотите использовать чрут2пфс для установки пакетов или обновления, то у вас два пути.

  1. Это внутренний скрипт. Содержание приблизительно такое.
    #!/bin/bash
    urpmi --auto-update
    rm -rf все-не-нужное

И запускаете

chroot2pfs -o mod.xzm --script имя-скрипта.sh

Либо второй путь, чрут2пфс собирает не в модуль, а в папку, которую вы чистите скриптом и пакуете мкпфс, можно сразу и клеить. Мкпфс папки с модулями клеить умеет.

Написал в форум пфс-утилс
http://forum.puppyrus.org/index.php?topic=21961.msg162437#msg162437
Посмотрим что скажут.

Сегодня решил проверить на своей сборке удаление пакетов и удалил пакеты для virtualbox
Само удаление делал на rpmdrake и нужные тени не прошли в модуль записи
Как то странно. Удалял из системы и тени должны быть верхнего уровня и остаться в модуле записи.
Похоже что не желательно из образа для записи модуля удалять файлы

.wh…wh.orph
.wh…wh.plnk
.wh…wh.aufs