Очень многие пользователи и системные администраторы используют дистрибутивы Fedora/RHEL/Suse/Mandriva с ядром собственной сборки и поэтому обновление или установка ядра от вендора не является желанным.Избежать установки ядер при обновлении можно следующим образом. Создайте файл kernel.spec, определяющий пакет с заведомо более новой фиктивной версией ядра, (данный вариант на 100% работает только на Fedora/RHEL) со следующим содержимым:
Name: kernel
Summary: The Linux kernel
Version: 2.6.100
Release: 1
License: GPLv2+
Group: System Environment/Kernel
URL: http://www.kernel.org/
Packager: Artem S. Tashkinov%description
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system. The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
input and output, etc.%prep
%build
%install
%clean
%files
%changelog
* Thu Jul 8 2010 Artem S. Tashkinov <birdie@permonline.ru> 2.6.100
- First indefinite release (unless kernel developers
change kernel versioning)Затем соберите и установите его с помощью следующих команд:
$ rpm -ba kernel.spec
$ rpm -ivh ~/rpmbuild/RPMS/`rpm --eval '%_target_cpu'`/kernel-2.6.100-1.i686.rpm
URL:
Обсуждается: http://www.opennet.me/tips/info/2407.shtml
мда :((((((
echo "exclude=kernel*" >> /etc/yum.conf
ну так то да, но костыль прикольный :)
>мда :((((((
>echo "exclude=kernel*" >> /etc/yum.confОткуда в openSUSE и Mandriva yum ?
С вашими методами - только в застенках майкрософта работать...
Полез посмотреть только для того что бы посмотреть, мало ли чего не знаю. А тут такое. Вот если бы даже задача у меня такая стояла, в голову бы не пришло такое решение.
Автору за нестандартное мышление респект.
Выполнять только гуру админам, новичкам идти читать доки.
автору дизреспект за то что не читает документацию по пакетным менеджерам
OMFG
в yum,apt есть опции исключения пакетов.С suse никогда не работал, но подозреваю, что в zypper (или что там у них? ) тоже есть.
Отвечаю всем, почему exclude нельзя пользоваться: от ядра зависят ещё достаточно много пакетов, которые перестанут обновляться, если вы не будете включать ядро в обновление (это как минимум fuse и libdrm.). А если не использовать некоторые опции yum'a (подсказка --skip-broken), то командаyum update --exclude='kernel*'
вообще не будет работать, и ваша система перестанет автоматически обновляться.
Так что прежде чем критиковать, подумайте сначала головой.
>Отвечаю всем, почему exclude нельзя пользоваться: от ядра зависят ещё достаточно много пакетов, которые перестанут обновляться, если вы не будете включать ядро в обновлениеПри невозможности обновлять ядро их точно нельзя обновлять тоже.
>(это как минимум fuse и libdrm.).
Странно, а мне (CentOS 5.5) yum говорит что для fuse надо kernel >= 2.6.14, а libdrm вообще не зависит от ядра.
> и ваша система перестанет автоматически обновляться.
Кому-то нечего делать и он обновляет систему автоматически без контроля?
>Так что прежде чем критиковать, подумайте сначала головой.
Прежде чем писать, почитайте документацию. И последуйте своему же совету.
Спасибо за совет - уже воспользовался. Критиков не слушайте - задача решена по уму, и более правильного решения с ходу и не придумаешь.
>Спасибо за совет - уже воспользовался. Критиков не слушайте - задача решена
>по уму, и более правильного решения с ходу и не придумаешь.
>Более _неправильного_ хотели сказать? Если бы я ?додумался? до такого решения, меня начальство заставило бы съесть мой сертификат RHCT (да-да, даже не RHCE, и то знаю что так делать нельзя) вместе с рамкой и стеклом, в которой он висит. И в сухомятку.
>>Спасибо за совет - уже воспользовался. Критиков не слушайте - задача решена
>>по уму, и более правильного решения с ходу и не придумаешь.
>>
>
>Более _неправильного_ хотели сказать? Если бы я ?додумался? до такого решения, меня
>начальство заставило бы съесть мой сертификат RHCT (да-да, даже не RHCE,
>и то знаю что так делать нельзя) вместе с рамкой и
>стеклом, в которой он висит. И в сухомятку.Вы по существу можете сказать чем оно неправильно или только на уровне "у меня невзъ**ный сертификат - я буду им как своим толстым и длинным махать" и говорить, что я один прав?
Тем, что для таких вещей имеются управлялки репозиториями. И раз уж собираем свои пакеты, так что мешает сделать для них свой репозиторий, которому указать приоритет выше чем у стандартного? И то, если боимся что у нас чего-то ?поплывёт?.
Ну а сертификат RCHT - это минимум из существующего и ни разу не круто.
Если Вы заметили, тут высказали бредовость этой идеи задолго до меня.
>>Спасибо за совет - уже воспользовался. Критиков не слушайте - задача решена
>>по уму, и более правильного решения с ходу и не придумаешь.
>>
>
>Более _неправильного_ хотели сказать? Если бы я ?додумался? до такого решения, меня
>начальство заставило бы съесть мой сертификат RHCT (да-да, даже не RHCE,
>и то знаю что так делать нельзя) вместе с рамкой и
>стеклом, в которой он висит. И в сухомятку.Ваше замечание очень правильное. Не на вступать в полемику с ?красноглазыми?. Навидался я таких... Поправят в скриптах, а потом ищи - где это он поставил заглушку и файлы, где должны быть настройки - идут лесом.
Грамотный админ не тот, кто может исправить скрипт, а тот, кто может понять разработчика и настроить систему средствами, которые предоставляет разработчик. Это нужно для того, чтобы документация к системе соответствовала системе.
P.S. Упаси вас бог пить пиво в бутылках с поддельной этикеткой.
а вот как это делается в openSUSE:
zypper al kernel-*
Как здорово пользоваться ubuntu - там ядро само не обновляется.
>Как здорово пользоваться ubuntu - там ядро само не обновляется.Смотря как его ставить.
криво, но удобно(имхо).Я так патченные, и пересобранные пакеты иногда называю, что бы не потерлись при апдейте, когда по какой-то причине приоритеты репозиториев неудобны.
Минус решения в том, что о _существовании_ security фиксов Вы так и не узнаете.
Имхо, контроллируемые централизованные апдейты через тот же Spacewalk все-таки лучше...
Таки автор заметки очень чётко написал, что некоторые ядра устанавливают сразу после появления на kernel.org, поэтому, скорее, пользователи дистрибутивов в опасности, нежели те, кто действительно следит за своей системой, пусть даже слегка извращаясь с пакетным менеджером.Кстати, вы много пользователей знаете, которые читают bug tracker'ы или обращают внимание на security update'ы? Я практически никого - и да у меня много знакомых "сисадминов".
>Таки автор заметки очень чётко написал, что некоторые ядра устанавливают сразу после
>появления на kernel.orgАвтор писал про самосборные ядра, а не ?сразу после появления на kernel.org?. Если Вы не в курсе, то в дистрибутиве идут ещё и исходники, из которых ядро можно под свои нужды перебрать.
>Кстати, вы много пользователей знаете, которые читают bug tracker'ы или обращают внимание
>на security update'ы? Я практически никого - и да у меня
>много знакомых "сисадминов".Пользователей или админов?
>Кстати, вы много пользователей знаете, которые читают bug tracker'ы или обращают внимание
>на security update'ы? Я практически никого - и да у меня
>много знакомых "сисадминов".Я стараюсь регулярно просматривать в RSS и читаю центосную рассылку, но, конечно, иногда могу что-то пропустить. Большинство знакомых админов этим не занимаются (но не все)
Интересно, кто-нибудь придумал, как автоматизировать этот вопрос?
у меня в генте используется сей скрипт, который на почту посылает инфу о новых пакетах и инфу о glsa. думаю и для rhel/sles/etc сделать не проблема.#!/bin/bash
LIST="/tmp/list"
MAILTO="tra-lya-lya@uau.ru"
rm $LIST
emerge --sync
/usr/bin/update-eix
echo "Subject: `hostname` emerge notification" >> $LIST
echo -e "\n `date -R`" >> $LIST
echo '######## emerge -uDN world information ########' >> $LIST
/usr/bin/emerge -pvuDN world |awk -F ] '{print $2}' |awk -F [ '{print $1}' |awk '{print $1}' |uniq >> $LIST
echo '######## GLSA-CHECK information ########' >> $LIST
/usr/bin/glsa-check -l affected >> $LIST
cat $LIST | /usr/sbin/ssmtp $MAILTO
без обид, но не дай Бог кому достанется "сервер" на gentoo в наследство от старого админа и есесно без документации(как у нас обычно принято).
Совсем забыл спросить: это у меня одного yum ни в одной инсталяции не трогает текущее используемое ядро и оставляет его альтернативным вариантом при загрузке, или просто у меня ?кривые руки? и я забыл ему испортить чего-то?
man yum.conf
Вот я и рекомендую кое-кому (читай автору вредного совета) почитать этот самый man, дабы не страдать подобной ерундой. В дефолтной инсталяции RHEL/CentOS/UBL оно сохраняет используемое ядро в качестве альтернативы при загрузке. Если что-то зависит от ядра так, что обязательно обновляется вместе с ним, то и подобный костыль не поможет.
Это RPM делает. Особенности обновления ядра в RHEL.
В SuSE новое ядро ставится в загрузку по-умолчанию при апдейте.
Как!!! У Вас ядро не на отдельном разделе? И вы его монтируете?? Да и еще в режиме RW??? Ай-яй-яй!!!# cat /proc/mounts | grep boot
/dev/sda1 /boot xfs noauto,ro,defaults 0 0Нипёт, пущай ставит...
----------
> Очень многие пользователи и системные администраторы
> используют дистрибутивы Fedora/RHEL/Suse/Mandriva с ядром собственной сборкиИ воооообще, нафига оставлять пакеты с ядром дистрибутива???
Пользуясь случаем, хочу спросить, зачем заменять дистрибутивное ядро своим, не считая наложения сторонних патчей?
>Пользуясь случаем, хочу спросить, зачем заменять дистрибутивное ядро своим, не считая наложения сторонних патчей?Новая версия == установка "несторонних" патчей~~ :)
Как и с любым софтом -- новая версия = "+ новые фичи".
Я вот "балуюсь" ядром с backports.org (Debian) - и ядро "от Линуса" новее, и дистрибутивные" патчи уже включены.ЗЫЖ Да, знаю, как обычно "+ новые фичи" -> возможны "+ новые мис-фичи"~~
>>Пользуясь случаем, хочу спросить, зачем заменять дистрибутивное ядро своим, не считая наложения сторонних патчей?
>
>Новая версия == установка "несторонних" патчей~~ :)
>Как и с любым софтом -- новая версия = "+ новые фичи".
>
>Я вот "балуюсь" ядром с backports.org (Debian) - и ядро "от Линуса"
>новее, и дистрибутивные" патчи уже включены.
>
>ЗЫЖ Да, знаю, как обычно "+ новые фичи" -> возможны "+ новые мис-фичи"~~Спасибо за ответ. Но интересует следующее: разве при обновлении дистрибутивных пакетов ядра (конкретно CentOS 5.5) не появляются возможности самых свежих ядер? Ведь разработчики RHEL постоянно бэкпортируют в 2.6.18 ядро код?
>(конкретно CentOS 5.5) не появляются возможности самых свежих ядер? Ведь разработчики
>RHEL постоянно бэкпортируют в 2.6.18 ядро код?Насколько я ничего не знаю об RHEL-ах/CentOS-ах, бэкпортируют они в основном фиксы и драйверы [новых] железок. "Инфраструктурные" фичи в стабильном пакете ядра д.б. ...стабилизированы, наверное.
Может, кто из аборигенов RHEL/CentOS подтвердит, опровергнет или дополнит мои измышления?
а вообще очень интересно как народ решает проблему отката до старых версий, если обновление прошло не удачно?
>а вообще очень интересно как народ решает проблему отката до старых версий, если
> обновление прошло не удачно?Диву даюсь. Народ читает доки и маны. Ядра не обновляются, а устанавливаются. Старое ядро так и будет висеть, пока его ручками не удалишь.
Fedora 13 в /boot/grub/grub.conf увеличивает default на 1, чтобы всенепременно загрузится со старого ядра. Чтобы загрузится с нового, нужно: либо править grub.conf либо загрузится ручками с нового и удалить старое.
Это справедливо, для всех дистров, ИМХО.
Я думал, что этого хватит на десятилетия, нет, уже пришлось пересобрать, но теперь я сделал версию 100, что хватит на всю мою жизнь.