Alt linux kernel update

Обновление ОС

Как правило, возможно обновление установленного дистрибутива ALT Linux до следующей версии без необходимости переустановки заново.

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

Само обновление производится путём указания требуемых репозиториев в файлах /etc/apt/sources.list.d/*.list , /etc/apt/sources.list и выполнения команд apt-get update && apt-get dist-upgrade

либо эквивалентными действиями в графической утилите synaptic ; после чего следует обновить и ядро командой update-kernel (не реализовано в Synaptic).

Если при попытке сделать apt-get dist-upgrade выводится ругань о неудовлетворённых зависимостях, то следует обновить сначала apt и rpm:

В любом случае рекомендуется перед apt-get dist-upgrade обновлять apt и rpm.

Содержание

В любом случае [ править ]

• не смешивайте репозитории различных версий (и особенно с нестабильным Sisyphus)!
• следует указывать один репозиторий (возможно, содержащий несколько компонент или архитектурных разделов)
  не забудьте проверить содержимое /etc/apt/sources.list.d/*.list , среди них несложно пропустить /etc/apt/sources.list.d/sources.list либо /etc/apt/sources.list.d/cdrom.list Как вариант, посредством apt-repo rm all отключить сразу все, это не удалит записи о репозиториях, а лишь закомментирует. После чего вручную подключить (раскомментировать, удалив # в строках) только нужные.
• для смены источника, начиная с p7, так же удобно использовать утилиту apt-repo .

• наиболее общим репозиторием для каждого дистрибутива, начиная с версии 3.0, является соответствующий бранч
• начиная с ветки 4.0, обязательно подключение не только архитектурно-зависимого (i586 или x86_64), но и межархитектурного (noarch) раздела соответствующего репозитория второй строкой
• если используется ПО со связанной ядерной/пользовательской частью (например, драйвер NVIDIA или VirtualBox) — необходимо также выполнить обновление ядра при помощи update-kernel .
• при существенном количестве кандидатов на удаление лучше отказаться от dist-upgrade, перепроверить конфигурацию репозиториев и посоветоваться в рассылке community@
• в ubuntu и ей подобных дистрибутивах принята другая последовательность команд (apt-get update; apt-get upgrade). В дистрибутивах ALT она в общем случае не работает, т.к. не отслеживает изменение зависимостей. Применение такой последовательности команд ведёт к возникновению неисправимых ошибок в зависимостях.

В пределах версии [ править ]

• обновления можно получать из соответствующего дистрибутиву бранча (например, p8/branch для Альт p8 или p5/branch для Альт Линукс Школьный 5.0)

Между версиями [ править ]

• не следует предпринимать «прыжки» дальше, нежели на соседний бранч!
  например, процедура по возможности безболезненного обновления с Server 4.0 на бранч t6 выглядит как цепочка обновлений между ветками: 4.0=>4.1=>5.0=>5.1=>t6 [1]
• перед попыткой перехода между бранчами следует накатить все доступные обновления из текущего (особенно rpm и apt — apt-get update; apt-get install rpm apt )
• подробности перехода уточняйте на соответствующих страничках для p9, p8 и т.д.

apt-get upgrade [ править ]

Несмотря на то, что команда upgrade существует, использовать её следует осторожно, либо не использовать вовсе (altbug #30867). Цитата из «ALT Linux Master 2.0. Руководство системного администратора»:

Для обновления всех установленных пакетов используется команда apt-get upgrade. Она позволяет обновить те и только те установленные пакеты, для которых в репозитариях, перечисленных в /etc/apt/sources.list, имеются новые версии; при этом из системы не будут удалены никакие другие пакеты. Этот способ полезен при работе со стабильными пакетами приложений, относительно которых известно, что они при смене версии изменяются несущественно.

Иногда, однако, происходит изменение в именовании пакетов или изменение их зависимостей. Такие ситуации не обрабатываются командой apt-get upgrade, в результате чего происходит нарушение целостности системы: появляются неудовлетворенные зависимости. Например, переименование пакета MySQL-shared, содержащего динамически загружаемые библиотеки для работы с СУБД MySQL, в libMySQL, отражая общую тенденцию к наименованию библиотек в дистрибутиве, не приводит к тому, что установка обновленной версии libMySQL требует удаления старой версии MySQL-shared. Для разрешения этой проблемы существует режим обновления в масштабе дистрибутива — apt-get dist-upgrade.

Источник

Kernelnotes

Эта страница была перемещена с freesource.info. Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки. Просьба по окончанию убрать этот шаблон со страницы.

Эта статья протухла. Её нужно существенно доработать или удалить

Использование своего ядра с дистрибутивами ALT Linux не поддерживается как техподдержкой ООО «Альт Линукс», так и силами сообщества. Созданные в багтрекере ошибки, относящиеся к самосборным ядрам, вероятнее всего, будут закрыты как NOTABUG.

Эта страница не описывает, как собирать ядра с kernel.org, но как собирать ядра из репозиториев ALT Linux.

Содержание

Последняя информация о том, как правильно собирать ядро [ править ]

Последняя информация о том, как правильно собирать ядро, находится в пакете kernel-build-tools в файле README.ru.koi8; его посмотреть можно в git-репозитории пакета, например, тут (ссылка со временем устареет): README.ru.koi8

Зачем может быть нужно собирать своё ядро? [ править ]

• Вы разработчик ядра.
• Вам нужно ядро, собранное каким-то особым способом (например, со включенной экспериментальной опцией), и ядра в ALT Linux не собраны таким образом.
• Вы пытаетесь отладить проблему в ядре ALT Linux и в багтракере, списке рассылки или техподдержке вам подсказали, что для этого нужно собрать ядро специальным способом
• У вас есть устройство, не поддерживаемое ядрами ALT Linux (только изредка! Очень часто достаточно просто собрать свой модуль к ядру, см. ниже).

Почему обычно не нужно собирать своё ядро? [ править ]

• Это скучное занятие.
• Если вам нужен специальный драйвер, то достаточно собрать модуль к уже имеющемуся ядру.
• Распространённые мифы про сборку ядра ложны:
  • Сборка ядра — простое дело Современный PC — достаточно сложное устройство, и правильный выбор опций компиляции — нетривиальное занятие. Дистрибутивные ядра оптимизированы под «средний» компьютер, пересборка увеличивает производительность Не подтверждается тестами. Чаще наоборот: неправильно собранное ядро замедляет систему. Сборка ядра — обязательное дело любого линуксоида Нет© Ненужные драйвера тормозят и занимают память Ненужные драйвера лежат на диске в виде модулей и не загружаются в память. Ядро с драйверами, вкомпилированными внутрь, работает быстрее Не подтверждается тестами. Загрузка модулей занимает несколько секунд при старте компьютера, дальнейшее использование идентично по скорости вкомпилированным драйверам. (а для тех применений, где отсутствие лишнего просмотра таблицы действительно существенно — всяко требуется специалист, не судящий по глупым сказкам)

Предупреждение [ править ]

Статья частично протухла. vsu@ советует читать доки в kernel-build-tools .

Собираем новое ядро [ править ]

Будем для примера собирать ядро версии 2.6.23. Вам понадобится хорошая быстрая машина, с быстрым процессором, и большим объемом ОЗУ [1] . Для ускорения сборки можно использовать ccache, установив для этого переменные:

Подготовительный этап [ править ]

I [ править ]

У ALT Linux разработана своя среда (kernel-build-tools) для сборки ядер. Основным мантейнером этой среды является vsu; по состоянию на декабрь 2009 последние правки публиковал aspsk:

Как видно, среда состоит из набора скриптов.

II [ править ]

Репозиторий c ядром должен находиться в директории kernel.

Забираем ядро, например, у vsu или lakostis:

Добавляем репозиторий, содержащий новую версию ядра (для git-remote может потребоваться поставить пакет perl-GIT):

В master ветку этого репозитория Линус помещает обновления для ядер серии 2.6.23 (например 2.6.23.1, 2.6.23.2…). В нашем репозитории будет создана ветка linux-2.6.23/master, которая будет отслеживать обновления для ванильного ядра 2.6.23.

Загрузим с репозитория linux-2.6.23 исходный код ядра.

Теперь в нашем репозитории ветка linux-2.6.23/master содержит ядро 2.6.23 с обновлениями. Убедимся:

Собрираем пакет kernel-source-2.6.23-1.0.0-alt1.noarch.rpm [ править ]

Как видно, данный пакет не зависит от архитектуры. Внутри пакета содержиться только файл с иходными кодами ванильного ядра: /usr/src/kernel/sources/kernel-source-2.6.23.tar.bz2

Заметьте, что данный пакет содержит исходный код ядра версии 2.6.23, а не 2.6.23.1. Собрать этот пакет не составит труда. Достаточно:

В ответ на ругань add_changelog что версия пакета не изменилась, можно добавить к alt1 точку: ‘alt1.’, потом удалить. Версия пакета не изменяется, а изменяется имя пакета.

Осталось собрать сам пакет с помощью gear в hasher:

на результат не влияют, там BuildRequires(pre) не хватает. После сборки этот пакет будет находится в репозитории hasher-a.

Собираем пакет kernel-image-std-smp-2.6.23-alt1.i586.rpm [ править ]

Собственно этот пакет содержит само ядро + стандартные модули поставляемые с ядром.

Несколько слов о структуре репозитория. На мой взгляд следует различать ветки:

• kernel-source — цель этой ветки создать пакет с исходниками ванильного ядра 2.6.23 (мы использовали эту ветку на предыдущем шаге).
• начинающиеся с feat-*-* fix-*-* . Каждая такая ветка содержит ванильное ядро + какое-то одно исправление, дополнение, патч.

Имя ветки сообщает, какое конкретное дополнение она несет.

• fix-stable — содержит ванильное ядро с последними исправлениями 2.6.23.1.
• kernel-image-std-smp — содержит пропатчиное ядро. эту ветку мержутся ветки fix-stable, feat-*-*, fix-*-*, fix-stable

Цель ветки kernel-image-std-smp создать мега патч-бомбу который накладывается на ванильное ядро 2.6.23, скомпилировать бинарное ядро, собрать пакет.

Файл branches-to-merge используется скриптом merge-all-branches. Может возникнуть вопрос: «Зачем мержить ветки которые указаны в branches-to-merge, если они уже в замерженыы в ветку kernel-image-std-smp ?» Ответ: Периодически в этих ветках появляется что-то новое, вот скрипт и проверяет, что появилось. Ещё возможен вариант вида branch-* скрипт merge-all-branches проверяет, есть ли что-то новое, если нет — ничего не делает, если есть — спрашивает, надо ли это мержить.

В моем случае, накатывать 2.6.23 поверх пропатченого 2.6.18, бесмысленно, иначе там всё развалится. Придётся делать по сути rebase всех веток с патчами, и подцеплять к старой истории в самом конце. При сборке 2.6.23 лучше создать новые ветки fix-stable, kernel-image-std-smp, …

A [ править ]

Cоздадим ветку fix-stable. Задача этой ветки содержать последние официальные исправления для ядра от Linus Torvalds:

При будущих обновлениях можно поступать одним из следующим способов: 1. Из tracking branch:

2. Загрузить обновления непосредственно из репозитория Linus-а:

B [ править ]

Создадим ветку kernel-image-std-smp на основе тега v2.6.23. Задача этой ветки содержать код ядра со всеми приложеными патчами. То есть в эту ветку мержатся остальные ветки feat-*-* fix-*-*.

Заберем из старой ветки vsu/kernel-image-std-smp файлы: kernel-image.spec config-i586 config-x86_64 branches-to-merge .gear/rules modules.build

Для каждого вышеперечисленного файла выполним:

флаг -f указывает добавить .gear/rules, даже если он занесен в .gitignore

C [ править ]

Создадим ветки feat-*-* и fix-*-*. Например создадим ветку добавляющую поддержку файловой системы unioinfs.

Патч можно наложить в ручную (patch -p1 feat-core- -rt feat-core-bootsplash feat-evms feat-evms-nodm feat-fs-squashfs feat-fs-unionfs fix-core- -init fix-core- -syslog fix-stable kernel-image-std-smp kernel-source master

D [ править ]

Мержим все исправления в ветку kernel-image-std-smp, исправляем конфликты.

E [ править ]

В ветке kernel-image-std-smp, создадим новый конфиг на базе старого:

При обработке make oldconfig, следует учитывать тот факт, что при наличии возможности скомпилировать некую часть ядра в виде модуля, следует ее выбрать. Чаще всего модули не компилируются непосредственно в ядро, но бывают исключения.

Проверяем все ли впорядке:

Опцию CONFIG_LOCALVERSION_AUTO следует отключить.

F [ править ]

Сборка дополнительных модулей [ править ]

A [ править ]

Каждый пакет, несущий дополнительный модуль собирается на основе шаблона. Шаблоны для всех дополнительных модулей раньше можно было загрузить с CVS:

Теперь шаблоны для модулей находятся в репозиториях kernel-modules у мантейнеров.

B [ править ]

Например, при сборке пакета kernel-modules-nvidia-std-smp-100.14.19-alt3.132631.1.i586.rpm будет использован шаблон modules/nvidia/kernel-modules-nvidia.spec и пакет kernel-source-nvidia-1001419-100.14.19-alt39.i586.rpm.

Пакет kernel-source-nvidia-1001419-100.14.19-alt39.i586.rpm берем из Sisyphus.

Пакеты kernel-source-* собираются как обычно. У кого-то лежит в гите, у кого-то старым дедовским способом. Получается что мантейниры модулей предлагают только kernel-source-%modulename, а сам бинарный модуль собирает vsu. Пакеты с бинарными модулями нужно собирать с каждым обновлением ядра. Если kernel-source-modulename плохо собран, тогда vsu выполняет двойную работу, либо забивает на этот модуль.

Undeground [ править ]

то есть, rpm-build-kernel — для BuildRequires, kernel-build-tools — скрипты для использования мантейнерами

pull . сейчас можно менять на merge что лучше cherry-pick или pull ? это в древних версиях git merge не предназначался для вызова руками зависит от ситуации… если в ветке куча коммитов, которые в свежей версии уже есть, merge с большой вероятностью не пройдёт автоматически если это патчи, которые не вошли в новую версию, вероятно, лучше сделать merge а я сделал cherry 🙁 кстати, в подобном случае может иметь смысл сначала сделать merge новой версии в эту ветку хотя это зависит от того, что в дальнейшем предполагается делать с этими изменениями если нужно получить патчи для свежего апстрима, придётся делать rebase если это какие-то изменения, которые апстриму нафиг не нужны, может быть проще смержить свежую версию апстрима туда и разгрести конфликты кстати, в самом свежем git сделали поддержку revert и cherry-pick для merge… указывается, с каким родителем делать дифф, который потом откатывается или применяется A->B ы :(то есть cherry-pick может забирвать все коммиты, между A и B ? нет… это git rebase умеет только он портит исходный бранч а в чем тогда новая фишка ? cherry-pick и revert — это почти одно и то же, различаются тем, в какую сторону применяется патч патч генерируется между указанным коммитом и его родителем если это merge, нужно указать, какой из родительских коммитов нужно брать вот эту опцию и добавили то есть, если сделать cherry-pick для merge, получится один мегапатч со всеми изменениями вообще это полезно для revert

Источник