LINUX.ORG.RU

Gentoo Waiting for uevents to be processed


0

0

Решил написать в этой ветке форума, т.к показалось наиболее подходяще вопорсу. После недавней пересборки ядра (точнее обновления до последней версии доступной в портах 2.6.32-r1 (gentoo-sources)) загрузка стала останавливаться на этапе запуска udev, точнее он стартует, дальше процесс останавливается на этапе «waiting for uevents to be processed».

Ядро пересобирал т.к. появилась wifi карточка dwa-520 (ath5k), поэтому подумал что косяк в исходниках данной версии ядра, поэтому решил подправить конфиг старого ядра (2.6.31-gentoo-r4) включил собственно только поддержку этой карточки, перезагружаюсь, опять двадцать пять, теперь та же трабла и со старым ядром, с теми исходниками, в которых я был уверен. Вернул забекапленое ядро 2.6.31-r4, загрузился, реши пееставиь udev (1.46-r1), затем решил грузиться с новым ядром, оно загрузилось, правда все же на выше описанном этапе загрузки немного задержалось.

Настроил я карточку, потестил, затем опят ребутнулся, с этим же ядром, опять стало подвисать, при чем капитально, вернулся к забекапленому ядру (2.6.31-r4) теперь и там таже фигня. При чем индикатор обращения к винту горит почти постоянно. Потом опять ребутился с новым ядром и решил ему дать время, мож проведет операции и все будет пучком. Прождав с минут 40, видя эту не суразную картину, решил загрузиться с еще более старого ядра (2.6.26-r6 вроде или r4) при загрузке пишет что неможет найти часть устройств /dev/tty* кроме tty1, смотрю каталог /dev, там все почти девственно чисто, т.е пусто, кроме tty1 и еще чати псевдо устройств.

Вопрос что делать и почему вдруг после апдейта ядра система похоже стала пересоздавать ноды в каталоге dev.

Первый раз новое ядро собиралось gcc-4.3.4 и glibc 2.8, точнее версию сча не скажу, затем было произведено обновление до gcc-4.4.1 и glbc-2.10-r1 примерно, так что с этим вроде не связано.

Конфиг сверял с сохраненным в /etk/kernels 2.6.31-gentoo-r4 diff`ом с версией конфига 32 различий нет, так что х.з.

Да ядро собирал одной из послених версий genkernel, правда сча не скажу какой, маштна стоит с новым ядром и проводит перегенерация каталога dev, может в нем какойто косяк, что он включает какието опции при сборке ядра, которые не указаны в конфиге.

Не посчитайте за идиота при виде такого объема текста, в описании темы, но я уже не знаю что делать, не хочется целиком переставлять систему.

★★★★★

Примерно то же было с месяц назад. Но в моём случае загрузка продолжалась через минуту-две.

Не помню, что именно было виновато, но проблема исчезла после обновления всех конфигов в /etc (скорее всего в /etc/init.d/ или /etc/conf.d/) и удаления всех ненужных пунктов из загрузки через rc-config. Возможно, дело было в sysfs.

question4 ★★★★★
()

У меня такой же эффект начался после того, как я установил плату тв-тюнера. Собственно загрузка продолжается секунд через 30, поэтому особо не парит. Но разобраться хотелось бы.

PS: у меня ArchLinux

m0rph ★★★★★
()

Я уже собственно даже пересобрал все системные пакеты:

emerge -ae system

и все равно полный косяк, если положить свеже собранное ядро на другой машине (с этим же конфигом ядра), то первая загрузка происходит нормально, но пи повторной опять происходит затык.

kostik87 ★★★★★
() автор топика

После долгих попыток разобраться что к чему, на отдельный раздел была произведена чистая установка из stage 3, произведено обновление до текушего среза portage от 15 января, сборка ядра с моим конфигом, с которым происходит остановка на этапе загрузки и произведено несколько раз перезагрузка, система нормально загружалась и работала.

Затем было произведено обновление системы: emerge -auvDN system

при этом udev обновися с версии 141-r1, версия из stage 3 последнего, до 146-r1? после чего стала наблюдаться выше описанная ситуация, при возврате к старой версии (141-r1) нормально происходит только первая загрузка, после чего опять происходит затык на этапе запуска udev.

Но при обновлении также были обновлены и все остальные системные пакеты, (glibc, perl и т.д.), поэтому была произведена установка заново, ядро было взято с minimal-cd, скопированы модули ядра и образ initrd, загрузка прошла нормально, затем были обновлены: e2fsprogs и e2fsprogs-libs, для разрешения зависимостей и обновлена udev. Опять появилась эта же проблема, правда с ядром с minimal-cd задержка происходит примерно на минуту, а потом нормально загружается, а с моим ядром просто останавливается на этом этапе и шерстит винт. Правда версия ядро с минималсв 2.6.30-gentoo-r8, а мое 32-gentoo-r1. Так что какойто косяк в этой версии udev, она что то копитально ломает и глючит.

kostik87 ★★★★★
() автор топика
Ответ на: комментарий от FractalL

Я ее уже с 31 ядра выкинул. Только х.з. как теперь систему в работоспособное состояние привести, возврат на 31 ядро и даунгрэйд udev позволяют нормально загрузиться только один раз. Видимо придется переставлять систему и не обновлять udev, остаться на 141-r1 версии

kostik87 ★★★★★
() автор топика

на федоре такое же было.

Deleted
()
Ответ на: комментарий от m0rph

У меня такой же эффект начался после того, как я установил плату тв-тюнера.

У меня была аналогичная ситуация, правда не с тюнером, а с платой захвата, что собственно почти одно и тоже.

Оказалось, модулю ядра чипа тюнера нужны параметры самой платы, после того как я их прописал время загрузки системы вернулось на свое место. Пример:

cat /etc/modprobe.d/bttv.conf
options bttv card=7 tuner=4 pll=1 radio=0 autoload=0 i2c_hw=1

yaba ★★
()
Ответ на: комментарий от kostik87

Попробуйте собрать ядро с каким-нибудь универсальным конфигом. Например конфиг можно взять из Арча и проверить на нем.

yaba ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.