Не удается загрузить виртуальную машину Linux после применения изменений ядра

Статья
07/30/2024

Область применения: ✔️ виртуальные машины Linux

Примечание.

CentOS, на который ссылается в этой статье, является дистрибутивом Linux и достигнет конца жизни (EOL). Думайте об использовании и планировании соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

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

Предварительные требования

Убедитесь, что последовательная консоль включена и работает на виртуальной машине Linux.

Как определить проблему загрузки, связанную с ядром

Чтобы определить проблему загрузки, связанную с ядром, проверьте конкретную строку паники ядра. Для этого используйте Azure CLI или портал Azure для просмотра выходных данных журнала последовательной консоли виртуальной машины в области загрузки диагностика или последовательной консоли.

Паника ядра выглядит следующим образом и отобразится в конце журнала последовательной консоли:

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

Сетевое устранение неполадок

Совет

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

Последовательная консоль — это самый быстрый метод для устранения проблемы загрузки. Это позволяет напрямую устранять проблему без необходимости представить системный диск виртуальной машине восстановления. Убедитесь, что вы соответствуете необходимым предварительным требованиям для распространения. Дополнительные сведения см. в последовательной консоли виртуальной машины для Linux.

Определите конкретную проблему загрузки, связанную с ядром.
Используйте последовательную консоль Azure, чтобы прервать виртуальную машину в меню GRUB и выбрать любое предыдущее ядро, чтобы загрузить его. Дополнительные сведения см. в статье "Загрузка системы" в более старой версии ядра.
Перейдите к соответствующему разделу, чтобы устранить конкретную проблему загрузки, связанную с ядром:
После устранения проблемы загрузки, связанной с ядром, перезапустите виртуальную машину, чтобы она была загружена в последнюю версию ядра.

Автономное устранение неполадок

Совет

Если последовательная консоль Azure не работает на конкретной виртуальной машине или не является вариантом в подписке, устраните неполадку загрузки с помощью виртуальной машины спасения и восстановления. Для этого выполните следующие шаги.

Используйте команды восстановления виртуальной машины для создания виртуальной машины с копией подключенного диска операционной системы затронутой виртуальной машины. Подключите копию файловых систем ОС на виртуальной машине восстановления с помощью chroot.

Примечание.

Кроме того, можно создать виртуальную машину спасения вручную с помощью портал Azure. Дополнительные сведения см. в статье "Устранение неполадок виртуальной машины Linux путем подключения диска ОС к виртуальной машине восстановления с помощью портал Azure".
Определите конкретную проблему загрузки, связанную с ядром.
Перейдите к соответствующему разделу, чтобы устранить конкретную проблему загрузки, связанную с ядром:
После устранения проблемы загрузки, связанной с ядром, выполните следующие действия:
1. Выход из chroot.
2. Отключите копию файловых систем из виртуальной машины спасения и восстановления.
3. az vm repair restore Выполните команду, чтобы переключить восстановленный диск ОС на исходный диск ОС виртуальной машины. Дополнительные сведения см. в шаге 5 в разделе "Восстановление виртуальной машины Linux" с помощью команд восстановления виртуальной машины Azure.
4. Проверьте, может ли виртуальная машина загрузиться, взглянув на последовательную консоль Azure или попытаясь подключиться к виртуальной машине.
Если содержимое, связанное с ядром, отсутствует весь /boot раздел или другое важное содержимое, и их невозможно восстановить, рекомендуется восстановить виртуальную машину из резервной копии. Дополнительные сведения см. в статье "Как восстановить данные виртуальной машины Azure в портал Azure".

Загрузка системы в более старой версии ядра

Использование последовательной консоли Azure

Перезапустите виртуальную машину с помощью последовательной консоли Azure.
1. Нажмите кнопку завершения работы в верхней части окна последовательной консоли.
2. Выберите параметр "Перезапустить виртуальную машину (жесткий") .
После возобновления подключения последовательной консоли вы увидите счетчик отсчета в левом верхнем углу окна последовательной консоли. Нажмите клавишу ESCAPE, чтобы прервать виртуальную машину в меню GRUB.
Нажмите клавишу СТРЕЛКА ВНИЗ, чтобы выбрать любую предыдущую версию ядра.
Измените GRUB_DEFAULT переменную в файле /etc/default/grub , как описано в разделе "Изменение версии ядра по умолчанию" вручную. Это постоянное изменение.

