Реализация .PFS (тестирование)

[sfs]

При пересборке большого мета-pfs : pfsextract + pfsmerge не помешал бы ключ pfsextract -gzip (выходные модули с минимальной компрессией)
Серьезно экономим время на перепаковку

В PRA изначально использую ключи максимального сжатия во всех Mksquashfs. Проблем нет. Не пора ли ?

[Zay]

при загрузке и подключении pfs с модулем ядра (проприетарные драйвера nvidia) не наблюдаю выполнения depmod, смотрю в /initrd/pup_rw результат.
по идее должно выполнится и результаты depmod в слое rw появится должны.

Файлы .ko в модуле точно есть в нужных каталогах?
И где лежит модуль, чтобы посмотреть?
Команда запуска depmod приведена выше, по идее всё должно работать...

При пересборке большого мета-pfs : pfsextract + pfsmerge не помешал бы ключ pfsextract -gzip (выходные модули с минимальной компрессией)
Серьезно экономим время на перепаковку

Но при этом нарушаем спецификацию, что не очень хорошо.

Вопрос, а зачем при пересборке нужен pfsextract?
В pfsmerge давно есть ключ -c / --cut, ненужные пакеты удаляются, а новые добавляются за один проход.
Собственно pfsextract остался для того чтобы быстро выдернуть один-два пакета из большого набора.

В PRA изначально использую ключи максимального сжатия во всех Mksquashfs. Проблем нет. Не пора ли ?

Планирую попробовать прикрутить поддержку ещё нескольких ключей mksquashfs к mkpfs + pfsmerge + pfsextract, но там надо всё многократно тестировать, а то как бы не сломать случайно (как с editor_pfs получилось).

[Pro]

да модуль ko есть где надо, пакет nvidia можно взять в репозитарии.
помимо nvidia еще гружу модуль virtualbox, так что там модулей еще 4 шт.

команду поиска проверял, нормально ищет, мож просто в самом условии в синтаксисе что-то?

[sfs]

В pfsmerge давно есть ключ -c / --cut, ненужные пакеты удаляются, а новые добавляются за один проход.

век живи - век учись
Может в доку добавить пример использования или типа того (не юзайте pfsextract для перепаковки) ... Может я не 1 такой
А по экономии времени это поможет?

Планирую попробовать прикрутить поддержку ещё нескольких ключей mksquashfs к mkpfs + pfsmerge + pfsextract, но там надо всё многократно тестировать, а то как бы не сломать случайно (как с editor_pfs получилось).

Посмотрите что я переделал в этих утилитах в pra. Это уже хорошо оттестировано

[Zay]

Pro, хорошо, я ещё раз внимательно проверю синтаксис и т.д.

Может в доку добавить пример использования или типа того (не юзайте pfsextract для перепаковки) ... Может я не 1 такой

В документации этот параметр описан.
А перепаковку новичку проще всего делать через Меню > Редактор (editor_pfs). Там нужно только снять флажки с лишних пакетов, и в итоговом PFS их не будет. Куда ещё проще...

А по экономии времени это поможет?

Очевидно. Не создаётся куча временных однопакетных PFS, время уходит только на сжатие готового файла один раз.
Только при замене пакета на пакет с точно таким же названием приходится делать два прохода.

А утилиты PRA лежат где-нибудь отдельно от дистрибутива, чтобы можно скачать и посмотреть?

[sfs]

Очевидно.

ОК

А утилиты PRA лежат где-нибудь отдельно от дистрибутива, чтобы можно скачать и посмотреть?

Там немного микс из 0.2.9 и до последнего
Т.к. pfs зависимости так и не доделали побаивался некритичное апдейтить...
С busubox для совместимости пришлось костылей наставить
Вот бы сделать универсальную версию. То что для Pra подойдет - подойдет и для любого линукса (т.е. теоретически открывает новые горизонты)
А если бы еще и

*040 Научить pfs-util работать со списками файлов и зависимостей /var/lib/pacman . Без потери совместимости со старыми модулями

Без этого получается что в пра 2 дублирующих списка файлов 

[imago31]

я пробовал pfs-utils в slacko 5.4-работает, и даже через терминал подключал pfs, вылетали какие то там ошибки, непомню, но программы появлялись в меню и работали, ну если не требовались зависимости естественно

[sfs]

В идеале надо чтобы pfs-util работал в любом линуксе и еще бы привязывался  (опционально) к спискам файлов основных ПМ
Тогда можно будет и в слако и в магос
Ну и с яндексом победа близка - можно подумать про зависимости и скачку...

[Zay]

Проверил запуск depmod - у меня всё работает.
Не знаю куда ещё копать...

При запуске из Init-скрипта depmod, lodconfig и glib-compile-schemas не выполняются (ключ -n), как и было задумано.

[Pro]

подключение модулей же делается на уровне rc.sysinit так что те модули которые оттуда подключаются должны обрабатываться, ну или если не обрабатываются, то определение depmod надо вынести за пределы ключа -n

кстати раз у тебя find выдает конкретные результаты поиска, может в параметр depmod дать путь к модулю, чтоб быстрее обрабатывалось, или может insmod команда поможет чемнить.

