Новый calculate-sources

Начиная с ядер 3.7.10 и 3.8 calculate-sources использует новую систему сборки.

Все патчи и настройки ядра перемещены в шаблоны

Что это даёт?

Этот подход чем-то напоминает е-классы, когда поведение ebuild-а может измениться без изменения версии. Это конечно неудобно с точки зрения создания бинарных пакетов обновлений, но сильно облегчает рутинные операции. Мы же планируем извлечь из этого перехода следующие преимущества:

# Обновления ядра будут выходить максимально быстро за счёт того, что ebuild не будет содержать в себе патчей.
# По маске можно будет понять, в какой стадии находится поддержка пакета:

## hard mask будет говорить о том, что у пакета как минимум нет поддержки aufs, т.е. собрать livecd на таком ядре будет невозможно;

## маска по архитектуре будет говорить о том, что ядро при желании можно будет собрать. Оно замаскировано, т.к. не хватает полного набора патчей и оно соответственно ещё не протестировано.

## стабильное состояние говорит о том, что для актуальной версии него есть бинарный пакет обновления, если оно последней версии.
# Патчей будет больше. Будем добавлять то, что будет востребовано. Используя шаблоны вы сможете сами добавлять патчи.
# Настройки ядра также теперь хранятся в шаблонах (см. /var/lib/layman/calculate/profiles/templates/3.1/6_ac_install_patch/sys-kernel/calculate-sources/3.8/config-desktop-i686). Вы можете опять же сделать свои шаблоны с настройками ядра, либо с патчами к настройкам ядра (см. /var/lib/layman/calculate/profiles/templates/3.1/6_ac_install_patch/sys-kernel/calculate-sources/3.8/zzz-config-desktop-bfq-tuxonice.patch).

Для чего всё это надо?

Как сейчас происходит обновление ядер 3.x? Мы ждём патча aufs, затем смотрим на поддержку ati и nvidia и после этого создаём настройки и собираем ядро. Тестируем и выпускаем обновление. Проблема в том, что времени на тестирование отводится недостаточно. За это время многие успевают поставить другое ядро, например pf-sources. Новое ядро - новые сюрпризы, отследить которые можно только на большом количестве железа.

При удалении пакета, полностью удаляется ядро

Тема удаления старых ядер неоднократно поднималась на форуме. После этого мы подняли вопрос об полном удалении ядра при удалении пакета в рассылке и наконец внесли изменение в шаблоны. В этом нам помогло событие вызова шаблонов во время удаления пакета (/var/lib/layman/calculate/profiles/templates/3.1/6_ac_install_unmerge).

Я могу установить новое ядро 3.8.x, удалить старое 3.7.x, какое-то время поработать и затем перезагрузить компьютер. Какие могут быть риски:
# По какой-то причине я не смогу загрузиться на новом ядре.
Такое может произойти, если по невероятной причине поддержка вашего железа вдруг “отвалилась” в новом ядре. Вероятность небольшая.
# Я не смогу корректно отмонтировать какие-то файловые системы, т.к. модулей уже нет.

Поэтому прежде, чем подчистить пакеты без зависимостей командой emerge -ac, если среди обновлений было ядро, сперва перезагрузите компьютер и после этого выполните удаление пакетов с отсутствующими зависимостями.

Вообще calculate-sources по гентушным меркам необычное ядро. Теперь оно вполне подпадает под определение любого другого пакета - ядро устанавливается и удаляется как любой другой пакет.

Заключение

Изменения коснулись не только ядра. Для всех патчей, используемых в Calculate Linux написаны шаблоны (/var/lib/layman/calculate/profiles/templates/3.1/6_ac_install_patch). Один раз изучив шаблоны Calculate, вы можете управлять системой на всех её стадиях работы. Если у вас будут вопросы, пишите на форум Шаблоны.

В связи с этими всеми изменениями, небольшая просьба: проверяйте смонтирован ли корректно boot раздел, так как если ядро установилось просто в /boot, не факт что оно загрузится.

Если Вы не удаляли настройки монтирования раздела из /etc/fstab, проблем не будет.