Примечание.

Если в меню GRUB указана только одна версия ядра, выполните подход к устранению неполадок в автономном режиме, чтобы устранить эту проблему с виртуальной машины восстановления.

Использование виртуальной машины восстановления (скрипты ALAR)

Выполните следующую команду bash в Azure Cloud Shell , чтобы создать виртуальную машину восстановления. Дополнительные сведения см. в статье "Автоматическое восстановление Azure Linux" (ALAR) для исправления параметра ядра виртуальной машины Linux.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```
Выполните следующую команду, чтобы заменить сломанное ядро ранее установленной версией:
```
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME
```

Примечание.

Если в системе установлена только одна версия ядра, выполните подход к устранению неполадок в автономном режиме, чтобы устранить эту проблему с виртуальной машины восстановления.

Изменение версии ядра по умолчанию вручную

Чтобы изменить версию ядра по умолчанию из виртуальной машины восстановления (внутри chroot) или на работающей виртуальной машине, выполните следующие действия.

Примечание.

Если выполняется откат вниз ядра, выберите последнюю версию ядра вместо более старой.

RHEL 7, Oracle Linux 7 и CentOS 7
1. Проверьте список доступных ядер в файле конфигурации GRUB, выполнив одну из следующих команд:
  - Виртуальные машины 1-го поколения:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
  - Виртуальные машины 2-го поколения:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Задайте новое ядро по умолчанию и укажите соответствующее название ядра, выполнив следующую команду:
```
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'
```
  Примечание.
  
  Замените Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 соответствующим заголовком меню.
3. Убедитесь, что новое ядро по умолчанию является нужным, выполнив следующую команду:
```
grub2-editenv list
```
4. Убедитесь, что для переменной GRUB_DEFAULT в файле /etc/default/grub задано значение saved. Чтобы изменить его, необходимо повторно создать файл конфигурации GRUB, чтобы применить изменения.
RHEL 8/9 и CentOS 8
1. Выведите список доступных ядер, выполнив следующую команду:
```
ls -l /boot/vmlinuz-*
```
2. Задайте новое ядро по умолчанию, выполнив следующую команду:
```
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64
```
  Примечание.
  
  Замените 4.18.0-372.19.1.el8_6.x86_64 соответствующей версией ядра.
3. Убедитесь, что новое ядро по умолчанию является нужным, выполнив следующую команду:
```
grubby --default-kernel
```
SLES 12/15, Ubuntu 18.04/20.04
1. Выведите список доступных ядер в файле конфигурации GRUB, выполнив следующую команду:
  - Виртуальные машины 1-го поколения:
    - SLES 12/15:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
    - Ubuntu 18.04/20.04:
```
cat /boot/grub/grub.cfg | grep menuentry
```
  - Виртуальные машины 2-го поколения:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. Задайте новое ядро по умолчанию, изменив значение GRUB_DEFAULT переменной в файле /etc/default/grub . Для последней версии ядра, установленной в системе, значение по умолчанию равно 0. Следующее доступное ядро имеет значение "1>2".
```
vi /etc/default/grub
GRUB_DEFAULT="1>2"
```
  Примечание.
  
  Дополнительные сведения о настройке переменной GRUB_DEFAULT см. в статье SUSE Boot Loader GRUB2 и Ubuntu Grub2/Setup. В качестве ссылки: значение меню верхнего уровня равно 0, первое значение подменю верхнего уровня равно 1, а каждое вложенное значение меню начинается с 0. Например, "1>2" является третьим меню из первого подменю.
3. Повторно создайте файл конфигурации GRUB, чтобы применить изменения. Следуйте инструкциям в разделе "Переустановка GRUB" и повторное создание файла конфигурации GRUB для соответствующего дистрибутива Linux и создания виртуальных машин.

Паника ядра — не синхронизируется: VFS: не удается подключить корневые fs в неизвестном блоке(0,0)

Эта ошибка возникает из-за недавнего обновления системы (ядра). Чаще всего это видно в дистрибутивах на основе RHEL. Эту проблему можно определить из последовательной консоли Azure. Вы увидите любое из следующих сообщений об ошибках:

"Паника ядра — не синхронизируется: VFS: не удается подключить корневые fs в неизвестном блоке(0,0)"

[  301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[  301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.10.0-1160.36.2.el7.x86_64 #1
[  301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
[  301.027122] Call Trace:
[  301.027122]  [<ffffffff82383559>] dump_stack+0x19/0x1b
[  301.027122]  [<ffffffff8237d261>] panic+0xe8/0x21f
[  301.027122]  [<ffffffff8298b794>] mount_block_root+0x291/0x2a0
[  301.027122]  [<ffffffff8298b7f6>] mount_root+0x53/0x56
[  301.027122]  [<ffffffff8298b935>] prepare_namespace+0x13c/0x174
[  301.027122]  [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249
[  301.027122]  [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122]  [<ffffffff8237235e>] kernel_init+0xe/0x100
[  301.027122]  [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

"ошибка: файл "/initramfs-*.img" не найден"

ошибка: файл "/initramfs-3.10.0-1160.36.2.el7.x86_64.img" не найден.

Эта ошибка означает, что файл initramfs не создается, файл конфигурации GRUB содержит запись initrd, которая отсутствует после процесса исправления или неправильной настройки GRUB вручную.

Перед перезагрузкой сервера рекомендуется выполнить проверку конфигурации и /boot содержимого GRUB, если есть обновление ядра, выполнив одну из следующих команд. Важно убедиться, что обновление выполнено, и отсутствуют файлы initramfs.

BIOS на основе систем 1-го поколения
```
# ls -l /boot
# cat /boot/grub2/grub.cfg
```
На основе UEFI — системы 2-го поколения
```
# ls -l /boot
# cat /boot/efi/EFI/*/grub.cfg
```

Повторное создание отсутствующих инициамфов с помощью скриптов ALAR для восстановления виртуальной машины Azure

Создайте виртуальную машину восстановления, выполнив следующую командную строку Bash с помощью Azure Cloud Shell. Дополнительные сведения см. в статье "Автоматическое восстановление Azure Linux" (ALAR) для исправления параметра initrd виртуальной машины Linux.
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```
Повторно создайте образ initrd/initramfs и повторно создайте файл конфигурации GRUB, если запись initrd отсутствует. Для этого выполните следующую команду:
```
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME
```
После выполнения команды восстановления перезапустите исходную виртуальную машину и убедитесь, что она сможет загрузиться.

