[Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Васюк Максим]

Привет, Всем!

Branch: p8

Корень и boot лежат на одном томе ext4 LVM RAID1
RAID организован средствами LVM.

При выключении ругается на то, что не может размонтировать корень, т.к. 
с него запущен процесс LVM. Но это полбеды. Интернеты пишут, что это 
почти штатная ситуация. Вроде как на некоторых системах можно нырнуть 
обратно в initrd и от туда уже нормально размонтироваться. Как у нас 
обстоят дела в этом моменте?

И после одной, другой перезагрузке загрузка останавливается:
Checking root filesystem
/dev/mapper/vg00-root_sys_rimage_0 is in use.
e2fsck: Cannot continue, aborting.

Жму Ctrl-D,  если опять останавливается, жму опять Ctrl-D, с одного, 
двух, трёх раз загружается нормально.

Здесь понятно, что e2fsck хочет заюзать один из зеркал рейда, но райд 
уже активен и не даёт его использовать.

Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs, но 
боюсь могут возникнуть проблемы в rescue live cd, там что-то btrfs-ом и 
не пахнет.

Буду благодарен за любую информацию.

--
Васюк Максим

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Sergey]

On Tuesday 04 December 2018, Васюк Максим wrote:

> Здесь понятно, что e2fsck хочет заюзать один из зеркал рейда, но райд 
> уже активен и не даёт его использовать.

С чего бы e2fsck знал про RAID? Он просто должен проверить устройство
с ФС, и всё. Нет, причина в чём-то другом. Но в чём - не скажу. У меня
живёт конфигурация вида (лишнее убрал)

Filesystem             Size  Used Avail Use% Mounted on

/dev/sda1              182M   81M   89M  48% /boot
/dev/mapper/main-root  3,8G  659M  3,0G  18% /
/dev/mapper/main-home  3,8G  3,0G  610M  84% /home
/dev/mapper/main-usr   3,8G  902M  2,7G  25% /usr
/dev/mapper/main-var   3,8G  2,1G  1,6G  58% /var
/dev/mapper/main-www   7,6G  684M  6,5G  10% /var/www
/dev/mapper/main-rrd   385G   91G  275G  25% /var/lib/collectd2

тут mdadm/RAID10 c LVM поверх RAID. Везде ext4 и всё, вроде как, нормально
чекается.

> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs, но 
> боюсь могут возникнуть проблемы в rescue live cd, там что-то btrfs-ом
> и не пахнет.

btrfs в rescue не самая главная проблема - добавить не сложно, если на
самом деле отсутствует. Вот RAID средствами btrfs - это чёрный ящик. 
Хотя и пишут, что некоторые варианты уже считаются стабильными. Плюс не
интересовался наработанной практикой исправления порушенного btrfs raid.

-- 
С уважением, Сергей.

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Michael Shigorin]

On Tue, Dec 04, 2018 at 02:38:24PM +0700, Васюк Максим wrote:
> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs

Насколько понимаю, если данные не нужны, вполне себе вариант...

> но боюсь могут возникнуть проблемы в rescue live cd, там что-то
> btrfs-ом и не пахнет.

В http://altlinux.org/rescue есть и btrfs-progs, если что.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Васюк Максим]

04.12.2018 17:38, Sergey пишет:
> On Tuesday 04 December 2018, Васюк Максим wrote:
> 
>> Здесь понятно, что e2fsck хочет заюзать один из зеркал рейда, но райд
>> уже активен и не даёт его использовать.
> 
> С чего бы e2fsck знал про RAID? Он просто должен проверить устройство
> с ФС, и всё. Нет, причина в чём-то другом. Но в чём - не скажу. У меня
> живёт конфигурация вида (лишнее убрал)
Выхлоп:
Checking root filesystem
/dev/mapper/vg00-root_sys_rimage_0 is in use.
e2fsck: Cannot continue, aborting.

...is in use... разве это не говорит о том, что устройство кем-то 
используется?
Напоминаю, что на текущей машине RAID1 организован средствами LVM, без 
использования md.
К моменту начала работы e2fsck RAID уже собран, и e2fsck по идее должна 
проверять только его, а зеркала не трогать, потому как, по идее, за 
целостностью следит сам LVM.

Так наверно понятней будет:
# lvs -a -o +devices
   LV                  VG   Attr       LSize  Pool Origin Data%  Meta% 
Move Log Cpy%Sync Convert Devices
   root_sys            vg00 rwi-aor--- 10,00g         100,00 
root_sys_rimage_0(0),root_sys_rimage_1(0)
   [root_sys_rimage_0] vg00 iwi-aor--- 10,00g 
/dev/sda2(1)
   [root_sys_rimage_1] vg00 iwi-aor--- 10,00g 
