История calculate-sources началась, когда Calculate Linux стал распространяться на LiveCD. Понадобились патчи, отсутствующие в gentoo-sources. Поддержка calculate-sources велась с версии 2.6.27 по 2.6.30. Внедрение /etc/portage/bashrc позволило накладывать патчи на устанавливаемые пакеты, из-за чего мы смогли отказаться от поддержки в оверлее нескольких ebuild`ов и вернуться на gentoo-sources.
Особенности нового ядра
Необходимость в возрождении ядра была вызвана рядом причин, среди которых сложности при обновлении ядра (из за модульной структуры) и отсутствие возможности сборки бинарного пакета.
Особенности calculate-sources
поддержка файловой системы aufs2, а также fbcondecor, alpha-sysctl-uac, dm-bbr;
компиляция ядра при установке пакета;
формирование initrd файла;
прописывание ядра в автозагрузку;
поддержка опции --buildpkg (b) создание бинарного пакета
Установка
В настоящее время пакет проходит тестирование. Тем не менее вы можете его установить и поделиться своими впечатлениями. В настройках ядра были решены все описанные пользователями проблемы.
При установки модули ядра будут перемещены в директорию /lib/modules/2.6.32-calculate. Это позволит в дальнейшем пропускать команду module-rebuild при обновлении ядер 2.6.32.
Хочется узнать ваше мнение и отзывы перед подготовкой обновления Calculate Linux 10.0.1.
Всё же не дружит genkernel с reiser… В общем, после компиляции ядра пошли такие сообщения и всё встало колом:
rm: cannot remove directory `/var/calculate/tmp/portage/sys-kernel/calculate-sources-2.6.32.4/work/linux-2.6.32.4-calculate/temp/13435.8503.22616.4672/initramfs-temp/.initrd': Нет такого файла или каталога
rm: cannot remove directory `/var/calculate/tmp/portage/sys-kernel/calculate-sources-2.6.32.4/work/linux-2.6.32.4-calculate/temp/13435.8503.22616.4672/fuse-2.7.4/example/.deps': Нет такого файла или каталога
rm: cannot remove directory `/var/calculate/tmp/portage/sys-kernel/calculate-sources-2.6.32.4/work/linux-2.6.32.4-calculate/temp/13435.8503.22616.4672/fuse-2.7.4/util/.libs': Нет такого файла или каталога
rm: cannot remove directory `/var/calculate/tmp/portage/sys-kernel/calculate-sources-2.6.32.4/work/linux-2.6.32.4-calculate/temp/13435.8503.22616.4672/fuse-2.7.4/util/.deps': Нет такого файла или каталога
3 часа ждал с моря погоды, нифига. При этом там эти директории там есть… Вобщем не знаю даже в чём проблема.
Странно.А у меня сразу всё встало нормально.
Файловая система reiserfs.Причём в процессе он (genkernel) поругался на то,что нет поддержки reiser4 и лучше переходить на ext3 или reiser3.
Вообщем пока у меня на этом ядре всё нормально.
Имеет ли смысл устанавливать calculate-sources в режиме build ?
Попробовал поставить на 10.0 режиме build.
Все вроде почти прокатило, но именно почти.
После сообщения “ядро скомпилировано успешно”, ну и там еще по поводу возможных параметров ядра, все замирает после строчки об использовании свежей версии genkernel.
После сообщения “ядро скомпилировано успешно”, ну и там еще по поводу возможных параметров ядра, все замирает после строчки об использовании свежей версии genkernel.
Аналогично после обновления до нового и не в builder`е, а просто в системе.
Устанавливал стандартно 10 в режиме build на раздел в 10G
Сразу же запускал
cl-builder
layman -S
eix-sync
emerge calculate
cl-unmask calculate-sources
emerge calculate-sources
и далее то, что описано выше.
tmpfs не трогал.
Будет ли собран пакет, если отмонтировать tmpfs от /var/calculate/tmp/portage?
ДА!
Возможно это из-за того, что часть информации попадает в своп а часть остаётся в ОЗУ. Оттуда и “копыта” растут.
Пробовал собирать на аппарате с 4Гб ОЗУ, так всё собралось без проблем, правда не на много быстрее… Не знаю, я практически не ощущаю прироста производительности компиляции монтируя папку в tmpfs.
Попробовал то же на разделе в 15G, но уже через cld-meta
Увы, результат тот же. Замирает после того же сообщения от genkernel.
В не билд режиме не пробовал, потому как решил вопрос памяти в нем с помощью
cl-kernel --menuconfig
Хотелось слепить дистрибутив с “нормальным” ядром.
Баг с подвисание сборки ядра через ebuild: http://www.calculate-linux.org/issues/103, дальнейшее обсуждение именно этой проблемы предлагаю вести там. Там же буду выкладвать патчи.
Причина проблем была следующая: Ускорение сборки системы
принимаю эти слова как вызов, подбираю знамя на поле брани и вперед… (шутка)
А если серьезно, то хотелось бы подробностей, а именно с каккими ключами монтировал, с какой ошибкой вылетело, df -h; df -hi;free в момент вылета.
прирост ощутим когда дело не доходит до свопа(не происходит ненужной записи временной по сути информации на хард) и при работе с мелким файлом. во всяком случае при установке крупных пакетов вроде gentoo-sources если /var/calculate/tmp/portage будет на диске, то только очистка после установки займет порядка полуминуты. а также распаковка сорцов - субьективно быстрее.
Я что-то не понял суть вопроса…
Я определил, что такая проблема из-за того, что часть данных лежит в оперативке, а часть уходит в своп, за счёт этого появляются ошибки.
Определил это я при помощи научного исключения (метода тыка!), когда просто решил “а почему бы их не отмонтировать?” и всё начало работать.
2 Сергей Клюйков вообще такой проблемы быть недолжно в принципе.
Ибо нет разницы уходит ли tmpfs в своп или нет, по сути tmpfs тем и отличается от ramfs что второй работает ЛИШЬ в памяти, а tmpfs делали с расчетом что работать будет В ВИРТУАЛЬНОЙ памяти, а значит если ведет себя неодинаково в памяти и в свопе - значит это СЕРЬЕЗНЕЙШАЯ БАГА.
Михаил, это уже не ко мне. Сколько я не пробовал компилить ядро с Вашей системой, всё заканчивается этим: как только своп начинает использоваться, можно смело говорить о том, что компиляция не закончится. Проверял раз 10 минимум. С ядром 2.6.34.7 ещё не пробовал, но только что поставил на компиляцию. Результат скажу через 2-4 часа… испытуемый: Cel 2.4GHz,1Gb RAM, 2.5Gb Swap. используется технология ускорения сборки системы.
Как и обещал я проверил все ядра… Начиная с версии 2.6.34.5 установка проходит нормально (использовался cl-kernel). При этом более старшие версии устанавливаются только если /var/calculate/tmp/portage НЕ смонтирован в tmpfs. Кстати, последнее ядро ест ОЗУ значительно меньше: раньше вместе с системой кушало около 1.3Гб, теперь слегка дотягивает гиг. Причины неизвестны, но всё равно радует.
испытуемый: Cel 2.4GHz,1Gb RAM, 2.5Gb Swap. используется технология ускорения сборки системы.