Устранение неполадок с загрузкой виртуальной машины Linux из-за ошибок файловой системы
Область применения: ✔️ виртуальные машины Linux
В этой статье приводятся рекомендации по устранению неполадок с загрузкой виртуальной машины Linux, вызванных ошибками файловой системы.
Симптомы
Вы не можете подключиться к виртуальной машине Azure Linux с помощью протокола Secure Shell (SSH), или состояние агента виртуальной машины в портал Azure не готово. При запуске диагностика загрузки в портал Azure или подключении к последовательной консоли отображаются записи журнала, похожие на следующие примеры:
Примечание.
- Не все примеры будут присутствовать.
- Сбой подключения не всегда приводит к вводу виртуальной машины в режиме экстренного реагирования. Если проблема связана с определенными критически важными файловыми системами, виртуальная машина не может использовать режим экстренного реагирования.
Пример 1. Не удается подключить файловую систему ext4
EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
Пример 2. Не удалось подключить устройство ext Logical Volume Manager (LVM)
[ 14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[ 14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.
Пример 3. Не удалось подключить файловую систему xfs
[ 8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[ 8.553867] XFS (sdc1): Unmount and run xfs_repair
[ 8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[ 8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0 XAGI............
[ 8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d ...@...........=
[ 8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff ...`............
[ 8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[ 8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.
Пример 4. Загрузка в режим аварийного реагирования
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):
Причина
Приведенные выше записи журнала указывают на повреждение диска. В некоторых ситуациях повреждение диска предотвратит полную загрузку виртуальной машины. Различные проблемы могут привести к повреждению диска, таким как проблемы с ядром Linux, ошибки драйвера, ошибки в базовом физическом или виртуальном оборудовании и т. д.
Решение
Чтобы устранить проблемы с загрузкой виртуальной машины Linux, вызванные ошибками файловой системы, восстановите виртуальную машину, исправив повреждение диска. Чтобы восстановить повреждение диска, выполните следующие действия.
Определите тип файловой системы.
Выберите режим восстановления (в сети или в автономном режиме).
Подготовьте среду восстановления в соответствии с выбранном режимом восстановления:
Используйте средства командной строки для восстановления проблемной файловой системы на диске.
Примечание.
- Важно создать резервную копию критически важных данных, так как на восстановленном диске может возникнуть потеря данных.
- Перед внесением изменений на диск создайте моментальный снимок, чтобы сохранить текущее состояние диска, даже если он находится в состоянии ошибки. Исправление повреждения диска изменит данные на диске, что приведет к риску.
Определение поврежденного диска
Чтобы определить, какой диск поврежден, скачайте последовательный журнал для виртуальной машины с помощью последовательной консоли или загрузки диагностика, просмотрите записи журнала во время загрузки и найдите конкретную ошибку, вызывающую сбой диска или подключения.
Ниже приведены три примера записи журнала. В этих примерах обратите внимание на текст в скобках, который сообщает поврежденное устройство.
В следующем примере поврежденное устройство:sdc1
[ 14.285807] XFS (sdc1): Mounting V5 Filesystem
[ 14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[ 14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.
В следующем примере секция, в которой возникает sda1ошибка файловой системы:
EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.
В следующем примере поврежденное устройство .dm-2 Это устройство Сопоставления устройств Linux, указывающее том LVM.
[ 18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.
Если вызываемое дисковое устройство использует имя формата SDXN, где X — буква из Z и N является необязательным номером секции, это означает, что диск необработан и может работать с помощью пути /dev/sdXN .
Если подключенное дисковое устройство использует такое имя, как /dev/mapper/vgname/lvname, /dev/vgname/lvname или dm-N, это означает, что используется устройство LVM. Обратите внимание на распознавание всех физических томов диска (PV), которые могут использоваться.
Она не поддерживается для группы томов LVM (VG), чтобы содержать диск ОС и любое количество дисков данных. Для такого сценария существует высокий риск потери данных. Однако несколько дисков данных допустимы в VG LVM.
При определении сопоставления ссылок на диски ОС на объекты дисков Azure:
- Для образов Marketplace корневая файловая система (/), /boot и /boot/efi находится на диске ОС.
- Для образов на основе LVM может существовать множество других системных подключений, таких как /home, /tmp, /usr, /var, /var/log и /opt.
- Дополнительные файловые системы, созданные для приложений, находятся на дисках данных, например /datadisk или /sap. Настройте их правильно, чтобы система может загружаться, даже если возникает ошибка. Если диск данных является устройством, которое загружается в режим аварийного реагирования, см . статью о предотвращении сбоя загрузки.
Укажите тип файловой системы
При первоначальной идентификации единственный метод для определения типа диска использует последовательный журнал, как было описано ранее в разделе "Определение поврежденного диска". Когда устройство диска сообщается в последовательном журнале, ошибки будут отображаться из модуля ядра Linux для файловой системы. Запишите каждую строку, в которой EXT4-fs указано или XFS указано. Для любых других типов файловой системы журнал находится в той же области. Файловая система, указанная в записях журнала, определяется файлом /etc/fstab . Убедитесь, что указанный формат правильный при выполнении восстановления.
Получив доступ к интерактивной оболочке, выполните lsblk команду с -f флагом, как показано ниже, чтобы показать устройства, пути (если файловая система подключена), а также тип файловой системы, который считывается с самого диска.
[root@localhost ~]# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
|-sda1 vfat 93DA-8C20 /boot/efi
|-sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot
|-sda3
`-sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
|-rootvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp
|-rootvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr
|-rootvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt
|-rootvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0
|-rootvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var
`-rootvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 /
sdb
`-sdb1 ext4 1dac7c4c-bf8e-4964-8a59-7359eef53d0a /mnt
sdc LVM2_member CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp xfs 733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1 ext4 704d9fb1-2207-4bb9-998c-029f776dc6d2 /opt/data
Ниже приведены некоторые важные моменты в выходных данных:
- С помощью отображения искусства ASCII можно увидеть, что существуют тома LVM, так как существует LVM2_MEMBER FSTYPE для sda4, содержащих объекты с такими именами, как
rootvg-rootlvиrootvg-homelv. rootvg-homelvне подключен, который обозначается пустым полем MOUNTPOINT.rootvg-homelvимеет тип файловой системы XFS. Это контраст с ошибкой подключения EXT4 во время загрузки. Если тип файловой системы несогласован, доверяйтеlsblkвыходным данным, а не содержимому fstab.
Выбор режима восстановления
Вы можете восстановить виртуальную машину через режим аварийного реагирования или режим с одним пользователем или в автономном режиме с помощью виртуальной машины спасения.
Требования к оперативному восстановлению
Доступ последовательной консоли к виртуальной машине.
Если используется режим экстренного реагирования, последовательная консоль должна отображать запрос на аварийный режим, корневая учетная запись должна быть разблокирована, а пароль должен быть известен.
Если используется однопользовательский режим, корневой пароль не нужен. Однопользовательский режим может использоваться при повреждении файловой системы, отличной от обязательных системных секций, таких как корневая (
/) или/usrповрежденная.
Требования к автономному восстановлению
Если не удается выполнить требования последовательной консоли для сетевого восстановления, выполните автономное восстановление с помощью виртуальной машины спасения. Для выполнения автономного восстановления требуется возможность создания виртуальной машины и управления дисками в Azure. Кроме того, вы можете использовать функционируют виртуальную машину Linux с доступом на уровне Azure к поврежденным дискам.
Подготовка среды для восстановления через Интернет
Если режим аварийного реагирования отображается в запросе на вход, как показано ниже, введите корневой пароль:
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):
Если корневой пароль не известен, или корневая учетная запись заблокирована, как в следующем выходных данных, используйте однопользовательский режим:
Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
Если среда восстановления в сети недоступна, перейдите к автономному восстановлению.
Подготовка среды для автономного восстановления
В отдельных виртуальных машинах или при сбое подключения является системной секцией, например корневая файловая система (/) или /usrнаиболее надежным способом восстановления диска, является использование аварийной виртуальной машины для получения доступа к диску. Вы можете создать виртуальную машину спасения автоматически или вручную.
Сведения об автоматическом создании виртуальной машины спасения см. в статье "Восстановление виртуальных машин Azure". Сведения о создании виртуальной машины спасения вручную см. в статье о создании виртуальной машины восстановления. В любом случае не подключайте тома с диска проблемы, так как файловая система не должна быть подключена для работы служебных программ восстановления.
Восстановление файловой системы
Перед восстановлением файловой системы убедитесь, что выполнены следующие действия:
- Обнаружена проблема с диском и секцией или структурой томов LVM.
- Тип файловой системы определен.
- (Необязательно) Копия диска проблемы или дисков в охватываемой группе томов LVM была подключена к виртуальной машине спасения.
- Доступ к интерактивной оболочке был защищен с помощью доступа к диску.
Чтобы выполнить восстановление файловой системы, перейдите к разделу "Восстановить файловую систему ext4" или "Восстановить файловую систему XFS" в соответствии с типом файловой системы.
Независимо от того, какой режим восстановления используется, команды для восстановления файловой системы одинаковы. У экстренной оболочки могут быть ограничения. Если команды недоступны в среде аварийного режима или возникают ошибки неизвестных типов файловой системы, подготовьте среду для автономного восстановления.
Команды для восстановления файловой системы могут не устранять все ошибки. Они работают вокруг повреждения диска, но потеря данных по-прежнему может произойти. После вывода команды о том, что файловая система очищается, повторно соберите исходную виртуальную машину с восстановленным диском и загрузите виртуальную машину для проверки данных.
В следующих разделах /dev/sdc1 поврежденная файловая система находится в необработанном режиме, а lv в VG rootvg — том LVhomelv. Замените эти значения фактически поврежденной файловой системой во всех экземплярах.
Восстановление файловой системы ext4
fsck [-y] FILESYSTEM Используйте команду для восстановления файловой системы ext4. Укажите файловую систему как раздел диска для необработанной файловой системы, например /dev/sdc1или путь /dev/rootvg/homelvлогического тома LVM.
Ниже приведен пример выходных данных команды:
[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid. Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes
/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#
Выходные данные показывают, что подтверждение изменения файловой системы запрашивается три раза. Если есть много запросов, нажмите клавиши CTRL+C и перезапустите fsck флаг -y , чтобы предположить "да" для всех вопросов. Если все файлы передаются как помещенные lost+found, вручную идентифицируйте их и поместите их в соответствующие расположения.
Если некоторые ошибки возникают и впоследствии исправлены, выполните fsck команду еще раз. Повторите, пока команда не fsck завершит работу с состоянием clean . В качестве примера см. следующие выходные данные:
[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#
Восстановление файловой системы xfs
Ниже приведены команды для восстановления файловой системы XFS:
xfs_repair [-n] FILESYSTEMxfs_repair [-L] FILESYSTEMmount FILESYSTEM MOUNTPOINT
Чтобы восстановить файловую систему XFS, выполните следующие действия.
Проверьте ошибки файловой
xfs_repair -nсистемы с помощью команды следующим образом:xfs_repair -n /dev/rootvg/homelvЕсли проверка выполнена успешно, перейдите к режиму восстановления, удалив
-nфлаг, который попытается устранить все возникшие ошибки, как показано ниже.xfs_repair /dev/rootvg/homelv
Для файловых систем XFS журналы, но незафиксированные изменения рассматриваются путем подключения файловой системы. Если во время устранения неполадок возникает следующая ошибка, попробуйте подключиться и просмотреть результаты.
ОШИБКА: файловая система имеет ценные изменения метаданных в журнале, который необходимо воспроизвести
Если используется виртуальная машина восстановления, создайте каталог для временной точки подключения, например /recoveryи подключите файловую систему. Если среда восстановления находится в аварийном или однопользовательском режиме, подключите файловую систему в своем предполагаемом расположении. Ознакомьтесь со следующими командами в качестве примеров:
mount /dev/rootvg/homelv /recovery
or
mount /home
Если внесенные в журнал изменения не записываются при подключении файловых систем, используйте -L флаг для отмены журнала и подключения файловой системы, как если бы все изменения успешно завершены. При использовании флага -L происходит потеря данных, так как в журнале отображаются неполные операции с файлами.
xfs_repair -L /dev/rootvg/homelv /recovery
Предотвращение сбоя загрузки
nofail Если параметр указан при подключении файловых систем, повреждение некритичной файловой системы может не препятствовать полной загрузке Linux. Дополнительные сведения см. в nofailразделе "Подключение диска". Большинство подключений в сторону от корневого (/), /usrи /var можно сделать с nofailпомощью .
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.