Повторное создание отсутствующих initramfs вручную

Внимание

Если вы можете загрузить виртуальную машину с помощью предыдущей версии ядра или внутри chroot из виртуальной машины восстановления или спасения, повторно создайте отсутствующие инициамфы вручную.
Чтобы повторно создать отсутствующие initramfs вручную из виртуальной машины восстановления, убедитесь, что шаг 1 в автономном устранении неполадок уже выполнен, и эти команды выполняются внутри chroot.

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

См. следующий снимок экрана: пример. Ошибка паники ядра показывает, что версия ядра — "3.10.0-1160.59.1.el7.x86_64":
Повторно создайте отсутствующий файл initramfs, выполнив одну из следующих команд:
- RHEL/CentOS/Oracle Linux 7/8
```
sudo depmod -a 3.10.0-1160.59.1.el7.x86_64
sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64
```
  Внимание
  
  Замените 3.10.0-1160.59.1.el7.x86_64 соответствующей версией ядра.
- SLES 12/15
```
sudo depmod -a 5.3.18-150300.38.53-azure
sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure
```
  Внимание
  
  Замените 5.3.18-150300.38.53-azure соответствующей версией ядра.
- Ubuntu 18.04
```
sudo depmod -a 5.4.0-1077-azure
sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure
```
  Внимание
  
  Замените 5.4.0-1077-azure соответствующей версией ядра.
Повторно создайте файл конфигурации GRUB. Следуйте инструкциям в разделе "Переустановка GRUB" и повторное создание файла конфигурации GRUB для соответствующего дистрибутива Linux и создания виртуальных машин
Если описанные выше действия выполняются из виртуальной машины восстановления, выполните шаг 3 в автономном режиме. Если описанные выше действия выполняются из консоли Последовательной службы Azure, выполните метод устранения неполадок в Сети.
Перезагрузите виртуальную машину по последней версии ядра.