[Zay]

Думаю лучше просто запускать depmod из rc.sysinit после подключения PFS/SFS.
Если пакетов с .ko-файлами окажется несколько - то и depmod будет запущен несколько раз, смысл?
Ключ -n как раз и был придуман для более эффективного многократного запуска pfsload.

По поводу запуска depmod с путями - при наличии одного/двух .ko-файлов может и будет ускорение, но если их окажется больше - то создание цикла в скрипте почти наверняка не ускорит, а замедлит процесс. ИМХО - не надо этого делать.
Кстати, при отключении модуля (в pfsunload) тоже вызывается depmod, уже после отключения модуля. Тут вообще пути ни к чему.

Про insmod ничего не могу сказать...

[Pro]

да insmod отклоняется,

depmod -A возможно даст более быстрый результат

-A --quick   Эта опция проверяет, не является ли какой-либо модуль более новым, чем файл modules.dep, прежде чем приступить к работе. Если файл modules.dep свежее модулей, то программа не будет повторно генерировать файлы, а без предупреждений завершит работу.

[sfs]

Ответил здесь, т.к. там не совсем по теме

PFS-utils был написан для PuppyRus, и последующие версии будут делаться в первую очередь для этой системы.
Но при этом максимально возможная совместимость с PRA очень желательна.

2 взаимоисключающих предложения
Надо делать pfs-util или универсальным или свою версию под каждый дистр.

Со своей стороны я всегда готов к коллективной работе.

http://forum.puppyrus.org/index.php/topic,12727.msg80100.html#msg80100
http://forum.puppyrus.org/index.php/topic,12727.msg83625.html#msg83625 :  pfs-utils-0.2.9pra-4-i686.pkg.tar.xz (61.21 Кб - загружено 0 раз.)

Если кто-то хочет модифицировать скрипты из пакета PFS-utils (при условии сохранения всего функционала и общей стабильности) - welcome!

ntf был написан и для pfs-util - до сих пор не используется
Предложению про -Xbcj x86 скоро год. Вроде все ясно. Не используется

Специфичные для PRA скрипты, скорее всего, не войдут в PFS-utils, авторы могут выкладывать их отдельным пакетом (PFS или PKG).

sfs-get не используется со времен Bit. PRA тогда не было

Разрабатывать скрипты для PRA я (пока) не планирую, но готов оказать желающим поддержку в общих для PR и PRA разработках (см. выше).

Какие могут быть общие PR pfs-util PRA разработки?

Развитие pfs-utils практически остановилось. Причем на пол пути

[Zay]

2 взаимоисключающих предложения
Надо делать pfs-util или универсальным или свою версию под каждый дистр.

Возможна частичная универсальность. Если получится - скоро будет поддержка %FILES% в списках.

Какие могут быть общие PR pfs-util PRA разработки?

Специфичные для PRA скрипты (тот же sfs-get) могут вызывать команды из PFS-utils (pfsload, pfsmerge).
А те скрипты, которые не востребованы в PRA - можно просто не использовать.

-Xbcj x86 не используется по умолчанию потому, что я так и не получил чёткого ответа на вопрос о совместимости (с x64 или ARM).
Если совместимость не потеряется (а только проиграет производительность) - то можно включить эти команды в скрипты в любой момент.
А если совместимость при этом будет потеряна - тогда, ИМХО, допустима только опциональная поддержка.

pfs-utils-0.2.9pra-4-i686.pkg.tar.xz
Это вложение я почему-то не заметил. Искал в разделе PRA эти скрипты, а под носом у себя проглядел...

Про баг со "\" в курсе, но готового решения никто не предлагал.
Наброски у меня есть, но протестировать не успел пока (а тестировать надо серьёзно, т.к. модифицируется самая важная часть кода).
Теперь планирую попробовать решить эту проблему одновременно с поддержкой %FILES% (править нужно будет тот же самый код).

[sfs]

Если получится - скоро будет поддержка %FILES% в списках.

Посмотрел размер того что можно сэкономить - не впечатлило
Причем если модуль состоит из нескольких пакетов - придется собирать files по папкам
Хоть какая-то экономия будет в многопакетных базовых модулях - так их вообще можно сделать .sfs (собирать\разбирать не предполагается)

Специфичные для PRA скрипты (тот же sfs-get) могут вызывать команды из PFS-utils (pfsload, pfsmerge).
А те скрипты, которые не востребованы в PRA - можно просто не использовать.

Так и делаю

-Xbcj x86 не используется по умолчанию потому, что я так и не получил чёткого ответа на вопрос о совместимости (с x64 или ARM).

Насколько я понял это вообще не про то
http://www.slax.org/blog/18663-XZ-compression-filters.html

For Slax, we simply add x86 filter since it will do the job for both 32bit and 64bit architectures. Slax core module is 2% smaller than before (52MB versus 51MB), so the difference for full Slax will be somewhere between 5-10 megabytes less of data at the cost of adding "-Xbcj x86" parameter to mksquashfs command. Cool!

https://lkml.org/lkml/2010/12/9/11
А зачем на х64 нужны х32 модули?
Проверил на x64 grml в виртуалке. mount -o loop работает