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

Предлагаю изменения- https://cloud.mail.ru/public/3Kn4/54M5DVLCj
1) В /usr/lib/magos/rc.halt.pre/ должен присутствовать 20-deactivate
Без него при паковке модуля - большой листинг
2) это замена стр 288 в последнем UIRD

echolog "$(umount $(mount | egrep -v "tmpfs|zram|proc|sysfs" | awk '{print $3}' | sort -r) 2>&1) "

Замена :

echo "$(mount | egrep -v "tmpfs|zram|proc|sysfs" | awk '{print $3}' | sort -r)" > /tmp/LISTFS
umount "$(cat /tmp/LISTFS)" 2>&1
rm -rf /tmp/LISTFS

При таком варианте вроде наиболее устойчивая паковка модуля. Но пробовал и такой вариант

umount $(mount | egrep -v "tmpfs|zram|proc|sysfs" | awk '{print $3}' | sort -r) 2>&1

Но вроде паковка работает и временами сбой. А на первом варианте сбоев практически не было

3) Чистка экрана

У меня это стр 298

[ "$shell" = "yes" ] && shell_
clear -x

Отделяет большой листинг на экране от финальной паковки модуля.
Команда именно такая, а не clear
Иначе большой листинг при паковке модуля

Ваш вариант отличается тем, что umount получает иначе сортированный список. Если размонтировать в “не правильном” порядке, что-то может не размонтироваться. Можно запускать размонтирование раза три подряд, так должно быть надежно при любой сортировке.
По поводу 20-deactivate, это не к уирд, должно работать и без дополнительных костылей со стороны ос.
А что за ключ -x к clear? Не нашел в мане.

P.S. Пересмотрел код. Строку 288 можно вообще убрать. Не пробовали?
P.P.S Покажите кусок этого листинга, может там и проблем никаких нет, просто спрятать и все.

Обновил UIRD.
В ядре Магеи был баг. На зкране появлялся большой листинг и модуля не получалось
Но мне удалось приспособиться

  1. Стр 288 в свежем UIRD. :
    echolog "$(umount $(mount | egrep -v "tmpfs|zram|proc|sysfs" | awk '{print $3}' | sort -r) 2>&1) "

Я заменил на

echo "$(mount | egrep -v "tmpfs|zram|proc|sysfs" | awk '{print $3}' | sort -r)" > /tmp/LISTFS
umount "$(cat /tmp/LISTFS)" 2>&1
rm -rf /tmp/LISTFS

Можно конечно это одной командой сделать. Но были случаи что Магея чудит на сложных командах и не всегда их выполняет. Просто не хотелось рисковать.
Если большой листинг не проявится здесь, то он проявится либо в цикле отмонтирования либо при паковке модуля
И тут очень важный момент. Если эта команда плохо сработает, тогда и модуль не записывался.

  1. Что бы список удаленных пакетов не попал в логи паковки модуля в Стр 295

     [ "$shell" = "yes" ] && shell_
     clear -x
    

clear -x это набрал в терминале clear help :

     clear help
    Usage: clear [options]

    Options:
      -T TERM     use this instead of $TERM
      -V          print curses-version
      -x          do not try to clear scrollback

Если применить просто clear то цикл отмонтирования у меня снова выдавал большой листинг на экране

С такими правками все работало.
Сейчас в Магее ядро исправили и не знаю что с этими правками делать.
Можно и оставить на всякий случай.

Наверное не буду пока это добавлять. Не понимаю в чем разница.
По clear надо искать опции не в clear --help, а в busybox clear --help, я думаю.

Разница что было сбойное ядро и перед паковкой модуля на экран экран появлялся вывод какаких то команд и модуль сохранения не создавался.
После правки вывод какаких то команд на весь экран экран появляется перед паковкой модуля и модуль сохранения нормально пишется
Ну да теперь и сбойного ядра у меня нет. Проверить не где. Да ядра теперь нормальные.

Наверно вы правы

