kernel panic при загрузке ядра 2.4.21

Часть конфигурации ядра:
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_IDE_TASK_IOCTL=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_ADMA100 is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
# CONFIG_BLK_DEV_ATARAID_SII is not set


#
# File systems
#
CONFIG_QUOTA=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_UMSDOS_FS=y
CONFIG_VFAT_FS=y
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_JFS_FS=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
CONFIG_NTFS_FS=y
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=y
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set


#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SMB_NLS is not set
CONFIG_NLS=y





Что сделать, чтоб ядро нормально запустилось???

а что ты делал после того как откомпилил ядро?

Скопировал в /boot/ файлы:
/usr/src/kernel-source-2.4.21/system.map (поверх старого)
/usr/src/kernel-source-2.4.21/arch/i386/boot/bzImage

Подредактировал файл /boot/grub/menu.lst:


title Alt-Linux
kernel (hd0,0)/boot/vmlinuz-up root=/dev/hda1
initrd (hd0,0)/boot/initrd-up.img

title Alt-Linux Fast
kernel (hd0,0)/boot/bzImage root=/dev/hda1
initrd (hd0,0)/boot/initrd-up.img

Вроде всё.
Alt-Linux-дефолтное
Alt-Linux Fast-новое

с грубом я не работал
у меня лило

но вопрос такой: ты в бут все что откомпилил всунул?

к примеру в лило после редактирования lilo.conf необходимо выполнить команду lilo из под рута, дабы все работало

>но вопрос такой: ты в бут все что откомпилил всунул?
В принципе это всё, что надо было всунуть. Больше туда я ничего не копировал.

Может ему файлик initrd-up.img не нравится?

>к примеру в лило после редактирования lilo.conf необходимо выполнить команду lilo из под рута, дабы все работало
В грубе написано, что не надо.

