что-то у меня это свжесобранное ядрышко падает в паник при инициализации Root раздела грузится через такой конфиг и так тоже падает у меня на мамке установлен редконтроллер, но не задействован, тако ощущение что ядро пытается поработать через него и из-за этого падает родное ядро дистра спокойно грузится так
Что за дистрибутив? Содержимое /var/log/messages и /var/log/dmes после загрузки этим с этим ядром. Конфиг свой или дистрибный?
Booster привет CentOS 5.4 , конфиг на родное ядрышко конечно дистр, а моё авторский так ядро дохнет на активации рут раздела и соответственно оно ни каких логов не делает т.к. просто некуда
wsd Ну так надо попробовать родной конфиг. И точно root на /dev/sdb5? Поддержка соответствующей ФС в ядре есть? Тогда напиши, что на экране написано.
wsd Скорее всего всё-таки неправильно указывается корневой раздел. У меня подобное было, имя корневого раздела менялось чуть-ли не рандомно. Попробуй отключить все USB устройства. Ну или не знает такую ФС.
Стандартное решение это использовать initramfs с указанием раздела по LABEL или UUID. Нужно скомпилить ядро с его поддержкой.
Booster в смысле флешку из того списка или и мышь тоже? у меня мысль ещё что может пересобрать ядро с выкинутыми дровами редов. и может влиять то, что у меня ext3 не в ядре, а модулем?
wsd Проблема в том, что usb устройства определяются в произвольном порядке и от этого имена разделов могут рандомно назначаться. Вот и нашлась проблема. По все видимости у тебя новое ядро собрано без поддержки initramfs и ядру просто неоткуда взять модуль ext3. Так что обязательно компили в ядро фс которую используешь. Ну или компилить ядро с initramfs и кидать туда необходимые модули.
Booster так я с модулем фс просто недокликал или проскачил при конфиге ) хотел цельно. а сейчас по папке с дровами лазил и обнаружил, что модуль ) а ядро обязательно клеанить перед изменением конфига и пересборкой? а то оно ощутимо долго делается даже на моих четырёх ядрах.
wsd Не надо, если в конфиге что-то поменяется, то соответствующий объектник пересоберётся. Нафик пересобирать то, что неизменилось.
Booster теперь так вообще непонятно кто там запустил эту хрень ) модуль такой есть, но в положенной иерархии, а не чистом /lib/ потом )
все дистровскии работают, кроме моего newkernel-2.6.35.7 я img образ создавал просто указывал вход и выход mkinitrd ./newkernel-2.6.35.7.img 2.6.35.7 мож ему ещё какие параметры надо?
wsd Скорее всего падает из-за образа initrd, возможно криво собрался. Ещё нужно в ядре соответствующие опции указать, иначе оно не поймёт: General setup ---> [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support. mkinitrd не пользовался, пользуюсь своим скриптом для создания initramfs. Попробуй убрать строчку initrd и загрузить по /dev/.. Если не выйдет, попробуй указать ядру свой init: init=/bin/bash
Booster собрал с Initial RAM filesystem and RAM не помогает ещё там с разными параметрами побаловался ноль похоже это из-за моего грёбаного редконтроллера, его инициализация или отсутствие влияют на поименовку если удалить из дистрюбовских стандартных пунктов вызов инитрд результат такой же как и с моим ядром ) надо раскручивать инитрд сейчас у мя время кончилось, продолжу попозжей спасибо за участие
Не думаю, что это из-за контроллера. Имена /dev/.. не надёжны, легко могут меняться от запуска к запуску. Поэтому уже давно отошли от этого и именуют по UUID или LABEL. Но для этого нужно нормально собрать initrd(устарел) или лучше initramfs. Не знаю как там собирает mkinitrd, по-моему лучше собрать ручками. Я делал по-этому мануалу - initramfs, работает отлично. Ну или разобраться с mkinitrd, скорее всего действительно не хватает какой-то опции. Ещё можно поиграть с параметрами ядра rootwait и rootdelay. Мне вроде как второй параметр помог при загрузке с /dev/.., устаканить именование разделов.
Рейдконтроллер здесь не причём абсолютно. Выбор раздела происходит по метке раздела: root=LABEL=/, но не по имени. Проблема с initrd. Дефолтные ядра дистрибутивов, как правило полагаются на initrd, и без него не грузятся. Поскольку дефолтные ядра -- generic ядра, они должны работать на куче разного железа, и включать статически в такое ядро всё, что ему может понадобиться для того, чтобы смонтировать /, выглядит глупостью. Кроме того initrd действительно удобен, если / не удаётся смонтировать: можно получить рутовский шелл для исправления ситуации. Тебе надо собирать свой initrd. Для этого, я бы на твоём месте воспользовался гуглом и нашёл бы мануал по созданию initrd для CentOS. "Initial RAM filesystem and RAM" -- штука необходимая для использования initrd, но её мало. initrd -- это же не просто пожатый образ файловой системы с модулями. Помимо модулей туда пихают, как правило, busybox, init и ряд скриптов. Или включать в ядро статически всё, что надо для монтирования / (драйвер на fs, драйвер на IDE/SATA контроллер, может ещё что-то). Сей второй путь сложен и выстлан граблями, помочь тебе в нём вряд ли удастся, если только не сидеть рядом и не видеть всех тех строчек что мелькают на экране при старте ядра. В утешение могу сказать лишь одно: путём этим сложно идти лишь в первый раз. Потом всё гораздо проще. В принципе, я бы порекомендовал начать с vesafb-консоли, и добавлением к опциям ядра vga=0x31A. Консолька в разрешении 1280x1024 гораздо более информативна по сравнению с чисто текстовой.
