Как проверить на ошибки lvm

Параметры fsck
Пример проверки диска на ошибки с помощью fsck
Запуск автоматической проверки и исправления найденных ошибок
Ручное добавление параметров в меню GRUB при загрузке ОС
Добавление параметров в меню GRUB с помощью утилиты grubby
Создание файла /forcefsck
Запуск проверки в ручном режиме
Использование загрузочного диска/flash для проверки файловой системы на ошибки
Проверка LVM-разделов с помощью утилиты fsck

В определенных случаях  (в результате сбоя или некорректного завершения работы)  на файловой системе могут накапливаться ошибки. В РЕД ОС для проверки файловой системы и исправления ошибок имеется утилита  fsck («file system consistency check»).

Инструмент fsck обладает следующим функционалом:

• проверка файловой системы при возникновении проблем (не загружается система/поврежденные файлы) или в качестве профилактического обслуживания;

• диагностика состояния внешних накопителей, таких как SD-карты или USB-накопители.

Базовый синтаксис соответствует следующему шаблону:

 fsck <опции> <файловая_система>

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

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

Параметры fsck

fsck –p – утилита автоматически исправит найденные ошибки.

Вывод аналогичен простой проверке.

fsck –с – проверка файловой системы на поврежденные сектора.

Для получения списка команд наберите fsck ––help или fsck –h.

Пример проверки диска на ошибки с помощью fsck

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

Существует несколько способов запуска автоматической проверки на ошибки:

1. Ручное добавление параметров в меню GRUB при загрузке ОС.

2. Добавление параметров в меню GRUB с помощью утилиты grubby.

3. Создание файла /forcefsck.

1. Ручное добавление параметров в меню GRUB при загрузке ОС

Первый вариант проверки и  исправления ошибок на разделах жесткого диска.

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

fsck.mode=force fsck.repair=yes

в конец предпоследней строки.

Нажмите Ctrl+Х для запуска ОС с этими параметрами, во время запуска будет произведена проверка разделов диска, и при наличии ошибок произведено их исправление.

2. Добавление параметров в меню GRUB с помощью утилиты grubby

Существует еще один способ добавления параметров ядра для принудительной проверки файловой системы на ошибки и их исправления. Добавить параметры можно командой:

grubby --update-kernel /boot/vmlinuz-$(uname -r) --args="fsck.mode=force fsck.repair=yes"

Удалить установленные параметры можно следующей командой:

grubby --update-kernel /boot/vmlinuz-$(uname -r) --remove-args="fsck.mode=force fsck.repair=yes"

3. Создание файла /forcefsck

Бывают ситуации, когда систему необходимо проверить на наличие ошибок в незапланированный момент. Для этого можно принудительно запустить утилиту fsck для проверки при следующей перезагрузке. Запуск осуществляется командой:

sudo touch /forcefsck

Команда sudo (после ввода пароля) предоставит права для создания с помощью touch пустого файла в корне диска /forcefsck, который послужит сигналом (флагом) для fsck, что нужно проверить диски. 

Останется только перезагрузить компьютер и fsck начнет проверять все жесткие диски, указанные в /etc/fstab.

Запуск проверки в ручном режиме

Следующий метод относится к проверке диска, когда операционная система загружена в режиме single mode.

1. Запустим ОС в single mode, для этого пропишите в меню загрузки grub параметр init=/bin/bash в конце строки, которая начинается на linux16, см. рисунок.

Также данная строка может начинаться с linuxefi, этот параметр характерен для систем с загрузкой в UEFI. Нажмите «ctrl+x» для запуска с этим параметром(init=/bin/bash).

2. Запустите проверку выполнив команду:

/usr/sbin/fsck -ACVfyv

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

Наглядное видео примера проверки диска на ошибки:

Использование загрузочного диска/flash для проверки файловой системы на ошибки.

Загрузившись в режим восстановления операционной системы РЕД ОС с помощью загрузочного диска или съемного накопителя с установленным образом операционной системы РЕД ОС. Выберите пункт: «Решение проблем» -> «Исправить установленную RED OS».

Система перезагрузится в режим восстановления. Введите «2» и нажмите 2 раза Enter. Так вы смонтируете операционную систему в режим «Только для чтения»

setfont cyr-sun16

Потом введите команду:

# сhroot /mnt/sysimage

После этого можете вводить fsck:

# fsck -ACVfyv

Если проверка завершится с такой ошибкой:

[путь_к_файловой_системе] is mounted

Введите:

umount [путь_к_файловой_системе]

И еще раз запустите утилиту fsck:

# fsck -ACVfyv
fsck from util-linux 2.30.2
…

Если система не выявит ошибок, то получится такой вывод:

[путь_к_файловой_системе] clean …

Чтобы выйти из режима восстановления, вы должны смонтировать все разделы, которые были отмонтированы командой umount, с помощью команды mount, нажать сочетание клавиш сtrl+d, а затем ввести команду reboot, которая перезапустит вашу операционную систему.

# reboot

По умолчанию, утилита fsck при проверке будет использовать разделы, указанные в /etc/fstab/, сформированные при установке операционной системы РЕД ОС.

Проверка LVM-разделов с помощью утилиты fsck

Перед проведением проверки необходимо найти устройство и размонтировать его.

Для просмотра всех подключенных устройств и проверки расположения диска выполните команду:

lsblk 

 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
 sda 8:0 0 20G 0 disk 
 ├─sda1 8:1 0 1G 0 part /boot
 └─sda2 8:2 0 19G 0 part 
 ├─ro_redos-root 253:0 0 17G 0 lvm /
 └─ro_redos-swap 253:1 0 2G 0 lvm [SWAP]
 sr0 11:0 1 4,3G 0 rom /run/media/user/redos-MUROM-7.3.1 x86_64

При попытке запустить проверку на смонтированном диске или разделе в консоли появляется предупреждение о том, что невозможно продолжить проверку, так как диск смонтирован.

fsck -nf /dev/ro_redos/root 

 fsck из util-linux 2.37.3
 e2fsck 1.44.6 (5-Mar-2019)
 Warning! /dev/mapper/ro_redos-root is mounted.

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

umount <файловая_система>

Однако попытка выполнить данную процедуру на работающей ОС ни к чему не приведет.

umount /dev/ro_redos/root 

 umount: /: target is busy.

Также проблемой при попытке проверить LVM-разделы может быть и то, что они являются не активными. Для проверки следует использовать команду:

lvscan 

 ACTIVE            '/dev/ro_redos/swap' [2,00 GiB] inherit
 ACTIVE            '/dev/ro_redos/root' [<17,00 GiB] inherit

Для активации раздела служит команда:

vgchange –ay <раздел>

Таким образом, можно сделать вывод, что проверка LVM-разделов через консоль с использованием утилиты fsck невозможна. Но это не значит, что LVM-разделы совсем не подлежат проверке. Существует как минимум два способа, позволяющие провести диагностику LVM-разделов. 

Первым способом является проведение проверки через консоль загрузчика операционной системы GRUB.

А вторым — запуск утилиты fsck в live-сессии системы.

Очевидным плюсом при проверке дисковых пространств, в том числе LVM-разделов, через live-сессию является то, что разделы там по умолчанию являются не смонтированными. Поэтому проверка LVM-раздела будет выполнена с первого раза.

Дата последнего изменения: 18.01.2023

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.

pvck can check LVM metadata, after that consistency is the job of the filesystem. LVM is only about volume management so it doesn’t need to care if the space constituting a particular extent is bad since higher level software catches those issues. LVM metadata only takes up the first (optionally also the last sector) of the physical volume anyways.

If just the first and last sectors of a reasonably large PV (such as you’d see in production) just happen to fail simultaneously, you basically have the sh*ttiest luck in the world since that’s so astronomically unlikely. Otherwise, if the admin knows multiple sectors of the drive have been failing, most people are alright with just filing such things as this under «hard drive failed permanently and needs to be replaced.»

If pvck returns an error, you can check to see if your LVM metadata is backed up in /etc/lvm somewhere. If it is you can do pvcreate specifying the backup copy to --restorefile

Syntax:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

Example:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

If the restore doesn’t work (for example, if the first sector is bad) you can re-do the above, but set --metadatacopies 2 (or you might just go straight to doing that) which will attempt to write the metadata to the first and last sectors on the PV. When pvscan does its thing on boot it will check both places and if it finds metadata it will verify them against a checksum. If the checksum fails on the first sector but succeeds on the last sector you’ll get a non-fatal error message.

Kind of manual and a pain, but then again this is part of the reason why people are excited to get a volume management redux with BTRFS. Most of the time it’s not really that much of an issue for the reasons derobert mentioned, and because the people who absolutely positively need to ensure continuity of data will usually do RAID and have a backup strategy.