Привет всем
На данный момент среди шаблонов есть несколько с очень странным поведением. и ни как не соответствующие своему названию,
первый набор шаблонов это smplayer/icons-update
вот все они для всех версий утилит
# find $(find /var/lib/layman/calculate/profiles/templates/ -name icons-update | xargs -n1 dirname ) -type f| xargs -n1 -iFF sh -c "echo -e '\n####\tFF'; cat FF"
#### /var/lib/layman/calculate/profiles/templates/3.1/1_ac_install_merge/smplayer/icons-update
# Calculate exec=/bin/bash ac_install_disk==off path=/tmp name=icons-update.sh
echo "Updating icon cache"
for i in /usr/share/icons/*;do gtk-update-icon-cache -ft $i &>/dev/null; done
#### /var/lib/layman/calculate/profiles/templates/3.1/1_ac_install_merge/smplayer/.calculate_directory
# Calculate append=skip merge()!=&&ac_install_disk==off&&pkg(x11-libs/gtk+)!=
#### /var/lib/layman/calculate/profiles/templates/3.1-beta/4_ac_install_live/1-live/smplayer/icons-update
# Calculate exec=/bin/bash path=/tmp name=icons-update.sh
for i in /usr/share/icons/*;do gtk-update-icon-cache -ft $i &>/dev/null; done
#### /var/lib/layman/calculate/profiles/templates/3.1-beta/4_ac_install_live/1-live/smplayer/.calculate_directory
# Calculate append=skip belong()!=&&ac_install_system!=up&&pkg(x11-libs/gtk+)!=
#### /var/lib/layman/calculate/profiles/templates/3.0/install/1live/smplayer/icons-update
# Calculate exec=/bin/bash path=/tmp name=icons-update.sh
for i in /usr/share/icons/*;do gtk-update-icon-cache -ft $i &>/dev/null; done
#### /var/lib/layman/calculate/profiles/templates/3.0/install/1live/smplayer/.calculate_directory
# Calculate append=skip belong()!=&&ac_install_system!=up&&pkg(x11-libs/gtk+)!=
Даже не знаю с чего начать вопросы о них, просто перечислю:
- одни и те же действия выполняются дважды
1_ac_install_mergeи4_ac_install_live - название (
1live/smplayer) не соответствует охватываемым файлам/usr/share/icons/* - для чего вообще это надо? Updating icon cache, у себя я отключил это, и все прекрасно отображается
- допустим smplayer нормально не регистрирует свои иконки, но тогда разве это не повод писать в гентушный багтрекер?
- эти шаблоны отрабатывают на системе где ВООБЩЕ НЕТ smplayer-а
- они отрабатывают при загрузке с liveCD. ЗАЧЕМ?
тем самым система с самого начала <<отжирает на @tmpfs@ лишние 170MB>>
Скорее всего - этот шаблон остался от каких-то старых шаблонов, явно делавших что-то очень важное, но теперь он потерял всякий смысл, имхо. Предлагаю удалить его.
4_ac_install_live/1-live/00-calculate-install
Из ряда в общем-то полезных при любой загрузке шаблонов выбивается один - prepare-scratch
# Calculate exec=/bin/bash os_install_scratch==on path=/tmp
find #-cl_chroot_path-#/boot -exec touch {} \; &>/dev/null
find #-cl_chroot_path-#/lib* -maxdepth 1 -name "ld*so" -exec touch {} \; &>/dev/null
find #-cl_chroot_path-#/usr/share/grub -exec touch {} \; &>/dev/null
find #-cl_chroot_grub-#/workspace -maxdepth 1 -regextype posix-egrep -regex ".*(bin|lib.*|etc|usr|var|opt|boot)$" |
while read line;do
linkname="workspace/`basename $line`"
[[ -L ${linkname} ]] || ln -sf ${linkname} #-cl_chroot_grub-#/`basename $line`
done &>/dev/null
* <<Этот скрипт отрабатывает в том числе и при загрузке с LiveCD>>. В этом случае пользы от него никакой. А вред - <<лишние 20-60MB памяти расходуются>> непонятно на что
* Идем дальше, по поводу первой строки - это понятно.
В случае scratch-установки, до старта этого скрипта /boot оказывается лишь в livecd.squashfs, соответственно системе грузиться будет несчего, соответственно touch на aufs workspace=rw заставит скопировать в него файлы из squash-архива
* find /usr/share/grub - тоже понять можно, хотя наверно хватило бы лишь шрифтов:
find /usr/share/grub -name '*.fb2' ......
* А вот модули тут совсем ни к чему. Ну действительно, сборка корня происходит еще из initramfs
grep 'mount -t aufs' /usr/share/genkernel/defaults/linuxrc
if mount -t aufs -o ro,udba=reval,br:${NEW_ROOT}/workspace=rw:${NEW_ROOT}/delta=ro+wh:${NEW_ROOT}/calculate=ro none /union;
mount -t aufs -o ro,udba=reval,br:${NEW_ROOT}/delta=rw:${NEW_ROOT}/calculate=ro none /union/mnt/builder
и chroot происходит в уже смонтированный aufs-пирог. Так что и эта строка тут ник чему(<<минус ~50MB>>)
- смысл последнего шаманства, если честно, вообще - сложно укладывается в моей голове
возможно это действо (вкупе с /lib) нужно чтоб можно было загрузить систему и безinitramfs, голым ядром, этакийfallback-режимв котором монтирование aufs не происходит.
Но почему тогда не разделить эти пути по смыслу?
Директорииbin,lib,usrиoptзацепить через/delta, а в/workspaceоставить лишьetc,varи можноboot.
Дело в том, что при внесении серьезных изменений в систему вcl-builder, работать становится невозможно
вот представьте себе, я обновляю систему, ставлю новые пакеты
и после этого у меня в системе присутствует каша из старых модулей(сохранившихся в workspace) и новых утилит, требующих новых версий либ.
И если имена файлов старых и новых пакетов пересекаются, видны будут старые
Особенно приятно будет так поломать openrc
Если же перенаправить ссылки наbin,lib,usrв/delta, то все файлы нормально смогут обновиться
А можно вообще /livecd.squashfs и /boot из iso-шки распаковывать не в корень партиции, а в директорию / #-os_install_linux_shortname-#-#-os_linux_build-#-#-os_install_arch_machine-# и вынести squash и delta в корень симлинками, подобно тому, как я описал это тут
тогда для fallbask-а не надо будет копировать /lib, или вообще загружать систему из /boot/{vmlinuz,initrd} и livecd.squashfs отдельным пунктом в меню grub.cfg в режиме LiveCD
/etc/init.d/calculate
Тут я хочу поговорить не о шаблоне, а о загрузочном скрипте.
Для чего в нем в режиме LiceCD понадобилось закидывать кучу файлов в tmpfs - я понять не могу
tail -n+138 /etc/init.d/calculate| head -n6
local roottype=`variable_value main.os_root_type`
if [[ $roottype == "livecd" ]]
then
touch /* /bin/* /sbin/*
udevadm trigger --action="add" --subsystem-match=net
fi
Я уже поднимал этот вопрос тут http://www.calculate-linux.ru/issues/515
Но пока ответа нет.
Если это из той же оперы откуда и prepare-scratch, то при чем тут $roottype == "livecd"
И вообще(если считать, что это все-же касается не livecd), уж лучше тогда “трогать” то же самое, но в /mnt/builder(а в livecd вообще ничего такого трогать не надо)
Из своего опыта скажу - это действие лишь утяжеляет livecd в вопросе потребления памяти (и вообще - глупо если используется опция ядра docache) и негативно сказывается на общем имидже livecd. Это из того что я заметил.
Заключение
При помощи аккуратных костылей Тем или иным образом, но у себя я отключил выполнение вышеописанных действий, не выпиливая эти шаблоны из оверлея (не люблю делать несовместимые решения), на “LiveCD over pxe”(если можно так сказать)
несмотря на то, что lan гораздо медленнее, чем usb-flash или хард, тем не менее, когда ядро САМО начало выбирать что кешировать а что нет - ПРОИЗВОДИТЕЛЬНОСТЬ ПОВЫСИЛАСЬ
PROFIT