А кусок листинга можете показать. Чтоб понять в чем дело. Предполагаю, что в последовательности отключения.
Предлагаю изменения- 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.
В ядре Магеи был баг. На зкране появлялся большой листинг и модуля не получалось
Но мне удалось приспособиться
- Стр 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
Можно конечно это одной командой сделать. Но были случаи что Магея чудит на сложных командах и не всегда их выполняет. Просто не хотелось рисковать.
Если большой листинг не проявится здесь, то он проявится либо в цикле отмонтирования либо при паковке модуля
И тут очень важный момент. Если эта команда плохо сработает, тогда и модуль не записывался.
-
Что бы список удаленных пакетов не попал в логи паковки модуля в Стр 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
- Монтирование получалось только для чтения и после запуска скрипта вся система переходит в режим только для чтения. Т е с корня системы ничего под root уже нельзя что то удалить или добавить. Запускал под root. Может в этом дело.
- Оказалось что нельзя запускать скрипт с опцией 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 - Описание файловой системы OverlayFS | Debuntarium
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
-
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- это из - Описание файловой системы OverlayFS | Debuntarium
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 пришлось добавить из-за особенностей оверлейфс.