В Магее новая напасть. В ядре нет aufs.
Решил проверить OverlayFS.
Опция запуска - uird.union=overlay
К удивлению все загрузилось и сейчас пишу из OverlayFS
Но модуль сохранения не писался
В итоге заменил стр 191 из /usr/share/uird/modules.d/00uird/shutdown-uird.sh

[ "$MODE" = 'overlay' ] && mount -t overlay -o redirect_dir=on,metacopy=off,index=off,lowerdir=$SRC:${AUFS}-bundle overlay $AUFS

Вроде все заработало но ТЕНИ ???
А тени из модуля сборки сборки удаляются.
Если допустим штатно из drakrpm удалить пакет то теней в модуле сохранения не будет
Т е штатно из drakrpm систему обновлять нельзя.
Но создавал на рабочем столе папки и потом их удалял.
И в этом случае папки нормально удалялись.
Непонятно одно - почему тени появляются /memory/ovl/changes и почему тени удаляются из папки сборки модуля созранения ???
Первое сохранение все ок ?
Второе и т д тени пропадают .
Даже перевод OverlayFS сделоал - https://cloud.mail.ru/public/1REZ/9y2ogKGFZ
Там английский текст я не удалил. Чередуются абзац английский и потом его перевод
Но больше я им заниматься не буду. Нужных опций в OverlayFS вроде нет и баг с тенями вроде неустраним.

PS

Нет в OverlayFS можно работать но в режиме Changes
Уж чем AUFS не приглянулся ? Пишут что в AUFS код сложнее
Поэтому и сложнее что все отработано и опций больше
Есть еще неприятные эмоции но нужны ли они ?
Уж лучше я допилю установку aufs в исходники и сборку ядра с aufs

В оверлейФс тени сделаны иначе. Не смотрели девятый пример в инструкции к toxzm? Здесь в форуме.

Я и пробовал с режимом MODE0='none’
Изначально папка $AUFS даже не монтировалась.
Заработало с моими правками но выявились проблемы с тенеями.
Но режим MODE0=‘copy’ не пробовал возможно он то как раз и заработает
Но проблема не только в тенях. Вроде сырая оверлейФс по сравнению с aufs
Собрал скрипт и в системе проверял монтирование в оверлейФс :

mount -t overlay -o redirect_dir=on,metacopy=off,index=off,lowerdir=$SRC:${AUFS}-bundle overlay $AUFS

  1. Монтирование получалось только для чтения и после запуска скрипта вся система переходит в режим только для чтения. Т е с корня системы ничего под root уже нельзя что то удалить или добавить. Запускал под root. Может в этом дело.
  2. Оказалось что нельзя запускать скрипт с опцией index=on
    Пишет что оверлейФс уже смонтирован в /

В aufs таких сюрпризов не было !!!
Возможно опции оверлейФс при загрузке системы надо править.
И почитайте мой перевод вики для оверлейФс
Часто одни опции входят в конфликт с другими. Может что не понял или не так перевелось
но что то уж больше не хочется тратить время. И так неделю угробил зря.
В любом случае aufs функциональнее и надежнее

В aufs таких сюрпризов не было !!!
Возможно опции оверлейФс при загрузке системы надо править.

Точно !!!
В стр 2229 в /usr/share/uird/modules.d/00uird/livekit/livekitlib установил опции :

-o redirect_dir=off,metacopy=off,index=off

И вроде в ядре эти опции выключены.
Собрал загрузчик. Загрузился с overlay и… сюрпризы вроде исчезли
Но проблема с тенями осталась.
Получилось что в папке монтирования $SRC тени игнорируются.
Причем если в монтируемых слоях $SRC тень найдет свой файл то файл нигелируется.

OverlayFS - https://debuntu.ru/a/opisanie-failovoi-sistemy-overlayfs
Overlay-Arch - https://wiki.archlinux.org/index.php/Overlay_filesystem_(Русский)
Из Wiki - https://cloud.mail.ru/public/1REZ/9y2ogKGFZ

