Концепт режима сохранения в модуль

У меня же в DROPFILTER только шаблоны
Поэтому строк с путями типа /home/bin быть просто не должно
Конечно опасно. Но так сделано в том числе для проверки работы поиска исключений по шаблонам. Вообще ведь у меня было много проблем и работало не очень хорошо.
С другой стороны когда задаешь шаблон MagOS а удаляется file:///etc/MagOS/config
то же малопонятно. Удалял одно а удалилось другое. И папка MagOS пустая
А для файлов с путями применил EXCLUDFILTER
Тут строки идут прямо в исключения

О том и речь. Надо придумать чтоб потом не удивляться :slight_smile:

При использовании этой строки удаляются директории
Теперь задаешь шаблон MagOS и он удаляется
Только удаляются в частности /etc/MagOS а так же все папки MagOS в /memory/changes

Извиняюсь за неточности.

Задержки у меня давали закоментированные строки (273 …)

    find $SRC/ -type d | sed 's|'$SRC'||' | while read a ;do
    grep -q "^$a" /tmp/includedfiles && continue
    echo "$a" >> /tmp/$n/excludedfiles
    done

И закоментированные стр как раз и ищут директории
Без них подготовка исключений, при обновлении ядра, прошла быстро
А в этом варианте будут зависания при больших объемах паковки
Формируется includedfiles и если эти файлы находятся в $SRC то они попадают в excludedfiles
Как то многоходовка получается. Не проще ли сразу писать файлы для excludedfiles в отдельном фильтре

Получилось что я вместо этих строк применил

find $SRC/$a/ -type d >>/tmp/allfiles

Для файлов с путями, которые пишутся прямо в excludedfiles, применил фильтр EXCLUDFILTER
И вроде у меня теперь все ок !
Если файла из EXCLUDFILTER нет $SRC то mksquashfs сам неплохо разбирается с отсутствующими файлами в списке
И смысла в закоментированных строках я не нахожу

С этой правкой задержек в подготовке списка исключений в toxzm, при обновлении ядра, нет

Предложенная мною подпрога cleaner_home вроде как лишняя. Просто еще не успел до конца протестировать.
А подпрогу cleaner_root я бы оставил. Так как

Для строчек REBUILD* добавлено еще одно значение - ‘once’
Было только yes/no
once означает сохранить один раз и перевести в - no. Может быть полезно если нужно включить сохранение однократно. Возможно даже в сборку это изменение попало.

Теперь toxzm работает и в случае если модули с сохранениями на разделе luks. Правда если пароль не привязан к железу, ( UIRD и LUKS ) будет спрашивать его и при выключении.

Опять я и опять с Ubuntu. Называется не было заботы так купили порося.
Допустим, при первой записи, toxzm делает модуль /memory/layer-base/0/toxzm/base0.xzm
Можно так же добраться до него - /memory/data/mounts/0/Linux/Ubuntu/toxzm/base0.xzm
При второй записи система, при выключении не может отмонтировать этот модуль
Так же его не может отмонтировать toxzm и как результат модуль не сохраняется.
На Магее и Росе все ок!
В Магее из /usr/lib/magos удалял содержимое папок rc.halt.pre и rc.halt
Все равно в toxzm все нормально отмонтируется а потом все что надо монтируется.
Не работают режимы mount. mount+wh, none+wh

Режим none+wh делает пустой модуль
Тут уж писал модуль - base/41-base0.xzm так же не может его отмонтировать
Другие модули отмонтируются ок
Сейчас в системе модули у меня и деактивируются и отмонтируются.
Вроде корректно. Но в toxzm опять появляется сообщение что 41-base0.xzm занят
Что то в toxzm не так работает в Ubunte …

  1. Скачал свежую версию toxzm и ситуация повторилась.
    Первый модуль создается а потом toxzm не может его перемонтировать
    А что нельзя без перемонтирования ?
    Но на свежей версии прогресс. Второй модуль записи создается пустым.
    Раньше toxzm блокировала запись и выключалась
    Но режим copy работает !

  2. Может какие пакеты не установил . Попробую доустановить
    И терминал в toxzm при запуске из убунты без сохранения истории действий.
    Приходится каждый раз команды снова набирать. В системе все ок
    Есть ли возможность в toxzm указать другой терминал ?

Наблюдал проблемы с монтированием каталога с конфигом toxzm только в ситуации когда один бинд размонтировался, а второй нет. Там же в дата/фром и в лэйер/бэйс точки монтирования есть. Но я вроде это место чинил уже. Можете выложить сборку с убунтой? Не обещаю что быстро, но постараюсь починить.
Про терминал не понял, что вы имели ввиду.

Со свежей версией toxzm подвижки.
Появилось сообщение
mount: mounting aufs on /tmp/aufs filed: invalid arguments

Может у меня получится.
Но с модулем записи все равно проблема. Не отмонтируется и все тут.
Но хоть режим copy работает.

