Привет, Всем!
Новые вводные.
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
используют и планов по отказу не озвучивали.
Я сначала тоже так решил, но потом подумал, что он же серьёзный человек,
и не будет приколяться над страждущими ;)
--
Васюк Максим
_______________________________________________
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins
