Обновили ядро и не поднялась сеть: план восстановления

MAATRIX

Плановое обновление ядра — рутинная операция в любом графике обслуживания, но иногда после reboot сервер физически включается (пингуется на уровне хостера, крутится вентилятор, горит индикатор), а по сети не отвечает вообще: ни ping, ни ssh, мониторинг молчит. Первая реакция — паника и звонок в техподдержку, но в большинстве случаев причина понятна и чинится за 10-15 минут через консоль хостера (KVM, IPMI, serial console или её веб-аналог), если знать, куда смотреть. Дальше — план: что проверить в первую минуту, какие три причины типичны именно после смены ядра, как диагностировать через консоль и как быстро вернуть доступ, пока разбираетесь с деталями.

Первым делом — консоль хостера и uname -r

Сеть недоступна — значит, единственный путь внутрь сервера сейчас это консоль хостера. У большинства провайдеров это либо веб-KVM (виртуальный монитор + клавиатура прямо в браузере панели управления), либо IPMI/iDRAC/iLO для выделенных серверов, либо serial console на VPS. Открывайте её сразу, не тратя время на попытки достучаться по SSH ещё раз — если сеть не поднялась, десятый ssh не поднимет её сам.

Первое, что нужно сделать в консоли — залогиниться и проверить, какое ядро реально загрузилось:

uname -r

Сравните вывод с тем, что вы ставили. Тут возможны три сценария:

• Загрузилось новое ядро (то, что вы и обновляли) — значит, GRUB отработал штатно, и проблема действительно в сети на новом ядре. Идём дальше по этой статье.
• Загрузилось старое ядро — GRUB откатился сам (например, через fallback в systemd-boot или из-за таймаута), и тогда странно, что сети нет: возможно, дело не в ядре вовсе, а в самой перезагрузке (конфиг интерфейсов был выставлен под ожидание нового ядра, либо сбой не связан с апдейтом). Проверьте journalctl -b на этом старом ядре — ищите сетевые ошибки независимо от версии ядра.
• Не грузится вообще ничего, зависает на GRUB или на initramfs — это не сетевая проблема, а проблема сборки initramfs под новое ядро (частая причина — не пересобрался dracut/update-initramfs с драйвером диска). Тут вообще не о чем говорить в контексте сети, сначала нужно поднять сам boot.

В этой статье разбираем именно первый сценарий: ядро новое, сервер загрузился, но сеть не поднялась.

Три типичные причины именно после обновления ядра

Если бы дело было в конфиге, который не менялся годами, сеть отваливалась бы и без апдейта ядра. Раз проблема появилась именно после смены ядра — ищите среди причин, которые завязаны на ядро и его драйверы, а не на общую конфигурацию сети.

Переименование сетевых интерфейсов. Современные дистрибутивы используют предсказуемые имена интерфейсов (ens3, enp0s3, eno1 вместо классического eth0) — это генерируется правилами systemd/udev на основе PCI-топологии, версии прошивки биоса и данных, которые ядро отдаёт о железе. При смене ядра (особенно при переходе через мажорные версии, скажем с 5.x на 6.x) может измениться то, как ядро видит и нумерует сетевые устройства — и интерфейс, который был ens3, вдруг стал ens4, либо схема именования вовсе переключилась на eth0. Если ваш конфиг сети жёстко прописывает ens3, а физически такого интерфейса больше нет — сеть не поднимется, хотя карта работает.

Недостающий модуль сетевой карты в новом ядре. Это особенно актуально на выделенных серверах со специфичным сетевым железом — Mellanox (mlx4_en/mlx5_core), Intel X710/X722 (i40e), Broadcom (bnxt_en) и подобные. Модуль драйвера мог:

• не собраться автоматически через DKMS при апдейте ядра (если драйвер идёт как DKMS-пакет, а не встроен в ядро);
• быть исключён из нового initramfs, если пересборка initramfs прошла до установки актуального модуля;
• иметь несовместимый ABI с новым ядром — старый бинарный модуль просто не грузится под новую версию.

В этом случае ip link show покажет, что интерфейса физически нет вообще — ядро его не видит, и дело не в конфигурации, а в отсутствующем драйвере.

Конфликт конфигурации сети между управляющими стеками. Если на сервере одновременно есть следы старого ifupdown (файл /etc/network/interfaces) и нового systemd-networkd или NetworkManager (файлы в /etc/netplan/ или /etc/NetworkManager/), при обновлении пакетов вместе с ядром мог поменяться дефолтный сетевой менеджер дистрибутива, и после ребута поднялся не тот стек, который ожидался. Наблюдается это часто на Ubuntu/Debian, где апгрейд дистрибутива заодно с ядром меняет систему по умолчанию с ifupdown на netplan+systemd-networkd, а старый конфиг остаётся лежать нетронутым и никем не читается.

