Хорошо ли иметь несколько версий ядра Linux?


14

Однажды я установил некоторые исправления ядра, и что-то пошло не так на живом сервере, где у нас были сотни клиентов. В системе было только одно ядро. Итак, сервер некоторое время не работал, и, используя live CD, мы запустили систему и выполнили дальнейшие ремонтные работы.

Теперь мой вопрос: хорошо ли иметь две версии ядра, чтобы в случае повреждения ядра мы всегда могли перезагрузиться с другим доступным ядром? Пожалуйста, дайте мне знать.

Кроме того, возможно ли иметь 2 версии одного и того же ядра? Так что я могу выбрать другое ядро, когда происходит повреждение ядра?

Edited:
My Server Details:
2.6.32-431.el6.x86_64
CentOS release 6.5 (Final)

Как я могу иметь одну и ту же копию этого ядра, чтобы при повреждении моего ядра я мог запустить резервное ядро?


4
Мне кажется, что вы ответили на свой вопрос. Нет недостатка в наличии нескольких ядер, если вы знаете, что они работают с вашей системой, и иногда это может быть полезно, если по какой-то причине у вас возникнут проблемы с конкретным ядром.
Фахим Митха

Спасибо, может быть, я не правильно спросил qns. Как я могу иметь такую ​​же копию этого ядра, чтобы при повреждении моего ядра я мог запустить резервное ядро?
Мани

2
Конечно, вы можете иметь идентичное ядро. Ядро - это просто файл на диске. Вы можете скопировать существующее ядро ​​с немного другим именем.
Фахим Мита

На одном из серверов, которые я унаследовал, на нем было 16 загрузочных записей для 8 различных ядер ... Вы знаете, пока я не очистил его
Канадский Лука

Я обычно держу предыдущее ядро ​​на случай, если что-то пойдет не так.
Иисус Навин

Ответы:


18

Как RedHat, так и дистрибутив на основе Debian сохраняют несколько версий ядра при установке новой версии с использованием yumили apt-getпо умолчанию. Это считается хорошей практикой и делается именно для описанного вами случая: если что-то идет не так с последним ядром, вы всегда можете перезагрузиться и в GRUB выбрать загрузку с использованием одного из предыдущих ядер.

В дистрибутивах RedHat вы управляете количеством ядер, которое следует сохранить /etc/yum.confпри installonly_limitнастройке. На моей новой установке CentOS 7 по умолчанию установлено значение 5.

Кроме того, если в RedHat вы устанавливаете новое ядро ​​из пакета RPM, которое вы должны использовать rpm -ivh, то нет rpm -Uvh: первое сохранит старое ядро ​​на месте, а позднее его заменит.

Debian сохраняет старые ядра, но не удаляет их автоматически. Если вам нужно освободить загрузочный раздел, вы должны удалить старые ядра вручную (не забудьте оставить хотя бы одно из предыдущих ядер). Для получения списка всех пакетов для установки ядра и заголовков ядра используйте dpkg -l | egrep "linux-(im|he)".

Отвечая на ваш вопрос - Кроме того, возможно ли иметь 2 версии одного и того же ядра? -- Да, это возможно. Я не могу проверить это на CentOS 6.5 прямо сейчас, но на CentOS 7 я смог получить желаемый результат, просто дублируя связанные с ядром файлы /bootкаталога и перестраивая меню grub:

cd /boot

# Duplicate kernel files; 
# "3.10.0-123.el7" is a substring in the name of the current kernel
ls -1 | grep "3.10.0-123.el7" | { while read i; \
    do cp $i $(echo $i | sed 's/el7/el7.backup/'); done; }

# Backup the grub configuration, just in case
cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.backup

# Rebuild grub configuration
grub2-mkconfig -o /boot/grub2/grub.cfg

# At this point you can reboot and see that a new kernel is available 
# for you to choose in GRUB menu

спасибо, я работаю над этим. Но в CentOS 6.5 нет "grub2-mkconfig". Знаете ли вы, как это сделать в Centos 6.5, я думаю, что grub2 доступен только в Centos 7. Я сейчас гуглю, если найду soln, обновлю здесь.
Мани

Я изменил эти строки в соответствии с Centos 6.5, как показано ниже, и застрял с тем, как обновить grub.conf. лс -1 | grep "2.6.32-431.el6" | {пока читаю я; \ do cp $ i $ (echo $ i | sed 's / el6 / el6.backup /'); сделано; } cp /boot/grub/grub.conf cp /boot/grub/grub.conf.backup
Мани

большое спасибо!!! Это сработало, и я изменил вот так ls -1 | grep "2.6.32-431.el6" | {пока читаю я; \ do cp $ i $ (echo $ i | sed 's / el6 / el6.backup /'); сделано; } cp /boot/grub/grub.conf cp /boot/grub/grub.conf.backup, и я отредактировал grup.conf вручную. Вы можете оставить UUID таким же, если вы собираетесь копировать на тот же диск и раздел.
Мани

7

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

На рабочем сервере это обычно не проблема, но всякий раз, когда вы обновляете ядро, рекомендуется иметь резервную копию. Некоторые дистрибутивы Linux предлагают откат (обычно поддерживаемый возможностями моментальных снимков файловой системы) обновлений пакетов, чтобы сделать процесс как можно более безболезненным, но даже в этих случаях я бы хотел сохранить резервную копию готовой.

Что касается нескольких копий одного и того же ядра - даже это имело бы смысл, но, как указывает @goldilocks в комментарии ниже, если ваше ядро ​​повреждено, вам следует подумать о замене аппаратного обеспечения. С другой стороны, размещение дубликата на другом физическом жестком диске может избавить вас от некоторых проблем. Но имейте в виду, что файл образа ядра только когда - либо использовали во время загрузки.


Я изменил qns, пожалуйста, дайте мне знать, как сделать резервную копию ядра? (желательно та же версия)
Мани

3
Вам не нужно ничего делать, они уже есть - но в разных версиях. Нет смысла иметь две одинаковые версии, если вы сами не скомпилировали одну из них, в противном случае это просто идентичные копии. Проблема «порчи» является своего рода фальшивой - по этой логике вам понадобятся две идентичные копии всей системы на случай, если bashбинарный файл был поврежден, libcповрежден и т. Д., И все это сделает систему бесполезной. Эти файлы не должны быть «повреждены». Если они есть, замените ваше оборудование.
Златовласка

1
@goldilocks Или замените своего системного администратора, в зависимости от того, где была ошибка.
Филипп Кендалл

@goldilocks см. обновленный ответ - это может иметь смысл в определенных случаях. Очевидно, что замена неисправного оборудования должна быть предпочтительнее, когда это возможно.
Петер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.