тогда не знаю :(((

ну во первых. kmod: failed to exec /sbin/modprobe -s -k nls_iso8859-1, errno=2

ты не влючил поддержу nls_iso8859-1 в ядре. имей ввиде что та что установлена как дефолтная должна быть вкомпилирована в ядро, остальные можно модулем. я фсегда устанавливаю по дефолту utf8.

во вторых покажы: #fdisk -l

Не говори ерунды. Можно все компилить модулем. Всю жизнь все так делают.

P.S. Можешь начинать править свой конфиг.

Что-то я такое про reiserfs уже видел.
Ты сделай вот что. У тебя /boot на reiser, да?
Тогда его компилишь жестко, а остальные fs - модулем.
Если компилишь ext3, не делай ext2.
После чего пересобери ядро и попробуй перегрузиться.
Глядишь и полегчает.


P.S. Если ты используешь initrd, то нафига вообще поддержку собирать жестко?

Спасибо всем за помощь, я уже разобрался. Как я и предпологал всё дело было в файлике initrg.img. Просто Alt-овцы скомпилили свое ядро с поддержкой reiser'а в виде модуля. В initrd.img запихали модуль reiserfs.o, а из файлика linuxrc этот модуль подгружали. Вот и конфликтовали 2 рейзера: вкомпиленный в ядро и подгруженный :))). А решилась проблема созданием своего initrd.img уже без модуля reiserfs.o и без вызова его из linuxrc.txt.
Но вот только сообщения об ошибках фата при загрузке не изчезли :(((, и вообще непонятно откуда они появились, ведь на том этапе загрузки ни о каком монтировании фат-разделов не может быть и речи!?

2jackill: Я, если честно, не понимаю зачем нужны модули: то что я использую, то я и вкомпиливаю, а то что мне не надо, запрещаю полностью. А если компилировать модулем, то ведь потом этот модуль ещё и подгружать надо, ядро ведь само его не подгрузит???

Не рюхаешь.

Модули подгружаются сами. Как только системе требуется поддержка, она смотрит, что у нее есть на эту тему и подгружает нужный модуль. (Ты для этого делаешь depmod -a, и при сборке ядра это, естественно, производится, только с несколько другим ключом, т.к. ядро еще неактивно).

Зачем нужен initrd.
Тут тоже все просто. Когда у тебя файловая система собрана модулями (исключительно), то ядро после загрузки не может обратиться к файловой системе - т.к. модуль на ней, а добраться до него нечем.
А в initrc он в памяти и все как надо - он обращается к нему, подгружает и дальше идет загрузка.

В чем смысл собирать все в ядро? Переключение контекста идет быстрее. Правда очень сомневаюсь, что ты это заметишь.

В чем смысл модулей?
1. А нафига делать такое большое ядро? Настанет момент, когда оно не влезет в память (при загрузке).
2. Модулям можно передать параметры, жестко вкомпиленной части параметров ты не передашь. Первый пример, который на ум приходит - тюнер. Опять же, если толком не знаешь что собирать (например, речь идет о выборе между двумя модулями), собираешь оба и по очереди грузишь, пока нужный не найдешь. Собранные жестко могут конфликтовать.

Скорее всего fat твой конфликтует с reiser,

>Переключение контекста идет быстрее

Не говори ерунды.

> Переключение контекста идет быстрее. Правда очень сомневаюсь, что ты это заметишь.

Енто еще зачем? Какого еще контекста? Есть понятие переключения контекста процесса, есть понятие переключения между user mode и kernel mode, но я не слышал о переключении между kernel mode и module mode :) Символы модуля ресолвятся в момент его загрузки, никакой дополнительной косвенной адресации нет (на уровне инструкций процессора), иначе бы модули были бы медленней и никто бы их не юзал :) Вот еще прикинь: когда динамичная библа вгружается, допустим libc, используемые твоим процессом символы в ней патчатся на фактические адреса внутри библиотеки, и дальше все на полной скорости! И этот процесс еще можно убыстрить, если регулярно использовать замечательную тулзу prelink! :)

Модули и есть медленнее.
В каком-то треде здесь об этом говорили.

Как думаешь, почему монолитное ядро быстрее? Прется от своей монолитности и поэтому так быстро работает?

А кто сказал, что оно медленнее? Не обладаю достаточной компетенцией/средствами чтобы доказать идентичность скоростей монолитного и модульного ядра или быть опровергнутым, но в случае с либами провел эксперимент: прога на С вызывает strlen() в цикле миллиард раз, и построил ее статично и динамично:

$ cat > foo.c
#include <stdlib.h>

int main(void)
{
size_t i, len;
for (i = 0; i < 1000*1000*1000; i++) {
len = strlen("hi");
}
return 0;
}
^D
$ gcc -o foo_dynamic foo.c
$ gcc -o foo_static -static foo.c
$ ls -l
total 476
-rw-r--r-- 1 rihad rihad 132 Jan 23 22:20 foo.c
-rwxr-xr-x 1 rihad rihad 11274 Jan 23 22:20 foo_dynamic
-rwxr-xr-x 1 rihad rihad 468567 Jan 23 22:20 foo_static
$ time ./foo_dynamic

real 0m3.886s
user 0m3.681s
sys 0m0.001s
$ time ./foo_static

real 0m3.900s
user 0m3.684s
sys 0m0.001s
$

Т.е. скорости абсолютно идентичны (в рамках погрешности).

Теперь вопрос: по какой врожденной причине модули должны быть медленней монолитного ядра?

> А кто сказал, что оно медленнее?

s/медленнее/быстрее/

Да постоянно все орут. Может, раньше как-то различалось?

Нашел доку, судя по доке - скорость та же (т.к. в kernel space грузится). Интересно, можно ли ей верить.

Возникает только один вопрос - нафига тогда давать выбор "модули/не модули" - обязательные к сборке как не модули воткнули бы жестко, а остальное - модулями. initrd же есть.

Есть у меня на этот счет догадка. Может они думают, что модуль в user space уходит?

Да скорей всего просто орут о том, что есть определенный оверхед при первом обращении к модулю (и потом если периодически делать rmmod -a, но я таким извратом не занимаюсь :)))

(Дальше говорю с точки зрения простого юзера т.к. еще не увлекался kernel-hacking'ом) Есть же ведь определенные достоинства у монолитного ядра (но никогда не слышал чтобы кто-то к ним причислял увеличенную скорость). Например, простота администрирования. Или чуть улучшенная защищенность (на памяти есть эксплойт, который работал, только когда в ядре есть поддержка модулей). Т.е. просто придерживаемся принципа K.I.S.S. - меньше возможных сценариев == меньше возможных точек облома где-то. А модули делают более простым процесс добавления новой функциональности в ядро! К тому же, если хочешь поиграться с вмварей или юзать дрова от нвидии, то просто нет выбора. И напоследок: предоставление выбора политики *юзеру* - это то, что отличает и всегда отличало юникс от винды, в конце-то концов :)

слушайте, вы оба == полные ламеры.
ядро линукса монолитное. даже если включена поддержка модулей. оно было бы не монолитным если бы каждый подгружаемый модуль выполнялся в отдельном адресном пространстве.

jackill, ты миня пугаеш своей не проходимой тупостью.

:( Как назвать немодульное ядро тогда? "Монолитное" - первое что приходит в голову (в противовес "модульному")! Пусть это слово и конфликтует с уже устоявшимся термином в дизайне ядер, мало чтоли таких случаев двусмысленности? :)

>Как назвать немодульное ядро тогда

так и назвать. ядро без поддежки загрузки модулей.

_не_монолитность и возможность загрузки модулей, совершенно разные вещи. и ни какой двусмысленности.

2jackill

>Есть у меня на этот счет догадка. Может они думают, что модуль в user space уходит?

С такими догадками ходят в лес ;)

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

в случае с initrd скорость по идее может быть и выше потому как модули будут дергатся не с харда а из /dev/ram0 сам же /dev/initrd дергается за один раз причем в сжатом виде ...

короче man initrd

Про "контексты" это просто бред ...

>> Как назвать немодульное ядро тогда
> так и назвать. ядро без поддежки загрузки модулей.

Дык блин весь мир рискуя двусмысленностью называет безмодульное ядро монолитным. Вот что гугл выдал на "monolithic kernel": http://gogole.com/search?q=monolithic+kernel&ie=UTF-8&oe=UTF-8&hl...

Это из той же оперы, что использование слова Unix. Строго говоря, все кто применяют слово Unix в отношении любой ОС, отличной от первой AT&T - не правы. Но они подразумевают Unix-like. То же самое здесь, говорим монолитное, но не имеем ввиду дизайн ядер, а просто его целостность и неизменность, в отличии от модульного.

Если ты один раз модуль дернешь, то потом-то тебе все равно будет, или не так?
Он же уже в памяти будет.

Я думаю, что все знают о том, что ядро линукса монолитное, а не микроядерное.
Поэтому слово "монолитное" в моем ответе означает, что модули вкомпилены жестко. Это поняли все, кроме тебя.

P.S. Ты на свои ответы лучше посмотри.

Не придирайся к словам, короче.

jackill, ты что дурак?

------------------------------------

Модули и есть медленнее.

Как думаешь, почему монолитное ядро быстрее? Прется от своей монолитности и поэтому так быстро работает?

Есть у меня на этот счет догадка. Может они думают, что модуль в user space уходит?

Поэтому слово "монолитное" в моем ответе означает, что модули вкомпилены жестко

>Если ты один раз модуль дернешь, то потом-то тебе все равно будет, или не так?

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

С точки зрения скорости _работы_ разницы не будет никакой с точки срения скорости загрузки драйвер в модуле это _медленнее_ но более гибко в том плане что можно пускать например ядра на заранее неизвестном железе (Live-CD например) и при этом не запихивать весь код в ядро или выгружать неиспользуемые модули хотя последнее ImHO сильно большого смысла не имеет - много не съэкономишь на этом.

Про терминологию:

Тут имеет место быть путаница

Классическая терминология монолит vs микрокернел относится к _архитектуре_ ядер OS вообще а не к классическому Linux ядру - он всю дорогу _монолит_ даже с модулями, код которых при загрузке оказывается в адресном пространстве ядра (kernel space) у mK же каждый (за некоторым искл.) драйвер работает в собственном адресном пространстве.

Правильнее было бы говорить что тот или иной драйвер собран как модуль или вкомпилен в ядро. "монолит" vs "модуль" в данном случае это сленг если хотите а не строгая терминология.