URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 70364
[ Назад ]

Исходное сообщение
"Проблема загрузки ядра с SATA-винчестера"

Отправлено VladimirX , 19-Ноя-06 18:53 
Здравия желаю....

Есть машина, на мамке встроенный SATA контроллер от VIA. Есть SATA-винт.
Устанавливаю на эту машину Gentoo Linux. Гружусь с LiveCD - всё хорошо
(на LiveCD используется ядро 2.6.17-2): винт определился, появилось устройство /dev/sda,
которое я fdisk'ом разметил. Создал следующие разделы и файловые системы на них:
/dev/sda1 ext2
/dev/sda2 swap
/dev/sda3 reiserfs
/dev/sda4 reiserfs

Взял на кернел.орг последнее ядро - 2.6.18.2. Собрал его. Файовые системы вкомпилил в ядро.
Поддержка SCSI модульная - используются модули libata.ko и sata_via.ko.
Для того чтобы передаваемый ядру параметр (root=/dev/sda3) был понятен, пришлось воспользоваться
утилитой mkinitrd:

#> mkinitrd --preload "libata sata_via" --fstab=/etc/fstab /boot/initrd.img 2.6.18.2

Получил initramdisk в /boot.

Файл /etc/fstab такой:

/dev/sda3   /      reiserfs   notail,noatime   0  1
/dev/sda1   /boot  ext2       noatime    1  1
/dev/sda2   none   swap       sw         0  0
proc        /proc  proc       defaults   0  0
shm         /dev/shm tmpfs    nodev,nosuid,noexec   0  0

В командной строке Grub вбиваю строки (Груб саташный винт видит как hd0)

root (hd0,0)
kernel /bzImage root=/dev/sda3
initrd /initrd.img
boot

Загружается ядро, определяется саташный винт, показывается sda: sda1, sda2, sda3, sda4
т.е модули работают нормально. Но потом ядро паникует:

Mount root filesystem
mount: error 6 mounting reiserfs
pivotroot: pivot_root (/sysroot, /sysroot/initrd) failed: 2
umount /initrd/proc failed: 2
Kernel panic - not syncing: No init found

Т.е. почему-то ядро не может примонтировать /dev/sda3.

Что я пробовал еще?
Пробовал драйвер ФС делать модулем и запихивать его в initrd - не помогло.
Пробовал ядру передавать загадошные параметры, о которых вычитал на буржуйских форумах
ide0=1xblablabla, пробовал передавать ядру параметр ramdisk_size=70000 - результат отрицательный.
Может, конечно, проблема где-то в дебрях devfs - тут я ничего не ковырял.

Помогите пожалуйста.


Содержание

Сообщения в этом обсуждении
"Проблема загрузки ядра с SATA-винчестера"
Отправлено VladimirX , 20-Ноя-06 09:03 
Ну может хотя бы чисто теоретически просветите меня, как всё должно быть?
В /dev/brain уже каша полная....

1) Вот ядро: нужны ли для САТА-винта SCSI-emulation, generic SCSI, SCSI ide?
(если я оставлял только SATA support (libata.ko) и via SATA (sata_via.ko)), то устройств sdaxx не сооздается. Выводится лишь
ATA: abnormal status 0x7F on port 0xB407
Vendor: ATA  Model: ST80817AS   Rev: 3.42
Type: Direct Access      ANSI SCSI revision: 05

2) Вычитал такую вещь, что САТА якобы определяется раньше IDE. Ему назначаются устройства
hda, hdb, hdc и hdd. Не совсем понял. Почему тогда у меня создаются sda?

Спасибо


"Проблема загрузки ядра с SATA-винчестера"
Отправлено perece , 20-Ноя-06 14:17 
>Ну может хотя бы чисто теоретически просветите меня, как всё должно быть?
>
>В /dev/brain уже каша полная....
>
>1) Вот ядро: нужны ли для САТА-винта SCSI-emulation, generic SCSI, SCSI ide?
SCSI ide возможно нужен, SCSI-generic не, SCSI-emu это что? dummy-SCSI?

>(если я оставлял только SATA support (libata.ko) и via SATA (sata_via.ko)), то
>устройств sdaxx не сооздается. Выводится лишь
>ATA: abnormal status 0x7F on port 0xB407
>Vendor: ATA  Model: ST80817AS   Rev: 3.42
>Type: Direct Access      ANSI SCSI revision: 05
>
>
>2) Вычитал такую вещь, что САТА якобы определяется раньше IDE. Ему назначаются
>устройства
>hda, hdb, hdc и hdd. Не совсем понял. Почему тогда у меня
>создаются sda?
hd* создаются если SATA работает в т.н. "Compatible" mode, т.е. когда обычный IDE эмулируется на уровне железа SATA-котроллером (переключается обычно в биосе)
при этом поддержки SATA в ядре линукса не требуется, достаточно обычного "generic ATA" драйвера.
в "Enhanced" mode создаются sd*, и для их получения необходима поддержка в ядре

вопрос в сторону: а нафига initrd? initrd это, в сущности, костыль, созданый дабы обеспечить возможность "первичной" установки на неизвестное оборудование без помощи "старой" машины, где можно было бы пересобрать. суть это фича для _дистрибьюторов_ линукса. если предполагается собирать кастомное ядро под конкретную машину то делать загрузку с initrd как минимум нелогично. все, что нужно для монтирования корневой ФС можно сделать hard-compiled в ядре.
вопрос в другую сторону: а почему reiser? ведь тормоз же, господи прости, да и не выполз окончательно из состояния "экспериментального". ну приспичило журналирование сделать (чо на него так все молятся-то?) - чем не устраивает jbd/ext3?

\^P^/


"Проблема загрузки ядра с SATA-винчестера"
Отправлено VladimirX , 21-Ноя-06 07:27 
Вот парадокс - вкомпилил всё в ядро и заработало ведь!
Огромный сенкс!
А по поводу reiserfs: могу конечно ошибаться, но листая как-то журнал, я вычитал что reiserfs наряду с jfs одни из самых шустрых. Неужели ввели в заблуждение?

"Проблема загрузки ядра с SATA-винчестера"
Отправлено XPurple , 21-Ноя-06 08:32 
>Вот парадокс - вкомпилил всё в ядро и заработало ведь!
>Огромный сенкс!
>А по поводу reiserfs: могу конечно ошибаться, но листая как-то журнал, я
>вычитал что reiserfs наряду с jfs одни из самых шустрых. Неужели
>ввели в заблуждение?


ReiserFS- ненадежная FS, слетает очень легко.


"Проблема загрузки ядра с SATA-винчестера"
Отправлено perece , 21-Ноя-06 12:25 
>Вот парадокс - вкомпилил всё в ядро и заработало ведь!
>Огромный сенкс!
>А по поводу reiserfs: могу конечно ошибаться, но листая как-то журнал, я
>вычитал что reiserfs наряду с jfs одни из самых шустрых. Неужели
>ввели в заблуждение?
reiser довольно шустрая при чтении. на запись она тормозит безбожно.

насчет надежности - согласен. надежности ей тоже недостает, в том плане что если у тебя ломается ext2(3), то поврежденные файлы просто пропадают (и ты узнаешь об этом, доставляешь нехватающее из дистрибутива или бэкапа). если ломается reiser, то поврежденные файлы остаются, просто некоторые куски их содержимого могут оказаться "заменены" мусором. искать такую поломку сложнее на порядок. потому и считаю ея ненадежной. (вероятность же слетания reiser/ext3 при одинаковых "внешних воздействиях" примерно одна и та же, и достаточно низка надо сказать)

\^P^/