Диагностика через консоль: ip link show и journalctl -b

Работая только через консоль хостера (клавиатура + текстовый вывод, без удобного копипаста — наберитесь терпения), пройдите по шагам.

Смотрим, видит ли ядро вообще интерфейсы:

ip link show

Если в выводе нет ни одного интерфейса кроме lo (loopback) — это симптом недостающего модуля драйвера. Проверьте, загружен ли он:

lsmod | grep -iE 'mlx|ixgbe|i40e|bnxt|igb|e1000'

Если модуля в списке нет — попробуйте загрузить вручную:

modprobe ixgbe

(замените на нужное имя модуля под ваше железо). Если modprobe ругается на отсутствие модуля для текущей версии ядра — драйвер действительно не собран под новое ядро, и это подтверждает диагноз.

Если интерфейс в ip link show есть, но состояние DOWN, а IP-адреса нет — смотрим логи именно этой загрузки:

journalctl -b

Флаг -b без параметров показывает логи текущей (последней) загрузки — то есть именно то, что произошло при старте на новом ядре. Для сравнения с предыдущей загрузкой (на старом ядре, когда всё работало):

journalctl -b -1

Отфильтруйте по сети и ядру:

journalctl -b -k | grep -iE 'eth|ens|enp|link|carrier|firmware'

Обратите внимание на строки вида renamed from — это прямое подтверждение переименования интерфейса ядром. Строки Direct firmware load failed или Cannot find firmware — признак того, что новому ядру не хватает файла прошивки для сетевой карты (актуально для некоторых Intel/Mellanox карт, где firmware ставится отдельным пакетом linux-firmware, который тоже нужно обновлять вместе с ядром).

Проверьте, какой сетевой менеджер вообще активен и не конфликтуют ли два одновременно:

systemctl status systemd-networkd
systemctl status NetworkManager
systemctl status networking

Если активны два конфликтующих стека одновременно (например, systemd-networkd и NetworkManager оба запущены и оба претендуют на один интерфейс) — это и есть причина: они спорят за интерфейс, и в итоге ни один не поднимает его корректно.

Быстрое восстановление: откат на предыдущее ядро через GRUB

Пока вы разбираетесь в первопричине, разумно вернуть сервер в сеть на старом (рабочем) ядре — это снимает давление и позволяет чинить новое ядро не по остаточному принципу «пока сервер офлайн», а спокойно.

При перезагрузке через консоль хостера (reboot из текущей сессии, если она у вас есть, либо через кнопку reset/power cycle в панели хостера) ловите момент меню GRUB — обычно нужно быстро нажать любую клавишу (Shift или Esc в зависимости от дистрибутива), пока не истекло время автозагрузки по умолчанию.

Если ваш пакетный менеджер не удалил старое ядро при установке нового (по умолчанию большинство дистрибутивов хранят 2-3 последних ядра), в меню GRUB будет пункт «Advanced options for...» с подпунктами по каждой версии ядра. Выберите предыдущую рабочую версию и загрузитесь один раз (без изменения дефолта).

Если консоль хостера не даёт интерактивности в момент GRUB-меню (бывает с некоторыми упрощёнными веб-KVM с задержкой) — можно выставить нужное ядро загрузки по умолчанию заранее, находясь ещё в рабочей системе на старом ядре (до апдейта) или уже находясь в новом ядре без сети, но с доступом через консоль:

grep -c menuentry /boot/grub/grub.cfg
awk -F"'" '/menuentry / {print $2}' /boot/grub/grub.cfg

Первая команда покажет количество пунктов меню, вторая — их названия по порядку (нумерация в GRUB начинается с 0). Дальше указываем нужный пункт как единоразовый (сработает один раз, следующая загрузка снова пойдёт по умолчанию):

grub-reboot 2
reboot

Либо, если нужно закрепить откат постоянно, пока не разберётесь с новым ядром:

grub-set-default 2
update-grub

После загрузки на старом ядре проверьте uname -r ещё раз — убедитесь, что вернулись именно туда, куда планировали, и что сеть поднялась штатно (ip a, ping до внешнего хоста). Если сеть на старом ядре тоже не поднялась — значит, дело не в ядре, а в чём-то более общем (физическое отключение порта на стороне хостера, проблема с коммутатором), и стоит писать в поддержку хостера с этим уточнением — вы уже исключили версию ядра как причину.