А Ubuntu выложу несколько позже, т к выяснилось сборка сыровата и не все пакеты установил.
Может что то не установлено. Хорошо бы список пакетов что именно нужно для МагОС
И какой то установочный скрипт бы не помешал.
А то вручную делать долго

Это если в toxzm использовать функцию shell для выхода в терминал при записи модуля.
Так в Ubuntu этот терминал без истории команд. Как бы неудобно.
В системе все ок

Я сейчас работаю над сборкой где тоже не работает mount+wh. Но причина не в toxzm, а в том что поддержка монтирования SHWH не включена в ядре. Посмотрите как у вас, может таже проблема. Просто грепом поищите SHWH в конфиге ядра.

Там один и тот же шелл во всех вариантах, он не из дистрибутива, а из бизибокса, который в UIRD. Между сессиями хранить историю слишком сложно будет, нет смысла так усложнять.

Списки пакетов для каждого модуля есть в сборке, в /var/lib/rpm/modules, но Вам это не поможет, так как имена пакетов в убунте будут отличаться.

У магеи есть в /usr/lib/modules/5.6.14-desktop-2.mga7 файл shwh
В ядре от Убунту в /usr/lib/modules/… файла shwh нет

Так вроде пробовал я запуститься на ядре от Магеи. И то же mount+wh не работал.
Попробую снова.

Надо в конфиге ядра смотреть.
cat /boot/config-(имя-ядра) |grep SHWH
или
zcat /proc/config.gz |grep SHWH
или
cat /lib/modules/имя-ядра/build/.config |grep SHWH
В разных дистрах в разных местах может конфиг лежать

Да вы голова !
Заработал mount+wh в toxzm в Убунту с ядром от Магеи

Причем с родным ядром

 root@ubuntu:~ cat /boot/config-5.4.0-37-generic  |grep SHWH
 CONFIG_AUFS_SHWH is not set
 root@ubuntu:~ zcat /proc/config.gz |grep SHWH
 gzip: /proc/config.gz: No such file or directory
 root@ubuntu:~ cat /usr/lib/modules/5.4.0-37-generic/build/.config |grep SHWH
 CONFIG_AUFS_SHWH is not set

С ядром от Магеи

 root@ubuntu:~ cat /boot/config-5.6.14-desktop-2.mga7  |grep SHWH
 CONFIG_AUFS_SHWH=y
 root@ubuntu:~ zcat /proc/config.gz |grep SHWH
 CONFIG_AUFS_SHWH=y
 root@ubuntu:~cat /usr/lib/modules/5.6.14-desktop-2.mga7/build/.config |grep SHWH
 CONFIG_AUFS_SHWH=y

Но одна проблема осталась. Последний смонтированный модуль в toxzm не отмонтируется
У мня это - toxzm/home0.xzm
Мой uirdsave.cfg

XZM0=toxzm/base0.xzm
MODE0='mount+wh'
REBUILD0='yes'
ADDFILTER0='boot etc opt root run usr shares var'
DROPFILTER0="$(cat /memory/layer-base/0/optional/base-filtr)"
SEARCHFILTER0="$(cat /memory/layer-base/0/optional/search-filtr)"

XZM1=toxzm/home0.xzm
MODE1='mount+wh'
REBUILD1='yes'
ADDFILTER1='etc home var'
DROPFILTER1="$(cat /memory/layer-base/0/optional/home-filtr)"
SEARCHFILTER1="$(cat /memory/layer-base/0/optional/search-filtr)"

Но модуль сохранения все же записался, т к toxzm как то исправил ситуацию
С родным ядром второй модуль сохранения писался всегда пустой

Так теперь получается патчить ядро?
Может разрабов Убунты озадачить ?

Помогли списки пакетов для сборки Магеи. Сборку веду на базе urpmi и списки у меня гораздо короче чем в МагОС а urpmi по зависимостям до устанавливает нужные пакеты.
По функционалу apt-get install это тот же urpmi
Имена пакетов в Магее и Убунту в основном совпадают

Проблема пропала. Теперь все чисто.
С ядром от Mагеи в Убунте все ок !
Может так и оставить ?

PS
Видимо aufs в ядре Убунту надо патчить актуальной версией
Может конфигуратор загрузчика uird дополнить функцией обновления aufs в активном ядре ?
Ну как для busybox и dracut
А то похоже что ядра в дистрах это очередное минное поле

Почему бы и нет. Работает раз. Ну или не использовать то где нужен shwh. У нас это mount+wh в конфигах toxzm и ключ -w у mkpfs. Вроде все.

Ну не патчить, всего лишь включить shwh и пересобрать. AUFS же есть в ядре.

У меня не работал еще режим mount.
Режим none+wh работал если модуль сохранения не монтировался в систему при загрузке
Если модуль от none+wh был смонтирован, допустим записан в папку base, то он не писался
Работал только режим copy

Хорошо бы в конфигуратор uird дополнить прогой тестирования ядра
Что бы не было лишней работы