1) "redirect_dir"
Включено с помощью параметра монтирования или параметра модуля: "redirect_dir=on" или
параметра конфигурации ядра CONFIG_OVERLAY_FS_REDIRECT_DIR=y.
Если эта функция отключена, переименование (2) в более низком или объединенном
каталоге завершится ошибкой EXDEV ("Invalid cross-device link" - «Недопустимая связь
между устройствами»).
2) "inode index"
Включено с опцией монтирования или опцией модуля "index=on" или с
параметр конфигурации ядра CONFIG_OVERLAY_FS_INDEX=y.
Если эта функция отключена и копируется файл с несколькими жесткими ссылками
вверх, то это "разорвет" ссылку. Изменения не будут распространяться на
другие имена, относящиеся к тому же иноду.

Примечание. Параметры redirect_dir={off|nofollow|follow[*]} и nfs_export=on
конфликтуют с metacopy=on и приводят к ошибке.

Оверлай у меня работает !!!
Уже обновил систему. Удалил два лишних пакета и в нужных местах уже появились тени.
Изменения
Стр 191 в usr/share/uird/modules.d/00uird/shutdown-uird0.sh заменил

[ "$MODE" = "overlay" ] && mhddfs $SRC ${UFS}-bundle $UFS

Папку сборки AUFS заменил на UFS
Имя папки сборки желательно уникальное а то мало ли что…
И применил утилиту mhddfs. В Магее такой утилиты не было. Скачал с Федоры.
Утилита на удивление подошла к Оверляю.
Если в монтируемых слоях встречаются

Файл + Тень = Тень
Тень + Файл = Файл
Тень = Тень

В стр 2229 в /usr/share/uird/modules.d/00uird/livekit/livekitlib установил опции :

-o redirect_dir=off,metacopy=off,index=off

Конечно в /usr/share/uird/mkuird.cfg добавил

FS_KM=“aufs squashfs vfat msdos mhddfs iso9660 isofs xfs fuse nfs cifs udf nls_cp866 nls_utf8 reiserfs overlay ext3 ntfs btrfs”

Сам Оверлай в TOXZM похоже не будет работать как надо.
Вроде что бы ему разобраться с тенями надо собрать в TOXZM всю систему а не отдельные куски. А это проблематично
AUFS просто функциональнее и имеет больше опций настройки и вероятно все же более отработанная
В Оверлай висит папка /memory/ovl/lowerdir кот сейчас не используется.
Может сюда то и надо монтировать слои а не в /tmp/aufs ?

PS
Работают режимы none и copy
Можно ли режим mount+wh то же сделать на оверлай ?

Режим копи у меня и раньше работал, как описано в примере 9. Если сломалось надо искать где, тянуть сюда mhddfs считаю лишним.
Для моунт+вх надо видимо писать обработчик для теней.

Оверлей в TOXZM работает с тенями, Если тень находит файл то он нигелируется.
Но после монтирования все тени игнорируются в том числе и нужные
Это те тени кот встретят свой файл после запуска системы.
В AUFS есть опция и тени не удаляются после монтирования.В Оверляй такой опции нет и никогда не будет. При штатном запуске системы Оверляй будет нормально работать.
И mhddfs это выход из тупика. Тени в TOXZM на месте и все работает !!!
И как эти тени искать ? Имена у тени и файла в Оверлай совпадают.
Из вики

Белая область создается как символьное устройство с номером устройства 0/0. Когда белое пятно обнаруживается на верхнем уровне объединенного каталога, любое совпадающее имя на нижнем уровне игнорируется, а само белое пятно также скрывается.

А символьное устройство это может быть не только тень. Найдется много лишнего
А утилита mhddfs гораздо эфективнее
В общем успехов конечно в борьбе с тенями.