Вы редактировали /etc/fstab?

Проблема уже возникла, как минимум дважды. В fstab все в норме, по крайней мере mount /boot корректно монтирует загрузочный раздел.
Корневые разделы в обеих системах - reiser3, загрузочные - ext3, загрузочный раздел прописан в fstab с опцией noauto. Если нужны дополнительные данные, готов их предоставить вечером.

Лаг инета, корректированный пост ниже.

Опцию “noauto” Вы прописали в fstab самостоятельно, отсюда и проблемы. Вы же монтируете /boot перед установкой ядра?

Вот я и прошу Вас делать проверку перед установкой ядра, во избежание таких вот сюрпризов.

Круто
спасибо, настройки конфига шаблонами очень не хватало.

… Я не смогу корректно отмонтировать какие-то файловые системы, т.к. модулей уже нет.

Насколько я понимаю - отмонтировать как-раз получится, поскольку если модуль ядра уже в памяти - то и монтировать и отмонтировать можно без проблем.
В связи с этим элегантное предложение - если удаляется ядро с которого выполнена загрузка - проверять, к примеру через /proc/filesystems, доступность файловых систем указанных в fstab, в случае их недоступности - подгружать соответствующие модули.
Если тип файловой системы указан auto - определять его, к примеру, через blkid.

Ну или можно просто подгружать модули всех fs без разбору, к примеру так:
modprobe -av $(find /lib/modules/$(uname -r)/kernel/fs/ -type f | xargs -n1 -iMM basename MM .ko)

Ошибся, смонтировать, конечно.

А может просто вываливать ошибку при обновлении пакета calculate-sources, если директория /boot пуста? )

Непустая /boot еще не значит, что в нее смонтирован корректный загрузочный раздел.

PS
И сразу такой вопрос - какие есть варианты указать системе портежей собирать ядро (и все собираемое через @module-rebuild) из сорцов, а не брать с бинарного сервера, в случае если конфиг ядра изменялся шаблонами?
Есть смутные мысли, по поводу использования /etc/portage/env/ для задания пакетам не обновляемым из бинарей, что-то вроде параметра PORTAGE_BINHOST=/dev/null

Но это сильно автоматизировать надо.

А может просто вываливать ошибку при обновлении пакета calculate-sources, если директория /boot пуста? )

Уж лучше тогда, если есть упоминание о /boot в fstab

И в любом случае - подгрузить модули всех фс не помешает.

а тем временем новое размаскированное ядро calculate-sources-3.7.10 nvidia не поддерживает, что приводит к дополнительным проблемам при обновлении

какая у Вас карта nvidia?

Eldar Abdrazakov писал(а):

а тем временем новое размаскированное ядро calculate-sources-3.7.10 nvidia не поддерживает, что приводит к дополнительным проблемам при обновлении

Если я не ошибаюсь, то новые драйвы от NVIDIA 3хх не поддерживают старые карты - моя GeForce 6150 в том числе. Можно откатиться на старые драйвы или поставить nouveau.

VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT 330M] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Sony Corporation Device 9072
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e2000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at e0000000 (64-bit, prefetchable) [size=32M]
I/O ports at d000 [size=128]
[virtual] Expansion ROM at e3000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 <?>
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting <?>
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Kernel driver in use: nvidia

Уважаемые разработчики, можно ли сделать данную фичу отключаемой, очень неудобно стало поддерживать привычный формат загрузчика: новое ядро по дефолту, проверенное - в резерв. Если раньше было достаточно удалить ненужные ядра и их модули и обновить конфиг grub, то теперь плясок с бубном стало существенно больше.
Пользоваться умолчательным вариантом нет никакого желания, так как если новое ядро по каким-то причинам окажется неработоспособным, то это приведет к куче лишних телодвижений.

В чем суть предложения, я не понял. Устанавливая calculate-sources, ядро прописывается в граб по умолчанию, так было всегда. Чтобы изменить это поведение, добавьте флаги -vmlinuz и -minimal и используйте cl-kernel для сборки ядра.