Пробовались ядра 2.6.37 и 2.6.38. С 2.6.30 грузится нормально. Ситуация такова, что драйвер хьюлетовского raid-контроллера cciss, начиная с 2.6.33 был интегрирован в ядро под именем hpsa. Поменялись и названия утсройств в /dev. Если раньше это был /dev/cciss/c0d0, то с момента интеграции должен стать /dev/sda. fstab: proc /proc proc nosuid,noexec,gid=proc 0 0 devpts /dev/pts devpts nosuid,noexec,gid=tty,mode=620 0 0 tmpfs /tmp tmpfs nosuid 0 0 UUID=6771a017-9dd9-48e9-baf2-41477af4dfba / ext3 relatime 1 1 UUID=1dd884c5-0901-4761-8499-75dec9b36e8e /usr ext3 nodev,relatime 1 2 UUID=07c7c523-6eb9-4c2c-9b94-81a9a0a369c3 /var ext3 nosuid,relatime 1 2 UUID=547efb63-4017-4a63-aace-5925cb18e57c /var/lib/pgsql-root/var/lib/pgsql ext3 noexec,nosuid,nodev,relatime, 1 2 #UUID=99c48152-9a77-4529-95b4-e0c09e4c81a1 /var/lib/pgsql/backups ext3 nosuid,nodev,noexec 1 2 UUID=99c48152-9a77-4529-95b4-e0c09e4c81a1 /storage ext3 nosuid,nodev 1 2 UUID=1ed4f8e4-0c10-4aa6-b0d7-0a0c78ea2882 /var/log ext3 nosuid,nodev,noexec 1 2 UUID=c7280740-6950-4e33-b993-4b1f8970c47b swap swap defaults 0 0 /dev/sr0 /media/cdrom udf,iso9660 ro,noauto,user,utf8 0 0 lilo.conf: image="/boot/vmlinuz-2.6.38-std-def-alt1" initrd="/boot/initrd-2.6.38-std-def-alt1.img" label="2638-std-def-1" root="UUID=6771a017-9dd9-48e9-baf2-41477af4dfba" read-only optional
Created attachment 4866 [details] скриншот ошибки
Сергей, а это случайно не udev виноват ? При чём тут ядро то ? драйвер загружается тот, который надо ?
а, вижу ошибку. Ну, переезд с /dev/cciss/c0d0 на /dev/sda тут не виноват - новый драйвер почему-то не поднимается на твоей железке.
Стоит попробовать загрузку с параметром: intel_iommu=off Ядра std-def 2.6.37 и 2.6.38 сейчас собраны с CONFIG_DMAR_DEFAULT_ON=y; в el-smp эта опция выключена. Хотя тут ошибка может быть даже не в самом ядре, а в BIOS.
попробовал intel_iommu=off с ядром 2.6.38 и ядро 2.6.32-el-smp без дополнительных параметров, на обоих ядрах ситуация одинаковая: вышеприведёных ошибок нет, но udev не может смонтировать корень. Из консольки initrd видно, что в /dev нет никаких устройств sd*, lsmod говорит, что драйвер hpsa загружен, но не используется. Перевешивать багу на udev? Кстати, вообще по поддержке контроллеров HP в сети и нашел вот это: For newer kernels and newer controllers, we are transitioning things to hpsa, and we do not want any overlap between the two drivers. For cciss, the supported controllers in newer kernels should be: {0x40700E11, "Smart Array 5300", &SA5_access}, {0x40800E11, "Smart Array 5i", &SA5B_access}, {0x40820E11, "Smart Array 532", &SA5B_access}, {0x40830E11, "Smart Array 5312", &SA5B_access}, {0x409A0E11, "Smart Array 641", &SA5_access}, {0x409B0E11, "Smart Array 642", &SA5_access}, {0x409C0E11, "Smart Array 6400", &SA5_access}, {0x409D0E11, "Smart Array 6400 EM", &SA5_access}, {0x40910E11, "Smart Array 6i", &SA5_access}, {0x3225103C, "Smart Array P600", &SA5_access}, {0x3223103C, "Smart Array P800", &SA5_access}, {0x3234103C, "Smart Array P400", &SA5_access}, {0x3235103C, "Smart Array P400i", &SA5_access}, {0x3211103C, "Smart Array E200i", &SA5_access}, {0x3212103C, "Smart Array E200", &SA5_access}, {0x3213103C, "Smart Array E200i", &SA5_access}, {0x3214103C, "Smart Array E200i", &SA5_access}, {0x3215103C, "Smart Array E200i", &SA5_access}, {0x3237103C, "Smart Array E500", &SA5_access}, {0x323d103c, "Smart Array P700M", &SA5_access}, For hpsa, it should be: {0x3241103C, "Smart Array P212", &SA5_access}, {0x3243103C, "Smart Array P410", &SA5_access}, {0x3245103C, "Smart Array P410i", &SA5_access}, {0x3247103C, "Smart Array P411", &SA5_access}, {0x3249103C, "Smart Array P812", &SA5_access}, {0x324a103C, "Smart Array P712m", &SA5_access}, {0x324b103C, "Smart Array P711m", &SA5_access}, {0x3233103C, "StorageWorks P1210m", &SA5_access}, {0x333F103C, "StorageWorks P1210m", &SA5_access}, {0x3350103C, "Smart Array", &SA5_access}, {0x3351103C, "Smart Array", &SA5_access}, {0x3352103C, "Smart Array", &SA5_access}, {0x3353103C, "Smart Array", &SA5_access}, {0x3354103C, "Smart Array", &SA5_access}, {0x3355103C, "Smart Array", &SA5_access}, So, a few which used to be supported by cciss are now supported only by hpsa, and there should be no overlap between the two drivers. Ну и вот околопроблемная ссылочка: http://www.gossamer-threads.com/lists/linux/kernel/1349728
Возможно, ещё не хватает модуля sd_mod - со старым драйвером он был не нужен, а вот hpsa полностью работает через подсистему SCSI. В mkinitrd был код, добавлявший sd_mod при добавлении модуля, каким-либо образом использующего модули из kernel/drivers/scsi.
(В ответ на комментарий №6) > Возможно, ещё не хватает модуля sd_mod - со старым драйвером он был не нужен, а > вот hpsa полностью работает через подсистему SCSI. В mkinitrd был код, > добавлявший sd_mod при добавлении модуля, каким-либо образом использующего > модули из kernel/drivers/scsi. Точно, дел было именно в этом! Итого, для 2.6.38-std-def-alt1 нужно добавить intel_iommu=off и пересоздать initrd с sd_mod. Для 2.6.32-el-smp только пересоздать initrd. Бага уезжает на make-initrd.
Хм, hpsa тянет scsi_mod, но не sd_mod... Хотя конкретно для initrd может и быть смысл вытягивать sd_mod, если попал scsi_mod.
(В ответ на комментарий №8) > Хм, hpsa тянет scsi_mod, но не sd_mod... Это всегда так и было для всех драйверов SCSI-контроллеров. > Хотя конкретно для initrd может и > быть смысл вытягивать sd_mod, если попал scsi_mod. Примерно так и делалось в mkinitrd (точнее, там в ModuleKind это определялось по расположению самого модуля или модулей, вытягиваемых по зависимостям).
Не могли бы вы попробовать: http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=commitdiff;h=HEAD ?
Обновил прошивку на контроллере и биос - теперь 2.6.38 грузится без intel_iommu=off. Т.е. ядро полностью работоспособно. Сергей, спасибо вам большое за эту подсказку! (В ответ на комментарий №10) > Не могли бы вы попробовать: > > http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=commitdiff;h=HEAD Ок, попробую.
Нет, патчик не помог. С ним в initrd добавлялся модуль scsi_mod, а надо sd_mod. Вот с таким конфигом генерится рабочий intrd: MODULES_PRELOAD = sd_mod hpsa
Можете прислать: make-initrd bug-report ?
(В ответ на комментарий №12) > Нет, патчик не помог. > С ним в initrd добавлялся модуль scsi_mod, а надо sd_mod. конечно sd_mod. я запутался и добавил не тот модуль. Исправил (с force): http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=commitdiff;h=60f9a5a7cf7588e68df8a944bccedfa4a810aed5 но bug-report вы всё равно приложите потому что мне казалось, что sd_mod должен вытягиваться по modalias.
В виду отсутствия реакции выпускаю make-initrd этим фиксом и считаю, что проблема решена.
Я извиняюсь что не ответил вовремя - перестала приходить почта от багзиллы. Сейчас поробовал make-initrd 0.5.0-alt1 - ситуация не изменилась. Ситуация такова: загружено ядро 2.6.32 - там ещё старый драйвер, установлено 2.6.38 и для него генерится initd: #rpm -q make-initrd make-initrd-0.5.0-alt1 #sudo make-initrd -k 2.6.38-da-ng-alt3 -v Config file: /etc/initrd.mk Generating module dependencies on host ... depmod -a -F "/boot/System.map-2.6.38-da-ng-alt3" "2.6.38-da-ng-alt3" Guessed modules: ext3 hpsa scsi_mod Guessed features: add-modules cleanup compress Creating initrd image ... mkdir: created directory `/tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd/img' mkdir: created directory `./conf' mkdir: created directory `./dev' mkdir: created directory `./etc' mkdir: created directory `./etc/modprobe.d' mkdir: created directory `./etc/udev' mkdir: created directory `./etc/udev/rules.d' mkdir: created directory `.//lib' mkdir: created directory `.//lib/modules' mkdir: created directory `.//lib/modules/2.6.38-da-ng-alt3' mkdir: created directory `./lib/udev' mkdir: created directory `./mnt' mkdir: created directory `./root' mkdir: created directory `./proc' mkdir: created directory `./sys' mkdir: created directory `./tmp' mkdir: created directory `./var' mkdir: created directory `./var/lock' put-tree: Copying '/lib/initrd' recursively ... put-tree: Copying '/lib/initrd' recursively ... put-tree: Copying '/usr/share/make-initrd/data' recursively ... create-initrd: Setting ash as /bin/sh ... create-initrd: Copying files from /etc/modprobe.d ... create-initrd: Copying files from /lib/udev/initramfs-rules.d ... Adding modules ... add-module: Adding module "mbcache.ko" add-module: Adding module "jbd.ko" add-module: Adding module "ext3.ko" add-module: Adding module "scsi_mod.ko" add-module: Adding module "hpsa.ko" Generating module dependencies in image ... /sbin/depmod -a -F "/boot/System.map-2.6.38-da-ng-alt3" -b /tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd/img \ "2.6.38-da-ng-alt3" Packed modules: ext3 hpsa jbd mbcache scsi_mod Packing image to archive ... Compressing image ... Installing image ... `/tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd/initrd.img' -> `/boot/initrd-2.6.38-da-ng-alt3.img' removed `/tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd/initrd.img' Removing work directory ... rm -rf -- "/tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd/img" "/tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd/guess" rmdir -- "/tmp/make-initrd.oX1sqgakw/2.6.38-da-ng-alt3.initrd" Image is saved as /boot/initrd-2.6.38-da-ng-alt3.img Как видно, sd_mod в initrd не попал. Если что, ядра собственной сборки, но влиять на ситуацию это не должно.
Created attachment 4969 [details] bugreport Кстати в bugreport попадает конфиг текущего ядра, но не попадает конфиг ядра, для которого генерися initrd. Запускалось так: make-initrd -k 2.6.38-da-ng-alt3 bug-report
(In reply to comment #16) > Как видно, sd_mod в initrd не попал. Наконец поймал то же самое на ноуте с 0.7.3-alt1 и 3.2.14-std-pae-alt1; помогло MODULES_PRELOAD += sd_mod, думаю дальше.
В 0.7.6/0.7.8 были изменения по части определения встроенных модулей (в el-smp sd_mod впаян статиком), см. bug #27321.
Ещё актуально?
Не актуально. Если это не так, то переоткройте.