Паника ядра — не синхронизирована: попытка убить инициализацию

Определите эту проблему из последовательной консоли Azure. Вы увидите следующие выходные данные:

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
 [<ffffffff81558bfa>] ? panic+0xa7/0x18b
 [<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
 [<ffffffff81086433>] ? do_exit+0x853/0x860
 [<ffffffff811a33b5>] ? fput+0x25/0x30
 [<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
 [<ffffffff81086498>] ? do_group_exit+0x58/0xd0
 [<ffffffff81086527>] ? sys_exit_group+0x17/0x20
 [<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
 [<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152

Такая паника ядра возникает из-за следующих возможных причин:

Отсутствуют важные файлы и каталоги.
Отсутствуют важные системные основные библиотеки и пакеты
Неправильные разрешения на файл
Отсутствующие секции
Проблемы SELinux

Дополнительные сведения о причинах и решениях см. в следующих разделах. Убедитесь, что команды выполняются из виртуальной машины восстановления и спасения в среде chroot, как описано в автономном устранении неполадок.

Отсутствуют важные файлы и каталоги

Важные файлы и каталоги Linux отсутствуют из-за ошибки человека. Например, файлы случайно удаляются или повреждены файловой системы.

Проверьте содержимое диска ОС после подключения копии диска ОС к виртуальной машине восстановления и подключения соответствующих файловых систем с помощью chroot. Выходные данные можно сравнить с данными из рабочей виртуальной машины с той же версией ОС.
```
ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more
```
Восстановите отсутствующие файлы из резервной копии. Дополнительные сведения см. в статье "Восстановление файлов из резервной копии виртуальных машин Azure". В зависимости от количества отсутствующих файлов может быть лучше выполнить полное восстановление виртуальной машины. Дополнительные сведения см. в статье "Как восстановить данные виртуальной машины Azure в портал Azure".

Отсутствуют важные системные основные библиотеки и пакеты

Важные системные основные библиотеки, файлы или пакеты удаляются из системы или повреждены. Чтобы устранить эту проблему, переустановите затронутые библиотеки, файлы или пакеты. Это решение работает на дистрибутивах на основе RPM, таких как Red Hat/CentOS/SUSE виртуальных машин. Для других дистрибутивов Linux рекомендуется восстановить виртуальную машину из резервной копии.

Чтобы выполнить переустановку, выполните следующие действия.

Создайте виртуальную машину спасения с помощью необработанного образа с той же версией ОС и созданием, что и затронутая виртуальная машина.
Чтобы устранить проблему, обратитесь к среде chroot в виртуальной машине спасения.
```
sudo chroot /rescue
```
Выходные данные команды указывают, какая библиотека отсутствует или повреждена, как показано ниже:
```
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```
Проверьте все системные пакеты и соответствующее состояние в виртуальной машине спасения. Сравните выходные данные с работоспособной виртуальной машиной с той же версией ОС.
```
sudo rpm --verify --all --root=/rescue 
```
Ниже показан пример результатов выполнения этой команды:
```
error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE
S.5....T.  c /etc/dnf/dnf.conf
S.5....T.  c /etc/ssh/sshd_config
.M.......    /boot/efi/EFI/BOOT/BOOTX64.EFI
.M.......    /boot/efi/EFI/BOOT/fbx64.efi
.M.......    /boot/efi/EFI/redhat/BOOTX64.CSV
.M.......    /boot/efi/EFI/redhat/mmx64.efi
.M.......    /boot/efi/EFI/redhat/shimx64-redhat.efi
.M.......    /boot/efi/EFI/redhat/shimx64.efi
missing     /run/motd.d
.M.......  g /var/spool/anacron/cron.daily
.M.......  g /var/spool/anacron/cron.monthly
.M.......  g /var/spool/anacron/cron.weekly
missing     /lib64/libc-2.28.so     <-------
.M.......    /boot/efi/EFI/redhat
S.5....T.  c /etc/security/pwquality.conf
```
Выходная строка missing /lib64/libc-2.28.so связана с предыдущей ошибкой на шаге 2 и указывает , что пакет libc-2.28.so отсутствует. Однако пакет libc-2.28.so можно изменить. В этом случае выходные данные будут отображаться .M..... вместо missing. На пакет libc-2.28.so ссылается пример, приведенный ниже.
На виртуальной машине спасения проверьте, какой пакет содержит библиотеку /lib64/libc-2.28.so.
```
sudo rpm -qf /lib64/libc-2.28.so
```
```
glibc-2.28-127.0.1.el8.x86_64
```
Примечание.

В выходных данных отобразится пакет, который необходимо переустановить, включая имя пакета и версию. Версия пакета может отличаться от версии, установленной на затронутой виртуальной машине.

На затронутой виртуальной машине проверьте, какая версия пакета glibc установлена.

sudo rpm -qa --all --root=/rescue | grep -i glibc

glibc-common-2.28-211.0.1.el8.x86_64
glibc-gconv-extra-2.28-211.0.1.el8.x86_64
glibc-2.28-211.0.1.el8.x86_64     <----  
glibc-langpack-en-2.28-211.0.1.el8.x86_64

Скачайте пакет glibc-2.28-211.0.1.el8.x86_64. Его можно скачать с официального веб-сайта поставщика ОС или из аварийной виртуальной машины с помощью средства управления пакетами, например yumdownloader или zypper install --download-only <packagename> в зависимости от используемой операционной системы.

Ниже приведен пример использования yumdownloader средства:
```
cd /tmp
sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64
```
```
Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC.
glibc-2.28-211.0.1.el8.x86_64.rpm               8.7 MB/s | 2.2 MB     00:00    
```

Переустановите затронутый пакет на виртуальной машине спасения.

sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefiles

warning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:glibc-2.28-211.0.1.el8           ################################# [100%]

Чтобы проверить переустановку, перейдите к среде chroot в виртуальной машине спасения.
```
sudo chroot /rescue
```
Отключите виртуальную машину спасения и переключите диск ОС на затронутую виртуальную машину.

Неправильные разрешения на файл

Неправильные разрешения на широкий файл изменяются из-за ошибки человека (например, кто-то работает chmod 777 в / или других важных файловых системах ОС). Чтобы устранить эту проблему, восстановите разрешения файла. Это решение работает на дистрибутивах на основе RPM, таких как Red Hat/CentOS/SUSE виртуальных машин. Для других дистрибутивов Linux рекомендуется восстановить виртуальную машину из резервной копии.

Чтобы восстановить разрешения файла, выполните следующую команду после присоединения копии диска ОС к виртуальной машине восстановления и подключения соответствующих файловых систем с помощью chroot:

rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key

Примечание.

Не выполняйте эту команду в рабочих системах.

Если проблема по-прежнему существует после восстановления соответствующих разрешений файла вручную, выполните восстановление из резервной копии.

Отсутствующие секции

В случаях, когда /usr, /opt, , /tmp/var/homeи / файловые системы распределяются по разным секциям, данные могут быть недоступны из-за проблем на уровне секций, которые могут быть вызваны ошибками во время операций изменения размера секции или других.

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

Если этот подход не работает, выполните восстановление из резервной копии.

Проблемы SELinux

Неправильные разрешения SELinux могут препятствовать системе получать доступ к важным файлам. Проблему можно устранить следующим способом.

Чтобы проверить наличие проблем в системе из-за неправильных разрешений SELinux, запустите систему с отключенным SELinux, добавив параметр ядра selinux=0 в строку GRUB linux16.
Если система может загрузиться, выполните следующую команду, чтобы активировать relabel SELinux во время загрузки и перезагрузить систему:
```
touch /.autorelabel
```
Если виртуальная машина по-прежнему не может загрузиться, выполните полное восстановление виртуальной машины из резервной копии. Дополнительные сведения см. в статье "Как восстановить данные виртуальной машины Azure в портал Azure".

Другие проблемы загрузки, связанные с ядром

В этой статье рассматриваются наиболее распространенные паники ядра Linux, выявленные в Azure. Дополнительные сведения о распространенных сценариях паники ядра см. в разделе "Паника ядра" на виртуальных машинах Linux Azure — распространенные события паники ядра.

Существуют некоторые другие важные возможные паники ядра, которые могут вызвать отсутствие загрузки или сценарии безопасной оболочки (SSH).

Убедитесь, что вы выполняете все команды из виртуальной машины восстановления в среде chroot, как описано в автономном режиме устранения неполадок. Если система уже загружена на предыдущую версию ядра, эти команды также можно выполнить с исходной виртуальной машины с помощью привилегий корневого компьютера или sudo, как описано в разделе "Устранение неполадок в Сети".

Последнее обновление ядра

Если ядро паникует после недавнего обновления ядра, загрузите виртуальную машину в предыдущей версии ядра. Дополнительные сведения см. в статье "Загрузка системы" в более старой версии ядра.

Вы также можете проверить, есть ли уже более новая версия ядра, выпущенная поставщиком дистрибутива Linux, и установить ее. Дополнительные сведения о том, как установить последнюю версию ядра, см. в разделе "Процесс обновления ядра".

Последнее понижение уровня ядра

Если ядро паникует после недавнего понижения уровня ядра, вернитесь к последнему установленному ядру. Вы также можете проверить, есть ли уже более новая версия ядра, выпущенная поставщиком дистрибутива Linux, и установить ее. Дополнительные сведения о том, как установить последнюю версию ядра, см. в разделе "Процесс обновления ядра".

Чтобы загрузить систему по последней версии ядра, следуйте инструкциям в разделе "Изменить версию ядра по умолчанию вручную", но выберите первое ядро, указанное в меню GRUB. В ручном изменении можно задать GRUB_DEFAULT значение 0 и повторно создать соответствующий файл конфигурации GRUB.

Изменения модуля ядра

Может возникнуть паника ядра, связанная с новым модулем ядра или отсутствующим модулем ядра. Чтобы получить сведения о конкретном модуле ядра, который вызывает проблемы (если таковые есть), проверьте соответствующую трассировку паники ядра.

Чтобы проверить загруженные модули ядра и отключенные модули в файлах /etc/modprobe.d/*.conf , выполните одну из следующих команд:

RHEL/CentOS/Oracle Linux 7/8
```
lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img
lsmod
cat /etc/modprobe.d/*.conf
```
Внимание

Замените 3.10.0-1160.59.1.el7.x86_64 соответствующей версией ядра.
SLES 12/15
```
lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
lsmod
cat /etc/modprobe.d/*.conf
```
Внимание

Замените 5.3.18-150300.38.53-azure соответствующей версией ядра.
Ubuntu 18.04
```
lsinitramfs /boot/initrd.img-5.4.0-1077-azure
lsmod
cat /etc/modprobe.d/*.conf
```
Внимание

Замените 5.4.0-1077-azure соответствующей версией ядра.

Чтобы удалить любой конкретный модуль ядра, выполните следующую команду и повторно создайте initramfs при необходимости.

rmmod <kernel_module_name>

Если системная служба использует определенный модуль ядра, отключите его, выполнив systemctl disable <serviceName> команду или systemctl stop <serviceName> выполнив команду.

Последние изменения конфигурации операционной системы

Определите последние изменения конфигурации ядра, которые могут вызвать проблемы. Чтобы устранить проблемы, измените эти параметры или откатите изменения конфигурации.

Выполните следующую команду, чтобы найти параметры постоянного ядра, настроенные в любом из следующих файлов:

cat /etc/systctl.conf
cat /etc/sysctl.d/*

Выполните следующую команду, чтобы проанализировать текущие параметры ядра и их текущие значения:

sysctl -a

Примечание.

Выполните эту команду в работающей системе, а не из среды chroot.

Возможные отсутствующие файлы

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

Неправильные разрешения на файлы

Дополнительные сведения об этой проблеме см. в разделе "Неправильные разрешения файла".

Отсутствующие секции

Дополнительные сведения об этой проблеме см. в разделе "Отсутствующие секции".

ошибки ядра;

Определите эту проблему из последовательной консоли Azure. Эта проблема будет выглядеть следующим образом:

[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP

Этот тип паники ядра связан с ошибками ядра или сторонними ошибками ядра.

Чтобы устранить ошибки ядра, выполните поиск в базе знаний поставщика с помощью строки ошибки ядра и найдите известные проблемы в соответствующей версии ядра, запущенной системой. Ниже приведены некоторые важные ресурсы поставщика:

Red Hat Kernel Oops Analyzer

Это средство предназначено для диагностики сбоя ядра. При вводе текста, vmcore-dmesg.txt или файла, включая одно или несколько сообщений ядра, вы узнаете, как диагностировать проблему сбоя ядра.
База знаний Red Hat

Чтобы получить доступ к ресурсам Red Hat, свяжите учетные записи Microsoft Azure и Red Hat. Дополнительные сведения см. в статье о том, как клиенты Microsoft Azure могут получить доступ к порталу клиентов Red Hat.
База знаний SUSE
База знаний Ubuntu

Рекомендуем поддерживать все системы в актуальном состоянии, чтобы исключить любые возможные ошибки, уже исправленные в последних версиях ядра. Дополнительные сведения см. в разделе Процесс обновления ядра.

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

Процесс обновления ядра

Чтобы установить последнюю доступную версию ядра, выполните одну из следующих команд:

RHEL/CentOS/Oracle Linux
```
yum update kernel
```
SLES 12/15
```
zypper refresh
zypper update kernel*
```
Ubuntu 18.04/20.04
```
apt update
apt install linux-azure
```

Чтобы переустановить определенную версию ядра, выполните одну из следующих команд. Убедитесь, что вы не загружаетесь в той же версии ядра, которую вы пытаетесь переустановить. Дополнительные сведения см. в статье "Загрузка системы" в более старой версии ядра.

RHEL/CentOS/Oracle Linux
```
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64
```
Внимание

Замените 3.10.0-1160.59.1.el7.x86_64 соответствующей версией ядра.
SLES 12/15
```
zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64
```
Внимание

Замените kernel-azure-5.3.18-150300.38.75.1.x86_64 соответствующей версией ядра.
- Ubuntu 18.04/20.04
```
apt update
apt install --reinstall linux-azure=5.4.0.1091.68
```
  Внимание
  
  Замените 5.4.0.1091.68 соответствующей версией ядра.

Чтобы обновить систему и применить последние доступные изменения, выполните одну из следующих команд:

RHEL/CentOS/Oracle Linux
```
yum update
```
SLES 12/15
```
zypper refresh
zypper update
```
Ubuntu 18.04/20.04
```
apt update
apt upgrade
```

Паника ядра может быть связана с любым из следующих элементов. Дополнительные сведения см. в разделе "Паника ядра во время выполнения".

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

Следующие шаги

Если конкретная ошибка загрузки не связана с ядром, см. статью "Устранение неполадок с загрузкой Виртуальные машины Linux Azure" для дальнейших параметров устранения неполадок.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.

Поделиться через

Не удается загрузить виртуальную машину Linux после применения изменений ядра

Предварительные требования

Как определить проблему загрузки, связанную с ядром

Сетевое устранение неполадок

Автономное устранение неполадок

Загрузка системы в более старой версии ядра

Использование последовательной консоли Azure

Использование виртуальной машины восстановления (скрипты ALAR)

Изменение версии ядра по умолчанию вручную

Паника ядра — не синхронизируется: VFS: не удается подключить корневые fs в неизвестном блоке(0,0)

Повторное создание отсутствующих инициамфов с помощью скриптов ALAR для восстановления виртуальной машины Azure

Повторное создание отсутствующих initramfs вручную

Паника ядра — не синхронизирована: попытка убить инициализацию

Отсутствуют важные файлы и каталоги

Отсутствуют важные системные основные библиотеки и пакеты

Неправильные разрешения на файл

Отсутствующие секции

Проблемы SELinux

Другие проблемы загрузки, связанные с ядром

Последнее обновление ядра

Последнее понижение уровня ядра

Изменения модуля ядра

Последние изменения конфигурации операционной системы

Возможные отсутствующие файлы

Неправильные разрешения на файлы

Отсутствующие секции

ошибки ядра;

Процесс обновления ядра

Следующие шаги

Свяжитесь с нами для получения помощи

Обратная связь

Дополнительные ресурсы