/dev/sdb2(2562)
   [root_sys_rmeta_0]  vg00 ewi-aor---  4,00m 
/dev/sda2(0)
   [root_sys_rmeta_1]  vg00 ewi-aor---  4,00m 
/dev/sdb2(2561)
   test                vg00 -wi-a----- 20,00g 
/dev/sdb2(5122)

RAID1 это vg00/root_sys на нём корень и он использует скрытые тома 
vg00/root_sys_rmeta_0 и vg00/root_sys_rmeta_1, которую в свою очередь 
уже используют непосредственно разделы на разных дисках. Этот слоённый 
пирог LVM сам организовал и если пользоваться просто lvs без -а, то он 
их не показывает.
Ну и df:
Файловая система          Размер Использовано  Дост Использовано% 
/dev/mapper/vg00-root_sys   9,8G         1,9G  7,4G           21% /

В итоге boot не надо выносить отдельно куда-то. Grub грузит initrd прямо 
с LVM RAID1 организованного только одним LVM.

Возможно из-за того, что e2fsck видит на LVM зеркалах систему, пытается 
её почекать, а на md зеркалах она её не видит и соответственно обруливает.
И нет бы сказал, что-то типа того: "Не могу работать, устройство 
занято!" и пошел дальше грузиться, но останавливает загрузку.

> Filesystem             Size  Used Avail Use% Mounted on
> 
> /dev/sda1              182M   81M   89M  48% /boot
> /dev/mapper/main-root  3,8G  659M  3,0G  18% /
> /dev/mapper/main-home  3,8G  3,0G  610M  84% /home
> /dev/mapper/main-usr   3,8G  902M  2,7G  25% /usr
> /dev/mapper/main-var   3,8G  2,1G  1,6G  58% /var
> /dev/mapper/main-www   7,6G  684M  6,5G  10% /var/www
> /dev/mapper/main-rrd   385G   91G  275G  25% /var/lib/collectd2
> 
> тут mdadm/RAID10 c LVM поверх RAID. Везде ext4 и всё, вроде как, нормально
> чекается.
На другой машине у меня организация загрузки с аналогичная Вашей, только 
корень лежит на md разделе. На новой машине хочу избавится от 
дополнительного слоя md.

>> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs, но
>> боюсь могут возникнуть проблемы в rescue live cd, там что-то btrfs-ом
>> и не пахнет.
> 
> btrfs в rescue не самая главная проблема - добавить не сложно, если на
> самом деле отсутствует. Вот RAID средствами btrfs - это чёрный ящик.
> Хотя и пишут, что некоторые варианты уже считаются стабильными. Плюс не
> интересовался наработанной практикой исправления порушенного btrfs raid.
Хотел использовать btrfs поверх LVM и испльзовать её просто как замену 
ext4, без дополнительных её возможностей по организации массивов и 
работе с томами. Наш установщик на неё почему-то ставиться не захотел, 
хотя гуй видел том и давал его выбрать, глянул из rescue, поддержки её 
там не увидел, подумал нам ещё рановато, раз не добавили. И во избежания 
проблем во время возможных отказов, решил не выпендриваться.

04.12.2018 17:58, Michael Shigorin пишет:> On Tue, Dec 04, 2018 at 
02:38:24PM +0700, Васюк Максим wrote:
>> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs
>
> Насколько понимаю, если данные не нужны, вполне себе вариант...
С данными всё в порядке, система то в итоге грузится и копию образа 
системы через снапшот я уже сделал. На машину система только накатилась, 
KVM и LXC ещё не начал настраивать, т.к. вышеописанный вопрос надо закрыть.

> В http://altlinux.org/rescue есть и btrfs-progs, если что.
>
У меня alt-p8-server-20180913-x86_64.iso я с этого диска грузился в 
rescue. И только сейчас докумекал, что Вы говорите про отдельный образ 
rescue. Просто раньше у меня не было вопросов, я просто брал любой образ 
с текущей ветки и грузился с него в rescue и отдельным образом для 
возобновления работы машины не пользовался, как-то хватало. Будем знать, 
спасибо!

-- 
Васюк Максим

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Sergey]

On Wednesday 05 December 2018, Васюк Максим wrote:

> Возможно из-за того, что e2fsck видит на LVM зеркалах систему, 

e2fsck ничего не видит. Он просто чекает то, что ему кто-то говорит
чекать. Вот почему ему скармливают /dev/mapper/vg00-root_sys_rimage_0,
это не знаю.

> И нет бы сказал, что-то типа того: "Не могу работать, устройство 
> занято!" и пошел дальше грузиться, но останавливает загрузку.

Если считается, что там повреждение, лучше остановиться.