Если ваша конфигурация похожа на ситуацию, когда после ребута недоступен сам SSH-доступ (а не обязательно из-за ядра), рядом есть более общий разбор: server-nedostupen-po-ssh-chto-delat.

Если откат — не вариант: чиним сеть на новом ядре

Иногда откатываться нельзя (например, обновление ядра было критично для безопасности, и оставаться на старом больше чем на пару часов не хочется) или предыдущее ядро уже удалено пакетным менеджером. Тогда чините сеть прямо на новом ядре, находясь в консоли хостера.

Если причина — переименование интерфейса. Найдите актуальное имя через ip link show или ls /sys/class/net/, затем либо переименуйте конфиг сети под новое имя (в /etc/netplan/*.yaml, /etc/network/interfaces или nmcli con — в зависимости от того, какой стек у вас на самом деле активен), либо закрепите старое имя правилом udev:

cat /etc/systemd/network/10-persistent-net.link

Если такого файла нет — создайте правило, привязывающее физический MAC-адрес карты к желаемому имени интерфейса, это надёжнее, чем полагаться на порядок PCI-энумерации ядра.

Если причина — недостающий модуль. Проверьте, установлен ли пакет с драйвером под текущее ядро (для DKMS-модулей):

dkms status

Если модуль числится собранным под старую версию ядра, но не под новую — пересоберите:

dkms autoinstall

После этого пересоберите initramfs, чтобы модуль точно попал в образ загрузки (иначе он может подгружаться слишком поздно, уже после того, как сеть должна была подняться):

update-initramfs -u -k all

(на дистрибутивах с dracut команда будет dracut -f --regenerate-all).

Если причина — конфликт network stack. Определитесь, какой менеджер сети должен быть главным, и отключите второй:

systemctl disable --now NetworkManager
systemctl enable --now systemd-networkd

(или наоборот — важно оставить ровно один активный стек, а не гадать, какой победит в гонке при следующей загрузке). После смены — systemctl restart выбранного сервиса и проверка ip a, что адрес получен.

Во всех трёх случаях после исправления делайте пробную перезагрузку сразу, пока вы ещё в консоли — не полагайтесь, что раз сеть поднялась «руками» сейчас, она поднимется так же и после следующего reboot. Причина проблемы обычно лежит именно в том, что происходит на этапе загрузки, а не в текущем работающем состоянии.

Как не оказаться в этой ситуации: практика для важных серверов

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

• Не полагайтесь, что апдейт пройдёт гладко на важном сервере. Планируйте окно обслуживания заранее, а не обновляйте ядро «между делом» в рабочее время без возможности быстро отреагировать.
• Держите доступ к консоли хостера настроенным и проверенным заранее, а не вспоминайте пароль от панели в момент, когда сервер уже недоступен по сети. Проверьте, что у вас есть рабочий логин в KVM/IPMI ещё до апдейта — на некоторых тарифах доступ к консоли нужно отдельно включать в панели.
• Тестируйте обновление сначала на менее критичном сервере с похожей конфигурацией сетевого железа и стека (тот же драйвер карты, тот же набор netplan/NetworkManager/ifupdown). Если у вас несколько серверов с одинаковым образом — накатите апдейт сначала на staging или на наименее критичный из них, подождите хотя бы один полный цикл перезагрузки, и только потом переходите к боевым машинам.
• Не удаляйте старые ядра сразу после апдейта. Большинство пакетных менеджеров по умолчанию оставляют 2-3 последних версии — не форсируйте очистку (apt autoremove --purge с флагами агрессивной очистки) сразу после обновления, оставьте себе путь отката хотя бы на неделю.
• Зафиксируйте список сетевых интерфейсов и их MAC-адресов до апдейта (ip link show, ip -br link) — если после ребута что-то переименовалось, у вас будет с чем сравнивать, а не придётся гадать по памяти.
• Если сервер перезагружался сам, без вашего участия, а не в рамках планового апдейта ядра — это отдельная ситуация с другими причинами, разбор есть здесь: server-sam-perezagruzilsya-kak-ponyat-pochemu.

Если на сервере поднят VPN-туннель (например, WireGuard) и после перезагрузки пропала не вся сеть, а именно туннель — там своя логика диагностики, отдельно от общей сетевой проблемы: wireguard-ne-rabotaet-posle-perezagruzki-prichiny-i-reshenie.

Частые вопросы