[Sysadmins] I: Обновления 5.1 -> p7: Встреченные проблемы

[Aleksey Avdeev <solo@solin.spb.ru>]

[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]

Приветствую.

  При обновлении сервера с 5.1 до текущего p7, наткнулся на ряд
достаточно неприятных проблем.

  Особенности обновляемой системы:

1. Активно используется LVM (когда-то был EVMS, но от него избавился
ранее) поверх Soft-RAID (используется автодетект), корень на и
вынесенный /boot на RAID1:

а) /, reiserfs - на RAID1;

б) /boot, ext2 - на RAID1;

в) все остальное (/usr, /var, /home и пр.) -- на LVM поверх RAID5
(некоторые некритичные части -- на LVM поверх RAID0).

2. Используется виртуализация -- KVM под libvirt.

3. Используется sysvinit (и нет планов перехода на systemd).

4. Архитектура x86_64 (AMD).

  Встреченные проблемы, в порядке столкновения с оными:

1. После обновления lvm2 и перехода на kmod и make-initrd
(0.8.6-alt1.M70P.2, был установлены доп. пакеты make-initrd-devmapper,
make-initrd-lvm и make-initrd-mdadm) -- получил проблемы с загрузкой:

а) При старом ядре 3.3.5-std-def-alt1 (и соответствующим ему старом
initrd) -- перестали подниматься LVM группы томов. (Это было ожидаемо,
эксперименты по ручному подъёму LVM не привели к успеху.)

б) При использовании свежеустановленного ядра
(3.14.58-std-def-alt0.M70P.1) и свежесформированного (с помощью
make-initrd) initrd -- не было найдено корневое устройство. Раскопки
показали что скорее всего в среде старого ядра (3.3.5-std-def-alt1) не
отработал автодетект. В initrd отсутсвовали:

б.I) модули необходимые для монтирования корня (raid1, reiserfs);

б.II) скрипты, привносимые фичами raid, mdadm и lvm.

  Для исправления ситуации пришлось использовать загрузку с LiveCD
(altlinux-p7-rescue-20151212-x86_64.iso) для генерации рабочего initrd
через chroot в штатный корень (/dev, /sys и /proc смонтированы через
mount --bind) и ручной настройкой /etc/initrd.mk.

2. В процессе генерации initrd, оказалось что в моём случаи комбинация
фич mdadm и raid отрабатывает не корректно. Оказалось что у меня скрипт
/lib/initrd/trouble/050-mdstart (см.
<http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/initrd/trouble/050-mdstart;h=b56114bed05a8b077b0f2a669eb025d7480aa6ef;hb=refs/tags/0.8.6-alt1.M70P.2>),
требующий наличия файлов
/sys/block/md*/md/array_state (код возвращает ошибку при их отсутсвии),
отрабатывает до скрипта /lib/initrd/handlers/050-md_run (см.
<http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/raid/data/lib/initrd/handlers/050-md_run;h=52c648069e3c2e89500e7f262306607e4910248c;hb=refs/tags/0.8.6-alt1.M70P.2>),
выполняющим фактический вызов команды md_run. А у меня, каталоги
sys/block/md* появляются только после выполнения md_run... Вылечил
отключением фичи mdadm (и удалением пакета make-initrd-mdadm).

  Текущий порядок вызова скриптов обусловлен тем, что в функции run()
скрипта /lib/initrd/modules/080-loop (см.
<http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/lib/initrd/modules/080-loop;h=313f2396eed15694cc85a97815fd878ad4be5024;hb=refs/tags/0.8.6-alt1.M70P.2>)
содержимое /lib/initrd/trouble/ выполняется раньше, чем содержимое
/lib/initrd/handlers/.

3. После обновления udev до 201-alt1.M70P.5, udevd отказывался из-за
стартовать невозможности создать управляющий сокет в каталоге /run/udev
-- не проходит тест наличия каталога /run... Решил симлинком
/run -> /var/run (не знаю на сколько оно правильно).

4. Похоже что после создания симлинка /run -> /var/run каталог /var/run
начал чиститься... Это привело к невозможности старта dbus
(/etc/init.d/messagebus) при старте системы, из-за отсутствия
/var/run/dbus. Вижу следующие варианты лечения:

4.а) Тупой и временный -- выполнять mkdir /var/run/dbus при старте
сервера, с последующим стартом messagebus. (Для libvit`а этого достаточно.)

4.б) Добавить создание /var/run/dbus и /var/run/dbus/users (с
правильными правами) в /etc/init.d/messagebus.

4.в) Создать /lib/tmpfiles.d/dbus.conf, и использовать
/bin/systemd-tmpfiles для создания описанного во всех tmpfiles.d. Как
минимум данный вариант потребует выделения systemd-tmpfiles в подпакет и
создания init скрипта для него.

PS: Это всё первые впечатления... Разгрёб ещё не всё.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]