Waiting for uevents to be processed
Решил написать в этой ветке форума, т.к показалось наиболее подходяще вопорсу. После недавней пересборки ядра (точнее обновления до последней версии доступной в портах 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, может в нем какойто косяк, что он включает какието опции при сборке ядра, которые не указаны в конфиге.
Не посчитайте за идиота при виде такого объема текста, в описании темы, но я уже не знаю что делать, не хочется целиком переставлять систему.
- Для комментирования войдите или зарегистрируйтесь
/
make oldconfig
?:wq
--
Live free or die
Пересобрал ядро со старым
Пересобрал ядро со старым конфигом, первая загрузка поисходит нормально, но при повторной загрузке поисходит подвис на выше описанном этапе.
rc-update show -v | grep udev
rc-update show -v | grep udev ?
P.S.: Linux - это красная таблетка :-) Windows - синяя...
udev-postmount |
udev-postmount | default
udev-mount |
udev-dev-tarball |
udev | sysinit
(http://dpaste.com/145824/)
Было такое, но не зависание,
Было такое, но не зависание, а слишком долгая работа. Попробуй обновится до последней нестабильной версии. По крайней мере у меня не осталось такой проблемы. Мне это было не критично, машина редко перезагружается, поэтому я не вникал в причины.
Но у меня вообще сейчас не
Но у меня вообще сейчас не происходит загрузка, я что либо могу делать с системой только если "чрутнусь" в нее, а в нете сижу с бука. После ожидания у меня просто сносятся почти все устройства в каталогу /dev, если собрать ядро на буке и положить скопировать на проблемную машину, с модулями соответсвенно, то один раз машина стартует нормально, а при перезагрузке опять полный аут. Уже сделал пересборку всех системных пакетов:
emerge -ae system
После долгих попыток
После долгих попыток разобраться что к чему, на отдельный раздел была произведена чистая установка из 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, она что то копитально ломает и глючит.
Рапортуйся =)
Рапортуйся =)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Помогите написать багрепорт,
Помогите написать багрепорт, а то у меня с английским не очень, понимаю нормально что написано, но правильно и грамотно описать баг и этапы его воспроизведения не смогу. Какие данные нужны для отправки (конфигурация), архитектура ... ?
AMD Athlon 6000+ x2
ASUS M2N32-SLI Deluxe (nForce 590)
Radeon 46700
Gentoo x86
http://bugs.gentoo.org/enter_
http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo Linux&format=guided
Начни отсюда, если совсем туго с английским, заяюзай гугловский переводчик - к мелким ( и даже средним) синтаксическим ошибка отношение нормально - понятно, что не у всех юзеров родной язык - английский.
если есть вопросы - открой тему и спрашивай. Так же можно спрашивать такие вопросы в джаббер-конфернции
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)