Чи добре мати кілька версій ядра Linux?


14

Одного разу я встановлював кілька патчів ядра, і щось не вийшло на живому сервері, де було сотні клієнтів. В системі було лише одне ядро. Отже, сервер деякий час не працював, і, використовуючи живий компакт-диск, ми запустили систему та працювали, і ми виконали подальші ремонтні роботи.

Тепер моє запитання: чи гарна ідея мати 2 версії ядра, так що якщо ядро ​​пошкоджене, ми завжди можемо перезавантажуватися з іншим доступним ядром? Будь ласка, дай мені знати.

Також, чи можна мати 2 версії того ж ядра? Так що я можу вибрати інше ядро, коли є пошкодження ядра?

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

Як я можу мати ту саму копію цього ядра, щоб коли моє ядро ​​псувалось, я могла запустити резервне ядро?


4
Мені здається, ви відповіли на власне запитання. Немає жодних недоліків у наявності декількох ядер, якщо ви знаєте, що вони працюють з вашою системою, і це може бути корисно, якщо ви з якихось причин зіткнетеся з проблемами з певним ядром.
Faheem Mitha

Дякую, нехай я не запитав qns правильно. Як я можу мати ту саму копію цього ядра, щоб коли моє ядро ​​пошкодилось, я можу запустити резервне ядро?
Мані

2
Звичайно, ви можете мати однакове ядро. Ядро - це лише файл на диску. Ви можете скопіювати наявне ядро ​​з дещо іншим ім'ям.
Faheem Mitha

На одному з серверів, які я успадкував, було 16 записів для завантаження для 8 різних ядер на ньому ... Знаєте, доки я не прибрав це
канадський Люк

Зазвичай я зберігаю попереднє ядро ​​на випадок, якщо щось піде не так.
Джошуа

Відповіді:


18

І дистрибутив на основі RedHat, і Debian зберігають кілька версій Kernel, коли ви встановлюєте нову, використовуючи 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 | греп "2.6.32-431.el6" | {поки читаю i; \ do cp $ i $ (echo $ i | sed 's / el6 / el6.backup /'); зроблено; } cp /boot/grub/grub.conf cp /boot/grub/grub.conf.backup
Mani

дуже дякую!!! Це спрацювало, і я змінив, як цей ls -1 | греп "2.6.32-431.el6" | {поки читаю i; \ 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. Будь ласка, дайте мені знати, як мати резервне ядро? (бажано тієї ж версії)
Mani

3
Вам нічого не потрібно робити, вони вже є - але в різних версіях. Немає сенсу мати дві однакові версії, якщо ви самостійно не склали одну з них, інакше це просто однакові копії. Питання про "корупцію" є хибним - за цією логікою вам знадобляться дві однакові копії всієї системи у випадку, якщо bashбінарний файл пошкоджений, libcпошкоджений тощо. Все це зробить систему марною. Ці файли не повинні бути "пошкоджені". Якщо вони є, замініть обладнання.
золотинок

1
@goldilocks Або замініть ваш sysadmin, залежно від місця вини.
Філіп Кендалл

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