С ядром от Магеи Убунту работает и даже Plymouth в uird запускается
Но это с загрузчиком сконфигурированным а Магее
Если загрузчик для ядра от Магеи сконфигурировать для uird в Убунту то Plymouth запускается только из системы
С родным ядром от Убунту uird делает загрузчик ок
Но в стр 32 в /usr/share/uird/mkuird.cfg
Снова переписан разбор ADDFILTER и DROPFILTER c устранением ошибок с папками. Просьба проверить. Еще разок напоминаю логику. Если в фильтре указана строка которая начинается со слэша, то проверяться она будет только от корня, если с любого другого символа то проверяется как шаблон для grep по полному списку файлов и папок. Сделано это чтоб при указании к примеру /bin не зацепило и /usr/bin тоже.
Михаил, фильтр который получился работает намного быстрее чем то что в 80-savetomodule, может и там поменять? В скрипте для toxzm выглядит так:
[ -f /tmp/allfiles ] || find $SRC/ | sed -e 's|^'$SRC'||' -e '/^\/$/d' > /tmp/allfiles
: > /tmp/savelist.black
: > /tmp/savelist.white
for item in $ADDFILTER ; do
if [ -d "$SRC$item" ] ; then
echo "^$item" >> /tmp/savelist.white
else
echo "$item" >> /tmp/savelist.white
fi
done
grep -q . /tmp/savelist.white || echo '.' > /tmp/savelist.white
for item in $DROPFILTER ; do
if [ -d "$SRC$item" ] ; then
echo "^$item" >> /tmp/savelist.black
else
echo "$item" >> /tmp/savelist.black
fi
done
(cat /tmp/allfiles | grep -f /tmp/savelist.white \
| awk -F"/" '{ A = $1 ;{for (i=2; i<=NF; i++) { A = A "/" $i ; print A} } }' \
| sort -u | cat - /tmp/allfiles |sort |uniq -u
grep -q . /tmp/savelist.black && cat /tmp/allfiles | grep -f /tmp/savelist.black ) \
|sort -u >> /tmp/$n/excludedfiles
Здесь DROPFILTER и ADDFILTER это списки того что добавить удалить, а SRC это /memory/changes
if [ -z "$ADDFILTER" ] ;then
echo "/.cache" >> /tmp/$n/excludedfiles
echo "/.dbus" >> /tmp/$n/excludedfiles
echo "/run" >> /tmp/$n/excludedfiles
echo "/tmp" >> /tmp/$n/excludedfiles
echo "/dev" >> /tmp/$n/excludedfiles # maybe it is not necessary
echo "/proc" >> /tmp/$n/excludedfiles # maybe it is not necessary
echo "/sys" >> /tmp/$n/excludedfiles # maybe it is not necessary
echo "/mnt" >> /tmp/$n/excludedfiles # maybe it is not necessary
else
cleaner_root
fi
Что не разрешено в ADDFILTER то из корня удаляется
Мало ли что может оказаться в корне. И в разных дистрах ADDFILTER может отличаться
Для случая если ADDFILTER пустой то будет работать ваш код.
Разделил я DROPFILTER.
Теперь у меня в DROPFILTER фильтр только со слэшем
/etc/.updated
/etc/mtab
/etc/hostname
/etc/initvars
/etc/fstab
и так далее
А для поиска файлов и папок для удаления сделал фильтром SEARCHFILTER
>/tmp/search.black
for item in $SEARCHFILTER ; do echo "$item" >> /tmp/search.black ; done
grep -q . /tmp/search.black && grep -f /tmp/search.black /tmp/allfiles >> /tmp/$n/excludedfiles
Изменения тестировались уже больше месяца
Поиск ведется быстро и зависаний нет
Допустим теперь все файлы и папки где есть слово MagOS удаляются из образа для записи модуля сохранения. А это сократило DROPFILTER что несомненно удобно.
PS
А что теперь /tmp/savelist.white и /tmp/search.black теперь не удаляются после формирования excludedfiles ?
Что-то не пойму чего вы добиваетесь этими изменениями. Давайте словами опишу как все задумано, может мы по разному понимаем как должно быть.
Фильтры ADDFILTER и DROPFILTER идейные последователи savelist для 80-savetomodule и логика их работы максимально похожа. Если в savelist пусто, то сохраняется все не удаляется ничего. Аналогично и тут.
Если в ADDFILTER пусто, то его значение заменяется на ‘.’, а под “греп точка” подходят любые строки. То есть - разрешаем все. Иными словами дефолтное значение ADDFILTER=’.’
DROPFILTER проверяется как есть, то есть если пусто то ничего не удалять.
Список файлов и папок который получился после прохождения полного списка из /memory/changes через эти фильтры записывается в файл /tmp/НомерСекции/excludedfiles, который используется mksquashfs при запаковке. Кроме этого в этот файл дописываются папки, которые однозначно не нужно сохранять /proc, /sys, /tmp, а также рутимены aufs из корня.
Если что-то работает не так или вам не хватает в этой логике чего-то, давайте обсуждать. Из файла с вашими правками я не понял чего вы добивались.
Удаляются перед обработкой следующей секции.
Если записать все в дропфильтр работать будет также. Имею ввиду добавить в дропфильтр все что у вас в searchfilter.
Циклы в баш работают крайне медленно, именно убрав циклы получилось ускорить в несколько раз обработку фильтров.
Да. Был косяк. Не сразу обнаружился, потому, что с моими фильтрами не проявлялся.
Запустил режим machines от toxzm. Изменения пишутся в machines/dynamic
Фильтры поместил machines/filtres
Но опять же один конфиг и два лога в папке machines
А если конфигов будет 5 или 10 ?
Логи конечно вещь нужная но я смотрю их во время отладки
Только куда их поместить ?
Ну так чтоб не мешали и что бы всегда были под рукой
Может в machines/log ?
Хорошо бы чтобы у юзера был выбор и он мог писать путь до логов в конфиге ?
Папку machines я наверно зря выбрал. Все же это папка для старой версии. Не получится ли каких нибудь конфликтов ?
Может лучше допустим в папке toxzm собирать machines от toxzm?
В режиме machines от toxzm конфиг формируются по умолчанию
Но после запуска системы приходится править конфиг
Могу ли я отредактировать формирования конфига по умолчанию уже с нужными параметрами ?
Думаю, что в вашем случае проще разнести конфиги по подкаталогам. Указание пути к логам можно сделать только относительно конфига, в любое место не получится, все же размонтировано. По этому думаю, что смысла нет.
Да, такая возможность есть. Смотрите последний абзац инструкции для toxzm здесь в форуме.
if [ -d $CFGPWD -a $log != 'no' ] ;then
logname=$(echo ${CHANGESMNT##*/} | sed 's/.cfg$/_log.tar.gz/')
[ ! -d "$CFGPWD/toxzmlog" ] && mkdir -p $CFGPWD/toxzmlog
[ -f $CFGPWD/toxzmlog/$logname ] && mv -f $CFGPWD/toxzmlog/$logname $CFGPWD/toxzmlog/${logname}.old
cd /tmp ; tar -czf $CFGPWD/toxzmlog/$logname * ; cd /
fi
В папке конфига появляется папка toxzmlog
Сюда переносятся все логи конфига
А так же bak-модули, кот появляются после записи модуля с изменениями
Стр 226
Перенос bak-модулей с логами не связаны. Они должны все равно переноситься в toxzmlog
Это я просто попробовал для эксперимента. Может лучше не надо переносить ?
Как то даже непривычно.
С другой стороны чистые загрузочные папки. Как бы улучшена стабильность загрузки, т к ничего лишнего.
PS
А что с 01-background
В последней сборке MagOS нет подписей на фоновую картинку для рабочего стола.
Как раз мой случай. У меня в /memory/layer-base/0 два конфига
saveadmin.cfg - режим обновления системы и модуль пишется в папку base
savetoxzm.cfg - обычная работа и модуль пишется в папку toxzm
Все логи переносятся в папку toxzmlog
Сделал аналог machines.
Конфиг лежит в toxzm/machines machines.cfg
XZM0=
MODE0='mount+wh'
REBUILD0='yes'
ADDFILTER0='boot etc opt home root run usr shares var'
DROPFILTER0="$(cat /memory/layer-base/0/toxzm/filtres/base-filtr)"
SEARCHFILTER0="$(cat /memory/layer-base/0/toxzm/filtres/search-filtr)"
SQFSOPT0=''
MAXCOPYSIZE0=''
Сюда же пишутся модули
В toxzm/machines появляется свой toxzmlog куда переносятся логи machines
В принципе удобно.
Если папок с конфигами будет больше то в каждой будет свой toxzlog
Привет от Магеи 8
Пришло новое ядро аж 5.9.11-desktop-2.mga8
Но что то с UIRD начались проблемы.
Свежий UIRD,
Появляется проблема со стр 288 в 99-shutdown-uird.sh
А проблема в том, что вместо компактного вывода логов, появляется листинг на 2/3 экрана
Но модуль пишется раза три а потом опять большой листинг и зависание UIRD
Но на старом ядре в Магее все ок !
Вот виновный цикл :
Что то больно мудреный. Можно ли задать этот цикл попроще и желательно без echolog
Все таки раз модуль пишется то это вероятно синтаксис изменился на новом ядре
В цикле нет ничего страшного. Пытается размонтировать все железо. Где-то с лета появилась ругань от системд, в том числе и в магос. Жить не мешает,как лечить не знаю, возможно вы об этом?
Пробовал вообще этот цикл удалить так модуль не пишется
Это на старом ядре жить не мешает а на новом ядре от Магеи результаты работы цикла попадают на экран.
Хотя модуль все таки пишется,
А на старом ядре результаты работы цикла не попадают на экран.
Вроде такая проблема.
А так ли уж нужно отмонтировать все подряд ?
Может как то ограничить этот цикл ?
Появляется проблема со стр 288 в 99-shutdown-uird.sh
А проблема в том, что вместо компактного вывода логов, появляется листинг на 2/3 экрана
Но модуль пишется раза три а потом опять большой листинг и зависание UIRD
Но на старом ядре в Магее все ок !
Удалось приспособиться.
Вот мой 99-shutdown-uird.sh - https://cloud.mail.ru/public/3Kn4/54M5DVLCj
Это из /run/initramfs/usr/lib/dracut/hooks/shutdown
В /usr/lib/magos/rc.halt.pre/ должен присутствовать 20-deactivate
Без него при паковке модуля - большой листинг
Вот измененный цикл (стр 289)
Отделяет большой листинг от финальной паковки модуля.
Команда именно такая, а не clear
Иначе большой листинг при паковке модуля
В измененном цикле большой листинг выдается на стр 290
umount "$(cat /tmp/LISTFS)" 2>&1
Удивительно что ничего команда не отмонтирует сервисы из LISTFS, а только выдает большой листинг. А полностью отмонтирует сервисы из LISTFS именно основной цикл.
PS
В Магее пришло новое ядро где большого листинга при паковке модуля уже нет.
Тут с новыми ядрами быстро !!!
Скоро перепакую сборку. Будут ли какие дополнения, пока могу что то проверить ?