Паника ядра на виртуальных машинах Linux в Azure
Область применения: ✔️ виртуальные машины Linux
В этой статье рассматривается несколько условий, которые могут привести к панике ядра и предоставляют рекомендации по устранению неполадок.
Как правило, паника ядра — это ситуация, когда ядро не может загрузиться должным образом, и поэтому система не загрузится. Другая форма паники ядра возникает при возникновении ситуации, когда ядро не знает, как обрабатывать и защищать себя путем остановки.
Предварительные требования
Убедитесь, что последовательная консоль включена и работает на виртуальной машине Linux.
Как определить панику ядра?
Используйте портал Azure для просмотра выходных данных журнала последовательной консоли виртуальной машины в колонке загрузки диагностика, колонке последовательной консоли или AZ CLI для определения конкретной строки паники ядра.
Паника ядра выглядит примерно так же, как в выходных данных ниже, и отобразится в конце журнала последовательной консоли:
Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[ 300.206297] Kernel panic - xxxxxxxx
[ 300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G ------------ T 3.xxx.x86_64 #1
Некоторые из наиболее распространенных событий паники ядра:
| Паническое сообщение | Причина |
|---|---|
| Oops: 0000 [#1] SMP " (проверка журнала для получения сведений) | Система паниковала из-за разыменовки плохого адреса. |
| SysRq: активация аварийного завершения | Основной дамб был инициирован пользователем с sysrq-c или эхом c в /proc/sysrq-trigger. |
| ОШИБКА ядра при <имени пути/имени файла>:<номер> строки! | Этот формат является стандартным для неудавшегося проверки ошибок (который так же, как и ASSERT, но логика инвертируется). Имя файла и номер строки указывают, какая ошибка ошибок завершилась ошибкой. |
| Паника ядра — не синхронизируется: обратимая блокировка: зависания задач | Детектор обратимой блокировки обнаружил ЦП, который не планировал задачу наблюдателя в пороге мягкой блокировки. |
| Паника ядра — не синхронизирована: Watchdog обнаружил жесткий LOCKUP на ЦП 0 | Детектор жесткой блокировки обнаружил ЦП, который не получил никаких прерываний hrtimer в пределах порога жесткой блокировки. |
| Паника ядра — не синхронизируется: hung_task: заблокированные задачи | Зависающая задача сторожевой группы обнаружила по крайней мере одну задачу, которая находилась в неиспеченном состоянии больше, чем значение времени ожидания заблокированной задачи. |
| Паника ядра — не синхронизируется: вне памяти. выбран panic_on_oom | Система не имеет памяти и переключения и вынуждена запускать процессы убийства, чтобы освободить память (не поведение по умолчанию). |
| Паника ядра — не синхронизируется: из памяти и не могут быть убиты процессы... | Система избежал памяти и переключения и убивал процессы для освобождения памяти, но не было процессов, чтобы убить. |
| Паника ядра — не синхронизируется: произошла NMI, см. сведения о встроенном журнале управления. | Наблюдатель перехватил NMI (не маскируемое прерывание). |
| Паника ядра — не синхронизирована: ошибка IOCK NMI: не продолжается | Система получила NMI проверки ввода-вывода из оборудования (а не ошибка четности памяти) и kernel.panic_on_io_nmi была задана (не по умолчанию). |
| Паника ядра — не синхронизируется: NMI: не продолжается | Система получила NMI (ошибка четности оборудования или памяти), а kernel.panic_on_unrecovered_nmi была задана (не по умолчанию). |
| Паника ядра — не синхронизируется: nmi watchdog | Система получила NMI и kernel.panic_on_timeout или kernel.panic_on_oops была задана (не значения по умолчанию). |
| Паника ядра — не синхронизируется: проверка неустранимого компьютера | Событие исключения проверки компьютера было создано для неустранимого состояния. |
| Паника ядра — не синхронизирована: попытка убить инициализацию! | Процесс инициализации — это первый процесс, который необходимо запустить, и никогда не должен завершать работу. |
| Паника ядра — не синхронизируется: VFS: не удается подключить корневые fs в неизвестном блоке(0,0) | Предполагается, что ядро будет использовать initramfs для подключения корневых файлов. Эта ошибка возникает, когда ядро не имеет initramfs. |
Сценарий 1. Во время загрузки возникает паника ядра
Во время загрузки ядра не позволяет виртуальной машине завершить процесс запуска операционной системы. Это происходит каждый раз, когда виртуальная машина запущена, и она не разрешает вход.
Этот тип события обычно связан, но не ограничивается:
- Недавнее обновление ядра.
- Недавнее понижение уровня ядра.
- Изменения модуля ядра.
- Изменения конфигурации операционной системы (GRUB, sysctl и SELinux).
- Проблемы SELinux.
- Отсутствуют важные файлы и каталоги.
- Отсутствуют важные системные основные библиотеки и пакеты.
- Неправильные разрешения на файлы.
- Отсутствующие секции.
Разрешение для сценария 1
Чтобы справиться с этим типом паники ядра, можно использовать следующие подходы:
Метод 1. Использование последовательной консоли Azure
Используйте последовательную консоль Azure, чтобы прервать процесс загрузки и выбрать предыдущую версию ядра, если она доступна. Таким образом, виртуальная машина сможет снова загрузиться, а затем можно использовать один из следующих методов для устранения конкретной проблемы с ядром без загрузки:
- Переустановите или повторно создайте отсутствующий initramfs.
- Переустановите проблематичное ядро.
- Просмотрите загруженные или отсутствующие модули ядра.
- Просмотрите разделы.
Метод 2. Автономное восстановление с помощью виртуальной машины спасения
Если последовательная консоль Azure недоступна или предыдущее ядро недоступно, вам потребуется виртуальная машина спасения и восстановления для автономного восстановления.
Используйте команду "Восстановить виртуальную машину", чтобы создать виртуальную машину восстановления с копией подключенного диска ОС целевой виртуальной машины. Затем используйте chroot подключение копии файловых систем ОС на виртуальной машине восстановления. После этого попробуйте выполнить следующие методы, чтобы устранить проблемы с ядром:
- Переустановите или повторно создайте отсутствующий initramfs.
- Переустановите проблематичное ядро.
- Просмотрите загруженные или отсутствующие модули ядра.
- Просмотрите разделы.
- Восстановление отсутствующих файлов.
- Восстановление отсутствующих важных системных основных библиотек и пакетов.
Сценарий 2. Паника ядра во время выполнения
Этот тип паники ядра обычно активируется в непредсказуемое время после завершения процесса запуска операционной системы и приводит к остановке реагирования виртуальной машины, предотвращая вход в систему. Обычно это связано, но не ограничивается следующими способами:
- Недавнее обновление ядра.
- Недавнее понижение уровня ядра.
- Изменения модуля ядра.
- Изменения конфигурации операционной системы (GRUB, sysctl и SELinux).
- Проблемы SELinux.
- Изменения рабочей нагрузки приложения.
- Изменения или ошибки разработки приложений.
- Возможные ошибки ядра.
- Проблемы, связанные с производительностью.
Разрешение для сценария 2
Чтобы справиться с этим типом паники ядра, можно использовать следующие подходы:
- Проверьте использование ресурсов и общую производительность системы. Паника ядра может быть связана с возможной нехваткой ресурсов, которые могут привести к размеру виртуальной машины.
- По возможности установите последние обновления, доступные в соответствующих репозиториях дистрибутивов Linux. Паника ядра может быть связана с известными ошибками в ядре или другом программном обеспечении.
- Существует вероятность того, что паника ядра связана с недавним изменением ядра, в этом случае также рекомендуется загружать предыдущую версию ядра, как описано в разделе "Разрешение" для сценария 1.
- Если приведенные выше параметры не применимы, может потребоваться настроить kdump и создать основной дамп для совместного использования с поддержкой дальнейшего анализа.
Более конкретные сценарии паники ядра
Распространенные сценарии паники ядра с определенными инструкциями по устранению неполадок и восстановлению:
| Документ | Сценарий |
|---|---|
| В виртуальной машине Azure Linux на базе ядра 3.10 возникает неполадка после обновления главного узла | В этой статье описывается проблема, которая возникает при сбое виртуальной машины Linux Azure под управлением ядра 3.10 после обновления узла в Azure. |
| Восстановление виртуальной машины Linux Azure при проблемах с загрузкой ядра | В этой статье приводятся решения проблемы, при которой виртуальная машина Linux не может перезапустить после применения изменений ядра. |
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.