> > тут mdadm/RAID10 c LVM поверх RAID. Везде ext4 и всё, вроде как,
> > нормально чекается.

> На другой машине у меня организация загрузки с аналогичная Вашей,
> только корень лежит на md разделе. На новой машине хочу избавится
> от дополнительного слоя md.

Я бы от LVM избавился, но у нас инсталлятор не умеет md на разделы
разбивать. ;-)

> >> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs
> >
> > Насколько понимаю, если данные не нужны, вполне себе вариант...

> С данными всё в порядке,

Михаил, как мне показалось, имеет ввиду предполагаемую недостаточную
обкатку btrfs и вероятные будущие проблемы. Но, вроде как, в SuSe 
используют и планов по отказу не озвучивали.

> У меня alt-p8-server-20180913-x86_64.iso я с этого диска грузился 
> в rescue. И только сейчас докумекал, что Вы говорите про отдельный
> образ rescue.

Вообще-то я думал, что это одно и то же. :-) Но отдельный чаще обновляется.

-- 
С уважением, Сергей.

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Васюк Максим]

Привет, Всем!

Новые вводные.

05.12.2018 14:42, Sergey пишет:
> On Wednesday 05 December 2018, Васюк Максим wrote:
> 
>> Возможно из-за того, что e2fsck видит на LVM зеркалах систему,
> 
> e2fsck ничего не видит. Он просто чекает то, что ему кто-то говорит
> чекать. Вот почему ему скармливают /dev/mapper/vg00-root_sys_rimage_0,
> это не знаю.
> 
>> И нет бы сказал, что-то типа того: "Не могу работать, устройство
>> занято!" и пошел дальше грузиться, но останавливает загрузку.

Под пристальным внимаем обнаружилось, следующее:
GRUB загрузил initrd, процессы запускаются и доходит дело до следующего 
момента:
Starting system-udevd service: DONE
Populating /dev: DONE
Activaiting swap partition: DONE
Setting hostname: DONE
Checking root filesystem: DONE
/dev/mapper/vg00-root_sys_rimage_0 in in use.
e2sfck: Cannont continue, aborting.
				FAILED

Жму Ctrl-D, идёт перезагрузка и может остановится или с такой же 
строчкой, или немного с другой:
/dev/mapper/vg00-root_sys_rimage_0 in in use.

Опять жму Ctrl-D, перезагрузка и так несколько раз, пока не попадёт на:
/dev/mapper/vg00-root_sys
и тогда загрузка проходит нормально:
Remounting root filesystem in read/write mode: DONE
и дальше по списку.

Получается, при неудачных загрузках, initrd перед монтированием выбирает 
не LVM раздел собранный из разделов LVM зеркал, а как раз одно из LVM 
зеркал, т.к. эти устройства уже используются, e2fsck не может 
примонтировать файловую систему для проверки, а т.к. думает, что там 
корень, останавливает загрузку.

Полез в  fstab:
# cat /etc/fstab
UUID=57dc8810-3432-4477-b4ee-294642884ec7  /  ext4    relatime 1 1

Глянул на UUID разделов и оказалось, что они у всех трёх разделов 
одинаковые:
# blkid
/dev/mapper/vg00-root_sys_rimage_0: 
UUID="57dc8810-3432-4477-b4ee-294642884ec7" TYPE="ext4"
/dev/mapper/vg00-root_sys_rimage_1: 
UUID="57dc8810-3432-4477-b4ee-294642884ec7" TYPE="ext4"
/dev/mapper/vg00-root_sys: UUID="57dc8810-3432-4477-b4ee-294642884ec7" 
TYPE="ext4"

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

