udev-237-alt2.M80P.2 несовместим с системами на ядрах 2.6.32-ovz-el и LVM. После обновления udev до 237-alt2.M80P.2 LVM2 перестаёт видеть диски: # pvs -v Wiping internal VG cache Wiping cache of LVM-capable devices Failed to enumerate udev device list. # strace -f pvs -v 2>&1 |less ... open("/sys/class/block/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 5 fstat(5, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 getdents(5, /* 23 entries */, 32768) = 616 open("/", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 6 openat(6, "sys", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 7 fstat(7, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 close(6) = 0 openat(7, "class", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 6 fstat(6, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 close(7) = 0 openat(6, "block", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 7 fstat(7, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 close(6) = 0 openat(7, "sda", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = -1 ELOOP (Слишком много уровней символьных ссылок) close(7) = 0 .... То же, для предыдущего работающего 233-alt0.M80P.4: ... open("/sys/class/block/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 5 fstat(5, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 getdents(5, /* 30 entries */, 32768) = 784 readlinkat(AT_FDCWD, "/sys/class/block/sda", "../../devices/pci0000:00/0000:00"..., 99) = 73 ....
А это не тоже самое? Только для P8. https://bugzilla.altlinux.org/show_bug.cgi?id=34433
> А это не тоже самое? Только для P8. > https://bugzilla.altlinux.org/show_bug.cgi?id=34433 Нет, это своё. Там проблема в GLibc - и неверно создавались файлы устройств. Здесь файлы устройств нормальные, перестал отрабатывать только выбор их в LVM2. И с MD-RAID, в отличии от #34433, всё нормально. Что сейчас делается в Sisyphus - не скажу. У меня есть рабочая система на 3.2.0-ovz-el-alt160 / glibc-2.26.0.124.98f244e-alt1 /udev-235-alt3 - по состоянию на январь и закрытие #34433, но более свежее в тестовых виртуальных серверах в рабочем состоянии получить пока не удаётся.
Вот приехали... Я откатил udev и всё, что хотело новый udev, до 233. В том числе важно не забыть libudev1. После перезагрузки система загрузилась корректно.
В принципе, достаточно откатывать (или ставить на hold) только libudev1.
Надо или перевешивать на ядро 2.6.32 или закрывать как wontfix. К сожалению, конфигурацию с ядром 2.6.32 в p8 у нас никто не тестирует, и врятли будет.
В p8 нормально встаёт 2.6.32-alt162 из Сизифа: bug 34526. то есть apt-repo rm all apt-repo add sisyphus apt-get update update-kernel apt-repo rm all apt-repo add p8 Как с ним? Сизифное, правда, надо тоже обновить. Потом снова проверять переносимость, если оно обновится.
Я сделал upgrade на машине, поставил ядро из Сизифа. После перезагрузки 1. новое ядро не находит root-раздел (указанный через UUID) 2. старое ядро не видит сетевые карты (не грузит модули для них) — это, видимо, udev.
(В ответ на комментарий №7) > Я сделал upgrade на машине, поставил ядро из Сизифа. > После перезагрузки > 1. новое ядро не находит root-раздел (указанный через UUID) > 2. старое ядро не видит сетевые карты (не грузит модули для них) — это, видимо, > udev. Проблема в том, что udev не загрузил модули для sata-контроллеров и сетевых карт. Откат всего *udev* до 233 решил проблему. Странно, что на других аналогичных системах проблемы с udev, кроме LVM2, не наблюдалось.
*** Bug 35248 has been marked as a duplicate of this bug. ***
Продукт более не поддерживается. Если актуально, то необходимо перевешать на новый поддерживаемый репозиторий (p10, p11, Sisyphus).
