ru

Всё же не дружит 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.
Вообщем пока у меня на этом ядре всё нормально.

Всё, таки обновился. Правда модули никак не собираются, но это мелочи (там что-то с wifi, а я его не юзаю).

Причина проблем была следующая: Ускорение сборки системы

Если отмонтировать tmpfs от /var/calculate/tmp/portage, то всё идёт нормально.

В обновлении 2.6.32.5 ошибки поправлены.

Имеет ли смысл устанавливать calculate-sources в режиме build ?

Попробовал поставить на 10.0 режиме build.
Все вроде почти прокатило, но именно почти.
После сообщения "ядро скомпилировано успешно", ну и там еще по поводу возможных параметров ядра, все замирает после строчки об использовании свежей версии genkernel.

После сообщения "ядро скомпилировано успешно", ну и там еще по поводу возможных параметров ядра, все замирает после строчки об использовании свежей версии genkernel.

Аналогично после обновления до нового и не в builder`е, а просто в системе.

А сколько свободного места на разделе, в котором производится сборка?

Если отмонтировать tmpfs от /var/calculate/tmp/portage, то всё идёт нормально.

Будет ли собран пакет, если отмонтировать tmpfs от /var/calculate/tmp/portage?

Устанавливал стандартно 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, дальнейшее обсуждение именно этой проблемы предлагаю вести там. Там же буду выкладвать патчи.

Сергей Клюйков wrote

Причина проблем была следующая: Ускорение сборки системы

А если серьезно, то хотелось бы подробностей, а именно с каккими ключами монтировал, с какой ошибкой вылетело, df -h; df -hi;free в момент вылета.

прирост ощутим когда дело не доходит до свопа(не происходит ненужной записи временной по сути информации на хард) и при работе с мелким файлом. во всяком случае при установке крупных пакетов вроде gentoo-sources если /var/calculate/tmp/portage будет на диске, то только очистка после установки займет порядка полуминуты. а также распаковка сорцов - субьективно быстрее.

Предлагаю в качестве эксперимента запустить

time emerge gentoo-sources

Я что-то не понял суть вопроса...
Я определил, что такая проблема из-за того, что часть данных лежит в оперативке, а часть уходит в своп, за счёт этого появляются ошибки.
Определил это я при помощи научного исключения (метода тыка!), когда просто решил "а почему бы их не отмонтировать?" и всё начало работать.

А в новом ядре будет поддержка v4l?

Да, здесь конфиги:
http://www.calculate-linux.org/projects/calculatelinux/repository/revisions/master/entry/profiles/kernel/

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Гб, теперь слегка дотягивает гиг. Причины неизвестны, но всё равно радует. ;)