Приветствую. При обновлении сервера с 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 (см. ), требующий наличия файлов /sys/block/md*/md/array_state (код возвращает ошибку при их отсутсвии), отрабатывает до скрипта /lib/initrd/handlers/050-md_run (см. ), выполняющим фактический вызов команды md_run. А у меня, каталоги sys/block/md* появляются только после выполнения md_run... Вылечил отключением фичи mdadm (и удалением пакета make-initrd-mdadm). Текущий порядок вызова скриптов обусловлен тем, что в функции run() скрипта /lib/initrd/modules/080-loop (см. ) содержимое /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: Это всё первые впечатления... Разгрёб ещё не всё. -- С уважением. Алексей.