Белый вполне норм.
Или зелёный, который там тоже имеется.
Это как например?
Понедельник - зеленый,
Вторник - синий и т.д.
Или просто случайный. Но на счет белого тоже в общем не против.
Тогда белый да и всё 
Перекрасил, и еще буковки UIRD сделал мелкими. Мне кажется лучше. А то не очень понятно, выключал вроде МагОС, а тут UIRD какой-то
Дабавил поддержку ненумерованных секций. Такое может быть нужно как в случае Ингваро, чтоб какой то модуль гарантированно подключался последним даже после срабатывания maxcopysize у другой секции. Например:
XZM0=mod.xzm
XZM_last=last.xzm
После срабатывания MAXCOPYSIZE для секции XZM0 получим секции:
XZM0=mod.xzm
XZM_last=last.xzm
XZM1=mod-DATE.xzm
Сперва попорядку подключатся нумерованные секции, затем по алфавиту остальные. То есть last.xzm будет последним. Конечно это имеет смысл видимо только когда MODE_last=copy. Для ненумерованных модулей тоже работает MAXCOPYSIZE, но смысла особого это не имеет, так как перед созданием нового модуля MODE_last будет переведен в mount и смысл “последнего” модуля теряется.
Так что Ингваро, можете пробовать. В вашем случае ненумерованная секция для 88-magos.xzm mode=copy, rebuild=no, maxcopysize=’’
З.Ы. Подписал на шарике вместо UIRD - $LIVEKITNAME из initvars. То есть тоже что в приветствии уирда. Просто текстом на хвостике шарика. Но пролетает так, что не успеваю заметить 
Надо еще думать. Так-то $LIVEKITNAME логичнее.
Попробовал зеленый и вполне норм.
Только при reboot у меня шарик почему то запускается и сохранение изменений включается.
Это в toxzm не настроено или я что недосмотрел ?
Цвет несложно наверно так настроить
- Вывод mksquashfs в зеленый и зеленый шарик
- Если reboot , то шарик белый, но без сохранение изменений
В папкке /usr/share/plymouth восстанавливается состояние по дефолту
Пробовал работать с сохранением без plymouth и появилась попытка системы преждевременного отмонтирования модулей. А это уже серьезнее
У меня один магос-модуль кот работает на три дистра
Тут и знаний системы не хватает да и сложности. Так что буду запускать как то изменения до магос-модуля
Чтобы при ребуте не сохранялись изменения нужен параметр uird.shutdown=haltonly, отключать при ребуте всегда считаю не правильным.
Разный цвет шарика при разных условиях сделать можно, давайте - предлагайте.
Что по этому поводу?
Вот же.
- Самый простой
- удалить файл из системы выключиться с сохранением
- включить систему и снова поместить в систему этот файл и выключиться с сохранением
- если включить систему и файл появится в системе, то зависших теней нет
- Через сервис для systemd
Изменения появляются в /memory/changes/etc/systemd/system
Лучше всего проверять на сервисе cups ( формирует целых три тени )
Например cups уже запущен в системе при старте
- остановить сервис
systemctl stop cups
- сделать disable для сервиса
systemctl disable cups
- выключится с сохранением
- запустить систему
- сделать enable для сервиса
systemctl enable cups
- не лишне будет проверить
systemctl start cups
- выключится с сохранением
- запустить систему
- если сервис запущен в системе
systemctl ststus cups
То зависших теней нет
ЗЫ
Это баг aufs а не МагОС или toxzm
Если при монтировании /memory/changes и старого модуля в образ aufs имеются тени, то эта тень уже оторвана от корня системы и ей не с кем нигелироваться.
Поэтому она висит и ее надо удалять принудительно для MODE0=‘mount
Или пользоваться режимом MODE0=copy
Однако поторопился. - Концепт режима сохранения в модуль
Были проблемы. Тестировал через сервис cups.
Этот нехороший … cups формирует целых три тени. И одна тень в этом варианте удалялась а две другие почему то оставались
На одиночных тенях все работало
Баг наблюдался при записи от uird
При запуске в системе или от 81-savetomodule все работало
Уже вроде исправил. Может завтра выложу. Пока тестирую
Есть же вроде такая пословица : “Не трогай систему и она не подведет”
Я вот тронул, да еще сохранялся и понеслось.
AlexL все со своим MagicOS. Сделал а потом не признал это за баг
Пришлось делать свою версию сборки
Пробовал по этой схеме. На примере /usr/bin/leafpad. Скопировал его предварительно в другое место после чего удалял, перегружался и возвращал на место так как Вы описали.
С модулем в режиме copy проблем нет совсем, исчезает и появляется как положено.
С режимом mount проблемы есть, но не зависшие тени, а то что я описывал. Первая загрузка (модуля еще нет, только конфиг) меняю режим на mount, удаляю leafpad перегружаюсь. Склеек еще не было по этому тень на месте, она работает и leafpad отсутствует. Если перегрузить еще раз то leafpad вернется и больше не исчезнет хоть удаляй хоть нет. Но и зависших теней я так и не увидел. Теней просто нет. Никаких.
А теперь интересное (переменные с дефолтными значениями убрал чтоб не отвлекали):
XZM0=mac-dc0ea1fbbb19.xzm
MODE0=‘mount’
REBUILD0=‘yes’
XZM1=wh.xzm
MODE1=‘copy’
REBUILD1=‘yes’
ADDFILTER1=’.wh.’
То есть один модуль в режиме моунт, в него пишется все. Второй в режиме copy, в него пишутся только тени. Оба rebuild=yes. И все, проблема решена :))
З.Ы. Матерая штука у нас получилась. Как обычно с уирдом - новые возможности сами лезут
З.З.Ы. А зависших теней так сделать и не получилось. Есть видимо какой-то подвох о котором вы забываете сказать.
Так зависшие тени появляются при записи в один модуль.
Если каждый раз писать изменения в новый модуль, то при сборке системы, все что должно нигелироваться - нигелируется
Хорошо включать отключать сервисы для systemd с выключением с сохранением
Тут все делает чисто система. На сервисах то я и увидел впервые зависшую тень,
Это как ?
- удаляем файл из системы. В /memory/changes появляется тень и выключиться с сохранением
Тень записывается в XZM1=wh.xzm - Возвращаем файл в систему. Файл пишется в XZM0=mac-dc0ea1fbbb19.xzm
Теперь получились два модуля в XZM0 - файл а в XZM1=wh.xzm - тень файла
Стартует XZM0 и потом XZM1
Тень стартует последняя и файла в системе не будет
Или я не прав ?
Я в один и писал
Думаю нет. Грузим первый раз - файл в системе, модулей еще нет. Перегружаем, чтоб создать модули (хотя не обязательно). Удаляем файл, в ченджез появится тень. Перегружаем, в моунт-модуле ничего нет, в копи-модуле - тень. В системе файл не видно. Возвращаем файл на место в системе, и в ченджез появляется файл, а тень исчезает (аннигилируется как вы говорите). Перегружаем в моунт-модуле файл, в копи-модуле пусто. Файл в системе есть.
Сделал удаление зависших теней - https://cloud.mail.ru/public/4dnk/n5s3MaEhF
Тут сам shutdown-uird.sh и whtoxzm.log (логи удаления .wh.)
Логи whtoxzm.log пишутся в /memory/layer-base/0/optional
В shutdown-uird.sh добавил п/прог WHDELL
Запуск чистки ( стр 193) из
if [ -f “$SAVETOMODULENAME” -a “$MODE” = “mount” ]; then
Мои действия
- Грузим чистую систему.
Модуль пишется из /memory/changes
Тут все чисто и зависших теней не может быть
И п/прог WHDELL не работает
- Перенес на флэшку /etc/a2ps.cfg
В /memory/changes появилась тень .wh.a2ps.cfg - Удалил из системы сервис cups
systemctl stop cups
systemctl disable cups
В /memory/changes появились тени
~/etc/systemd/system/multi-user.target.wants/.wh.cups.path
~etc/systemd/system/sockets.target.wants/.wh.cups.socket
~etc/systemd/system/.wh.printer.target.wants
- Выключил с сохранением
Первая запись toxzm-модуля, все чисто, WHDELL не работает и логов работы WHDELL нет - Грузим систему с созданным модулем модулем
- При второй заиси toxzm-модуля в режиме mount монтируется
/memory/changes + toxzm-модуль от первой записи (там тени от первой записи)
- Перенес с флэшки a2ps.cfg. В /memory/changes появился ~etc/a2ps.cfg
- Включил в системе сервис cups
systemctl enable cups
systemctl start cups
В /memory/changes появились файлы
~/etc/systemd/system/multi-user.target.wants/cups.path
~etc/systemd/system/sockets.target.wants/cups.socket
~etc/systemd/system/printer.target.wants
-
И вот он момент истины
Монтируются в toxzm
mount -t aufs -o shwh,br:$SRC=rw:${AUFS}-bundle=ro aufs $AUFS
{AUFS}-bundle- прошлая запись
$SRC - /memory/changes
Направление монтирования справа на лево
Теперьто в $AUFS и встречаются тень файла с прошлой записи и следом сам файл
- Выключаемся с сохранением
- Запускаем систему
Файлы на месте. Логи
WHF=/tmp/aufs/etc/systemd/system/sockets.target.wants/.wh.cups.socket
FS >=/tmp/aufs/etc/systemd/system/sockets.target.wants/cups.socket
WHF=/tmp/aufs/etc/systemd/system/sockets.target.wants/.wh.cups.socket (Delete)WHF=/tmp/aufs/etc/systemd/system/multi-user.target.wants/.wh.cups.path
FS >=/tmp/aufs/etc/systemd/system/multi-user.target.wants/cups.path
WHF=/tmp/aufs/etc/systemd/system/multi-user.target.wants/.wh.cups.path (Delete)WHF=/tmp/aufs/etc/systemd/system/.wh.printer.target.wants
FS >=/tmp/aufs/etc/systemd/system/printer.target.wants
/tmp/aufs/etc/systemd/system/printer.target.wants/cups.service
WHF=/tmp/aufs/etc/systemd/system/.wh.printer.target.wants (Delete)WHF=/tmp/aufs/etc/.wh.a2ps.cfg
FS >=/tmp/aufs/etc/a2ps.cfg
WHF=/tmp/aufs/etc/.wh.a2ps.cfg (Delete)
Полные логи можно найти по ссылке
Сделал что в whtoxzm.log пишутся все найденные тени
И отдельно отмечаются удаленные. На мой взгляд это удобно.
Чистка WHDELL сначала удаляет тени а потом тени теней
Дальше aufs не сопротивляется и окончательно лишние тени удаляются
ЗЫ
Сложности были с uird
Сылки в командах почему то не воспринимались.
Условие if [ -e “$FS” ] ;then для сервиса cups почему то отрабатывала всего одну из тех теней
Это видимо сам bash имеет ограничения
В системе WHDELL работает в любых вариантах
Перешел на поиск файла через find
B find не подвел !!!
Забыл совсем написать Тени в модуль при монтировании в aufs образ не проходят
Вот и получалось первая запись с тенями (тут нет монтирования) а во второй теней уже нет
- Удалить файл из системы и выключиться с сохранением
- загрузить систему и файла нет
- выключиться с сохранением
- загрузить систему и файл снова появляется
Изменил монтирование стр 191 в моей версии shutdown-uird.sh
mount -t aufs -o shwh,br:$SRC=rw:${AUFS}-bundle=ro aufs $AUFS
Тут то и появляются зависшие тени.
Правильно ли я понял, что вы изменили параметры монтирования внутренней ауфс в шатдаун для того чтоб появились зависшие тени?
Если так, то даже не знаю что ответить…
З.Ы. Вкрался косячек. Проявляется при одновременном использовании моунт и копи секций. Если обе ребилд=yes и моунт секция выше копи. Причину нашел, сегодня починю.
Иначе тени в модуль при монтировании не проходили
На 81-savetomodule я так обновления писал на тестовой сборке Магеи
И все было ок
Так я ж Вам пол темы объясняю, что тени и не должны проходить в модуль если он в режиме маунт. Для теней - копи. Используйте совместно с маунт и нет проблем. Это так и задумано.
Пробовал но XZM1 у меня не запустился и вроде неправильно задал меню
Этот режим в принципе рабочий и может наиболее аффективный, но все же это как бы комбинированный режим. Вроде как mount-copy
У меня же получился чистый mount и он протестированный и надежный
Да скорость паковки у toxzm выше но меня и 81-savetomodule устраивает
Может тут эффективность ниже зато простота и чистый mount, кот более удобный
в анализе багов. Все в одном модуле.
Если не лазить в систему то может toxzm и предпочтительнее