После обновления ядра до 3.2.8-std-def-alt1 система (ThinkPad T410 в режиме x86_64) не загружается: mv: cannot stat '/dev/.initramfs/handler-events/md_run.*': No such file or directory initrd: udev: ERROR: event handler failed: md_run initrd: Stage 'udev' failed initrd: This shell remains here for debug puproses. Press Ctrl-D to continue. (initramfs) Если тут нажать Ctrl-D, то ядро уходит в панику и показывает трейс, т.к. убит процесс init. Это вроде логично. Откат пакетов make-initrd make-initrd-devmapper make-initrd-lvm до 0.6.2-alt1 и вызов 'make-initrd -k 3.2.8-std-def-alt1' помогли. Нужную дополнительную информацию и/или файл(ы) образов предоставлю если нужно.
Систему, установленную на USB-HDD тоже не грузит, доходит до определения usb-устройств, сам внешний жесткий определяется, а дальше ничего не происходит - похоже, что sd_mod не подгружается и /dev/sdXX не появляются и всё стопорится на ожидании появления раздела для монтирования.
Да, в общем-то, если в этом шелле набрать lsmod, то лично у меня оно показывает, что вообще никаких модулей не загружено.
приложите пожалуйста результат "make-initrd bug-report", получившийся initrd (если остался) и рабочий initrd (0.6.2-alt1).
Created attachment 5337 [details] make-initrd bug-report
Created attachment 5338 [details] Рабочий образ от 0.6.2
Created attachment 5339 [details] Нерабочий образ от 0.7.0
Не могли бы вы проверить исправление в git: http://git.altlinux.org/people/legion/packages/make-initrd.git ?
У меня случай попроще, нет ни RAID, ни LVM. Просто не может смонтировать root. Поэтому я не удивился, что исправление не помогло. А помогло добавление в /etc/initrd.mk строчки MODULES_PRELOAD += ahci sd_mod ext3 Но в 0.6.2-alt1 и более ранних этого, вроде, не требовалось. Это так и должно быть?
Попробую сегодня вечером проверить. У меня различий по модулям ядра между образами нет, как видно, так что initrd.mk я не менял.
(В ответ на комментарий №8) > А помогло добавление в /etc/initrd.mk строчки > MODULES_PRELOAD += ahci sd_mod ext3 > Но в 0.6.2-alt1 и более ранних этого, вроде, не требовалось. > Это так и должно быть? Разумеется так быть не должно, но это другая проблема нежели проблема с md_run.
(В ответ на комментарий №10) > Разумеется так быть не должно, но это другая проблема нежели проблема с md_run. Завести новый баг? Приложить свои образы сюда?
(В ответ на комментарий №11) > Завести новый баг? Приложить свои образы сюда? Давайте пока сюда.
Created attachment 5344 [details] make-initrd bug-report
Created attachment 5345 [details] образ от 0.6.2
Created attachment 5346 [details] образ от 0.7.0
Симптомы, в общем-то, по ссылке описаны: [ 1.355754] Executing init=/init initrd: Starting sysklog... initrd: Loading modules before udevd... initrd: Starting udevd... initrd: udev: ERROR: Unable to mount root initrd: Stage 'udev' failed Образы с virtualbox'а, но на реальной машине ведёт себя так же точно.
(В ответ на комментарий №7) > Не могли бы вы проверить исправление в git: > http://git.altlinux.org/people/legion/packages/make-initrd.git > ? Проверил, замечательно работает. Удалил пакеты make-initrd-{devmapper,lvm}, убрал raid/lvm из /e/initrd.mk (давно собирался, нужна отпала), перегенерировал образ, загрузился - замечательно работает.
Заодно собрал в сизиф утилиту сравнения образов, называется initrddiff.
(В ответ на комментарий №18) > Заодно собрал в сизиф утилиту сравнения образов, называется initrddiff. Это ваша утилита ?
Created attachment 5355 [details] initrddiff Я немного переделал этот скрипт. Теперь он не требует отдельного создания временных файлов и из-за этого чуть-чуть упростился.
Да. Собрал.
(В ответ на комментарий №21) > Да. Если хотите, можно добавить эту утилиту в make-initrd.
+1
Хочу.
(В ответ на комментарий №16) > Симптомы, в общем-то, по ссылке описаны: > > [ 1.355754] Executing init=/init > initrd: Starting sysklog... > initrd: Loading modules before udevd... > initrd: Starting udevd... > initrd: udev: ERROR: Unable to mount root > initrd: Stage 'udev' failed > > Образы с virtualbox'а, но на реальной машине ведёт себя так же точно. Вы не могли бы добавить параметр rootdelay=3 и когда появится shell посмотреть что в /var/log/initramfs ?
Created attachment 5358 [details] initramfs.gz
(В ответ на комментарий №26) > Created an attachment (id=5358) [details] > initramfs.gz Очень странно всё. По логам и по содержимому образов всё нормально должно быть. В порядке догадки попробуйте добавить в initrd.mk строчку: DISABLE_FEATURES += syslog
Мало что изменилось. Логи пропали, остаток лога выдаётся в консоль. Появилось строчка hrtimer: interrupt took 30947578 ns. А так всё то же самое. Согласен, что странно. Нужные модули есть, вручную прекрасно загружаются, а автоматом не хотят. Но воспроизводится на всех моих сизифах, двух железных и двух виртуальных (обе архитектуры). И, судя по рассылке, не только у меня.
Вы можете подготовить тестовый образ виртуалки для расследования? Если возможно для qemu (если нет, то любой удобный вам).
Ок. Попробую завтра (то есть уже сегодня) соорудить.
(В ответ на комментарий №30) > Ок. Попробую завтра (то есть уже сегодня) соорудить. Протестируйте пожалуйста make-initrd-0.7.2.
Протестировал. Не помогло.
Пока делал образ, кажется, нашёл причину. Помогает удаление udev-initramfs с последующей перегенерацией initrd. Если вдруг зачем-то этот пакет поставить, то проблема снова возникнет.
2legion: предлагаю добавить Obsolete: initrddiff
Да пока маленькое и все видевшие точно читали эту багу -- можно сделать вид, что не было. :)
Ну мало ли кто мог установить и не читать багу.
0.7.2 работает, udev-initramfs не установлен
Ещё говорят про разницу при смонтированном в чруте /sys: http://lists.altlinux.org/pipermail/sisyphus/2012-March/356983.html
(In reply to comment #33) > Пока делал образ, кажется, нашёл причину. > Помогает удаление udev-initramfs с последующей перегенерацией initrd. Если > вдруг зачем-то этот пакет поставить, то проблема снова возникнет. make-initrd-0.7.2-alt1 udev-initramfs-150-alt8 kernel-image-std-def-3.2.9-alt1.1 Виснет при загрузке на: initrd: Loading modules before udevd... initrd: Starting udevd... Совет про удаление udev-initramfs не очень понятен - там много всего сносится: # apt-get remove --purge udev-initramfs Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: bootsplash* design-bootsplash-office-server* mkinitrd* udev-initramfs* 0 upgraded, 0 newly installed, 4 removed and 11 not upgraded. Что делать-то?
Сносить. Вместо bootsplash, если очень хочется, сейчас используется plymouth. mkinitrd не неужен, make-initrd, по сути, его замена.
(In reply to comment #40) > Сносить. Вместо bootsplash, если очень хочется, сейчас используется plymouth. > mkinitrd не неужен, make-initrd, по сути, его замена. Ясно, попробую завтра, как до сервера доберусь. Плимут мне там не нужен...
(В ответ на комментарий №34) > 2legion: предлагаю добавить Obsolete: initrddiff Хорошо. Я не поставил его с самого начала потому что немного переименовал утилиту.
(In reply to comment #40) > Сносить. Вместо bootsplash, если очень хочется, сейчас используется plymouth. > mkinitrd не неужен, make-initrd, по сути, его замена. Снес, перегенерировал initrd, теперь ядро нормально грузится. Всем спасибо за помощь!
Нужно будет провести расследование, что так фатально изменилось в udev-initramfs.
(В ответ на комментарий №44) > Нужно будет провести расследование, что так фатально изменилось в > udev-initramfs. Учитывая, что версия у него 150 (когда у самого udev 172) и пакету более чем 1,5 года, то вряд ли в нём что-то изменилось :) Но странно, что 0.6.2 с ним работает, а 0.7.x нет.
Мне не помогло... Вычистил и udev-initramfs, и mkinitrd.* и *initramfs* с компа - бесполезно. И перегенерил образы для новых ядер... Все компы (4 штуки) на ядре 3.2.9-un-def-alt2 и 3.2.9-std-def-alt1.1 В общем, для меня make-initrd нерабочий больше, чем полностью. Версия 0.6.2-alt1 для этих ядер тоже перестала генерить правильные образы... Старый mkinitrd на всех (кроме raid) делает рабочие образы.
Сейчас проверил на 2.6.9-std-def-alt1.1 на софт-raid: 1) make-initrd создает нерабочий initrd, в котором есть /dev/mdXpY. То есть самовольно объединяет целиком винты в один рейд, из-за чего ядро не может понять, что же делать с ним и какая там файловая система; 2) mkinitrd создает рабочий образ с файлами /dev/mdZ. То есть каждый раздел на одном винте объединяется с аналогичным разделом на другом винте в отдельный рейд. Ядро спокойно разбирается в типе файловой системы каждого рейда. При этом есть файл /dev/mdadm.conf, который описывает создание рейдов. Что это за самовольность make-initrd?
Специально для тестирования systemd в различных конфигурациях держу несколько виртуалок. Перестала грузится виртуалка, где корень на lvm. Ошибка похожа на mv: cannot stat '/dev/.initramfs/handler-events/lvm.*': No such file or directory Ощущение, что events создаются в udev-event, а пытаются удалиться из handler-events.
(В ответ на комментарий №48) > Перестала грузится виртуалка, где корень на lvm. > Ошибка похожа на > mv: cannot stat '/dev/.initramfs/handler-events/lvm.*': No such file or > directory Аналогично было и с md в версии 0.7.0-alt1. У меня корень на софт-raid1 под md.
Так. Господа, открывайте новые баги т.к. тут уже невозможно понять, что у кого не работает. Описанная ошибка в md_run была исправлена в 0.7.2.
(В ответ на комментарий №46) > В общем, для меня make-initrd нерабочий больше, чем полностью. Версия > 0.6.2-alt1 для этих ядер тоже перестала генерить правильные образы... Это уже не к make-initrd, а к kernel/udev. На старых ядрах make-initrd работает?
(В ответ на комментарий №47) > Сейчас проверил на 2.6.9-std-def-alt1.1 на софт-raid: > 1) make-initrd создает нерабочий initrd, в котором есть /dev/mdXpY. То есть > самовольно объединяет целиком винты в один рейд, из-за чего ядро не может > понять, что же делать с ним и какая там файловая система; Самовольно make-initrd ничего не делает. > При этом есть файл /dev/mdadm.conf, который описывает создание рейдов. mkinitrd активизирует рейд через ядро. Это же делает features/raid.
УМВР. Не надо смешивать различные проблемы.
(В ответ на комментарий №48) > Ощущение, что events создаются в udev-event, а пытаются удалиться из > handler-events. Какую версию вы проверяете ?
Перенёс свою проблему в #27061