Кусок из grub.cfg:
...
menuentry 'ALT starter kit' --class gnu-linux --class gnu --class os 
--unrestricted $menuentry_id_option 
'gnulinux-simple-57dc8810-3432-4477-b4ee-294642884ec7' {
...
   search --no-floppy --fs-uuid --set=root 
57dc8810-3432-4477-b4ee-294642884ec7
...
linux<->/boot/vmlinuz root=/dev/mapper/vg00-root_sys ro panic=30 splash
echo    'Loading initial ramdisk ...'
initrd  /initrd.img
...

Посмотрел на другой машине, там где организован MD RAID1. Оказалось, что 
у зеркал одинаковые uuid, а вот у собранного раздела из этих зеркал другой:

# df
...
/dev/md1                         28G         2,7G   24G           11% /
...

# cat /proc/mdstat
...
md1 : active raid1 sda3[0] sdb3[1]
...

# blkid
...
/dev/sda3: UUID="c2029de0-13c6-1261-5cc0-45fc1eca55fc" 
TYPE="linux_raid_member"
...
/dev/sdb3: UUID="c2029de0-13c6-1261-5cc0-45fc1eca55fc" 
TYPE="linux_raid_member"
...
/dev/md1: UUID="a210197a-0b6f-4626-8d72-a2cfd5f73d38" TYPE="ext4"
...

# cat /etc/fstab
...
UUID=a210197a-0b6f-4626-8d72-a2cfd5f73d38 / ext4 relatime 1 1
...

Кусок из grub.cfg:
menuentry 'ALT Linux starter kit' --class gnu-linux --class gnu --class
os $menuentry_id_option 
'gnulinux-simple-a210197a-0b6f-4626-8d72-a2cfd5f73d38' {
...
         set root='mduuid/a427249a0b7032ac5cc045fc1eca55fc'
         if [ x$feature_platform_search_hint = xy ]; then
           search --no-floppy --fs-uuid --set=root 
--hint='mduuid/a427249a0b7032ac5cc045fc1eca55fc' 
7d127096-dbff-4453-b8fc-70a350ee6afe
...
         linux   /vmlinuz root=UUID=a210197a-0b6f-4626-8d72-a2cfd5f73d38 
ro panic=30 splash
         echo    'Loading initial ramdisk ...'
         initrd  /initrd.img
...

Получается что md с этой проблемой знаком, а lvm нет.

На проблемной машине делаю:
#UUID=57dc8810-3432-4477-b4ee-294642884ec7 / ext4 relatime 1 1
/dev/mapper/vg00-root_sys                  / ext4 relatime 1 1

И всё начинает загружаться как надо.

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

Т.к. в такой конфигурации имя устройства, на котором лежит корень, не 
меняется при замене, добавлении и пр. жестких дисков, в теории можно 
оставить так.

>>>> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs
>>>
>>> Насколько понимаю, если данные не нужны, вполне себе вариант...
> 
>> С данными всё в порядке,
> 
> Михаил, как мне показалось, имеет ввиду предполагаемую недостаточную
> обкатку btrfs и вероятные будущие проблемы. Но, вроде как, в SuSe
> используют и планов по отказу не озвучивали.
Я сначала тоже так решил, но потом подумал, что он же серьёзный человек, 
и не будет приколяться над страждущими ;)
-- 
Васюк Максим

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Michael Shigorin]

On Wed, Dec 05, 2018 at 01:16:57PM +0700, Васюк Максим wrote:
> > В http://altlinux.org/rescue есть и btrfs-progs, если что.
> У меня alt-p8-server-20180913-x86_64.iso я с этого диска
> грузился в rescue. И только сейчас докумекал, что Вы говорите
> про отдельный образ rescue. Просто раньше у меня не было
> вопросов, я просто брал любой образ с текущей ветки и грузился
> с него в rescue и отдельным образом для возобновления работы
> машины не пользовался, как-то хватало. Будем знать, спасибо!

На здоровье; чего не хватит -- пишите нам с antohami@.

Есть давняя задумка про графический rescue, на данный момент
она вылилась в добавление gparted во все графические livecd
из регулярок/стартеркитов.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Michael Shigorin]

On Wed, Dec 05, 2018 at 11:42:29AM +0400, Sergey wrote:
> Я бы от LVM избавился, но у нас инсталлятор не умеет md на
> разделы разбивать. ;-)

Кстати, стоит повесить на alterator-vm, если я ещё не.
Порой так делаю, вынеся корень или /boot на отдельную флэшку --
куда удобней разбивать массив, чем делать кучку зеркал/десяток.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Michael Shigorin]

On Fri, Dec 07, 2018 at 06:34:08PM +0700, Васюк Максим wrote:
> >>>> Один вариант вижу, не использовать ext4. Смотрел в сторону btrfs
> >>> Насколько понимаю, если данные не нужны, вполне себе вариант...
> >> С данными всё в порядке,
> > Михаил, как мне показалось, имеет ввиду предполагаемую
> > недостаточную обкатку btrfs и вероятные будущие проблемы.
> Я сначала тоже так решил, но потом подумал, что он же серьёзный
> человек, и не будет приколяться над страждущими ;)

Прикалываться и впрямь не над чем, но бэкап средствами ФС
я бы за бэкап не считал, если нет автономного от неё
(т.е. на другом физическом носителе и на обкатанной ФС).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] e2fsck не может провести проверка при загрузке корневой ФС на LVM RAID1

[Anton Gorlov]

Полностью поддерживаю. Бекап должен быть в сторонке...

07.12.2018 21:42, Michael Shigorin пишет:
> Прикалываться и впрямь не над чем, но бэкап средствами ФС
> я бы за бэкап не считал, если нет автономного от неё
> (т.е. на другом физическом носителе и на обкатанной ФС).