Тени в оверлейфс это файлы с нулевыми правами. Легко находятся find. Посмотрите уже девятый пример там это есть.
Mhddfs это псевдо файловая система объединяющая несколько папок в одну, запись. в следующую папку начинается после заполнения предыдущей. То есть это не ауфс и не оверлейфс. Грубо mhddfs может из несколькиих маленьких папок сделать одну большую. При этом она даже не может записать файл частично в одну папку частично в другую.
З.Ы. Несколько лет назад активно его использовал чтоб увеличить место на сервере за счет объединения mhddfs нескольких яндекс дисков смонтированных по вебдав. Неторопливо, но работало.

1 лайк

Вот из 9 примера. Поиск теней

  • Пришли обновления и что то из библиотек удалилось
  • Удалил для сонтроля две папки
    /usr/local/etc и /usr/local/src
    Запустил в терминале команду

find /memory/changes/ -perm 0000 |sed 's:/memory/changes::' > /tmp/whove

Результат в whove - https://cloud.mail.ru/public/h6q1/4ypWhACis

Ну две тени я сделал + тени от обновления + другие

Конечно вы где то правы и все надо делать в одной системе.
Если использовать mhddfs то при паковке модуля mksquashfs неоднократно прерывается.
Хотя все пишется вроде ок. В Оверляй mksquashfs не прерывается
Непонятно чо за прерывания пэтому выбора вроде нет. Остается ваш 9 пример.
А есть ли пример успешного использования Оверляй ?

Нашел инфу - https://qastack.ru/ubuntu/109413/how-do-i-use-overlayfs

  1. XZM0=zsave.xzm
    MODE0=‘none’
    REBUILD0=‘yes’

    XZM1=zwhiteout.xzm
    MODE1=‘copy’
    REBUILD1=‘yes’
    ADDFILTER1="$(find /memory/changes/ -perm 0000 |sed ‘s:/memory/changes::’)"

  • папка /memory/changes в Оверлай в TOXZM пустая. Вместо ее /memory/ovl/changes

  • тени в Оверлай не копируются
    В системе удалил /usr/local/doc и пробовал копировать

     cp /memory/ovl/changes/usr/local/doc  /tmp/1
    cp: невозможно открыть '/memory/ovl/changes/usr/local/doc' для чтения: Нет такого устройства или адреса
    
  • Для верность в конфиге задал

ADDFILTER1="$(find /memory/changes/ -perm 777 |sed 's:/memory/changes::')"

Найденные файлы нормально скопировались и модуль записался

PS

Так что пока, к сожалению, есть рабочий вариант с mhddfs
Может у разрабов в Оверлай спросить пусть они и думают.
Есть в Оверлай dentry- это из - https://debuntu.ru/a/opisanie-failovoi-sistemy-overlayfs

dentry — объект VFS, содержащий информацию о директориях ФС и существующий только в памяти файловой системы и не хранится на диске. Если я правильно понял, то предназначен для уменьшения обращений к ФС при перечитывании содержимого каталогов.

Может в нем и лежит инфа о тенях. Только где вот он ???

Но перенес тени на диск или в папку /memory

mv -b /memory/ovl/changes/usr/local/doc /memory/layer-base/0/1

Несложно сделать

Про путь с ovl вы верно заметили, просто пример писался когда пути у ауфс и оверейфс были одинаковыми.

Непонятно что /memory/changes и /memory/ovl/changes это вроде одно и то же
и две разные папки. Вероятно можно одну оставить
Или /memory/changes для AUFS
Или /memory/ovl/changes для OverlayFS

Да так и есть. …/ovl/changes пришлось добавить из-за особенностей оверлейфс.

Сегодня пришла в голову почти гениальная мысль - “А не почитать ли инструкцию на AUFS”
Перевел README для AUFS. - https://cloud.mail.ru/public/1REZ/9y2ogKGFZ
Вроде с установкой AUFS в ядро особых проблем нет
Вроде и к лучшему что в Магее AUFS не стали делать. Версия AUFS все равно старая и надо было обновлять