Если новое ядро делает какие-то странные вещи после текущего его
обновления, то есть большая вероятность, что вы забыли выполнить make
clean до компиляции нового ядра. Симптомы могут быть любыми от полного
краха вашей системы, странных проблем с вводом/выводом до малой
производительности. Убедитесь также, что вы сделали make dep.
Если ваше ядро поглощает достаточное количество памяти, слишком большое и/или просто долго компилирует, даже когда вы заставили ваш новый 786DX6/440 работать с ним, то вы вероятно получили набор ненужных вам вещей (драйверов устройств, файловых систем и т.п.). Если вы не используете их, то не настраивайте их, потому, что это занимает память машины. Наиболее очевидный симптом раздутия ядра, это интенсивное свапирование памяти на диск и с диска; если ваш диск создает шум и он не один из старых винчестеров Fujitsu Eagles, чей звук напоминал звук выключаемого двигателя реактивного самолета, то посмотрите в конфигурацию ядра.
Вы можете узнать сколько оперативной памяти занимает ядро взяв общее
количество памяти на машине и вычтя из него количество ``общей памяти'' в
файле /proc/meminfo или вывод команды `free'. Вы можете
также определить это выполнив команду `dmesg' (или посмотрев в
файл протокола ядра, если он есть в вашей системе). Там будет строка,
которая выглядит примерно так:
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
Моя машина с процессором 386 (которая была настроена с меньшим количество опций) выдает следующее:
Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)
Если у вас просто получается большое ядро, но система не позволяет вам
это, то вы можете попытаться выполнить `make bzimage'. Вам также
может понадобиться установить новую версию LILO чтобы сделать это.
Если ядро не компилируется, то скорее всего произошел сбой при
накладывании заплатки или ваши исходные тексты были повреждены каким-либо
образом. У вас также может быть неправильная версия gcc или также может
быть повреждена (например включаемые файлы могут быть с
ошибками). Убедитесь, что символические ссылки, которые описывает Linus в
файле README установлены правильно. В общем, если стандартное ядро
не компилируется, то у час что-то серьезное с системой и вероятно
необходима переустановка некоторых утилит.
или возможно вы компилируете ядро 1.2.x при помощи ELF компилятора (gcc
2.6.3 и выше). Если вы получили набор ошибок типа so-and-so
undefined в течении компиляции, то скорее всего у вас такая
проблема. Исправление в большинстве случаев очень просто. Добавьте эти
строки в начало файла arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Затем заново выполните make dep и zImage.
В редких случаях gcc может не работать из-за аппаратных проблем. Сообщение об ошибке будет примерно такое ``xxx exited with signal 15'' и это в общем будет выглядеть очень загадочно. Я вероятно не должен был здесь это упоминать, за исключением того что это со мной однажды случилось -- у меня была испорченная кэш-память и компилятор время от времени не работал. Попробуйте сначала переставить gcc, если у вас есть такая проблема. ВЫ должны стать подозрительным только если ваше ядро нормально компилируется с отключенным внешним кэшем, с уменьшенным количество оперативной памяти и т.п.
Это имеет склонность беспокоить людей, когда они предполагают, что их
оборудование не в порядке. Хорошо, я не буду делать это. Об этом существует
FAQ -- он находится на http://www.bitwizard.nl/sig11/.
Вы не запустили LILO, или он не настроен правильно. Одна вещь которая
случилось однажды со мной это была проблема в файле конфигурации; там
говорилось `boot=/dev/hda1' вместо `boot=/dev/hda' (Это
может быть раздражающим в начале, но когда вы сделаете рабочий файл
конфигурации, то вам не нужно будет его больше изменять).
Оххх! Лучшая вещь, которую вы можете сделать в этом случае это
загрузиться с дискеты подготовить другой загрузочный диск (такой какой
должна сделать команда `make zdisk'). Вам необходимо знать где
находится ваша корневая файловая система (/) и какой тип она имеет
(например second extended, minix). В нижеприведенном примере, вам также
необходимо знать на какой файловой системе находится дерево исходных
текстов /usr/src/linux, ее тип и где она обычно монтируется.
В следующем примере, / находится на /dev/hda1, а
файловая система, которая содержит /usr/src/linux находится на
/dev/hda3, обычно смонтированной как /usr. Обе относятся
к типу second extended файловых систем. Рабочее ядро находится в директории
/usr/src/linux/arch/i386/boot и называется zImage.
Идея заключается в том, что если есть работающее ядро, то можно использовать его для создания нового загрузочного гибкого диска. Другой вариант, который может работать лучше (а может и не работать, это зависит от конкретного метода которым вы сломали свою систему) обсуждается дальше после примера.
С начала загрузимся с комбинации загрузочного/корневого дисков или спасательного (rescue) диска, и смонтируем файловую систему, которая содержит работающее ядро:
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Если mkdir сообщает вам, что директория уже существует, то
просто проигнорируйте это сообщение. Затем перейдите в ту директорию, где
находится работающее ядро. Заметим, что
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
Поместите отформатированную дискету в привод ``A:'' (только не загрузочную дискету и не дискету с корневой файловой системой!), и перебросьте ядро на дискету и настройте его на вашу корневую файловую систему:
cd /mnt/src/linux/arch/i386/boot
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
перейдите в / и отмонтируйте обычную файловую систему /usr:
cd /
umount /mnt
Теперь вы должны иметь возможность перезагрузить ваш компьютер как обычно с созданной дискеты. Не забудьте перезапустить lilo (или выполнить то, что вы сделали не правильно) после перезагрузки!
Как было упомянуто выше, существует другая общая альтернатива. Если у вас
к счастью имеется рабочее ядро находящееся на разделе / (например
/vmlinuz), то вы можете использовать его для загрузочной
дискеты. Предполагая все вышеприведенные условия, и что наше ядро находится
в /vmlinuz, то просто сделайте изменения в вышеприведенном
примере: измените /dev/hda3 на /dev/hda1 (корневая
файловая система), /mnt/src/linux на /mnt, и
if=zImage на if=vmlinuz. Замечание о том как получить
доступ к /mnt/src/linux может быть проигнорировано.
Используя LILO с большими дисками (больше чем 1024 цилиндра) может вызвать проблемы. Смотрите LILO mini-HOWTO или документацию для помощи в этом случае.
Это может быть серьезной проблемой. Начиная с ядер после 1.0 (примерно
20 апреля 1994), программа названная `update', которая
периодически сохраняла буфера файловой системы была
изменена/заменена. Возьмите исходные тексты программы `bdflush'
(вы должны найти их там где вы брали исходные тексты ядра), и установите
эту программу (вы вероятно захотите запустить старое ядро пока вы делаете
это). Эта программа сама установится как `update' и после
перезагрузки, новое ядро не будет больше выражать недовольство ее
отсутствием.
У вас вероятнее всего ELF компилятор (gcc 2.6.3 и выше) и исходные
тексты ядра 1.2.x (или более раннего). Обычное исправление заключается в
добавлении этих трех строк в начало файла arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Это заставит выполнять компиляцию ядра 1.2.x с библиотеками a.out.
Достаточно странно, но много людей не могут заставить работать свои устройства ATAPI, потому что существуют некоторые вещи, который могут быть сделаны неправильно.
Если ваш CD-ROM единственное устройство на отдельном интерфейсе IDE, то оно должно быть выставлено как ``master'' или ``single''. Предположительно это наиболее общая ошибка.
Creative Labs (для некоторых) поместил интерфейс IDE на свои звуковые карты. Однако это приводит к интересной проблеме, заключающейся в том, что некоторые люди имеют только один интерфейс, много имеют два IDE интерфейса, встроенных в материнские платы (обычно на IRQ15), так что общая практика в том, чтобы сделать интерфейс на soundblaster третим IDE портом (IRQ11).
Это вызывает проблему с linux в том, что в версиях 1.2.x не поддерживается третий IDE интерфейс (эта поддержка началась где-то в серии 1.3.x, но это было для разработчиков, помните об этом, и не был автоматической пробы). Для того чтобы заставить это работать у вас есть несколько возможностей.
Если вы уже имеете второй IDE порт, то существует вероятность, что вы не используете его или у вас не два устройства на нем. Уберите привод ATAPI со звуковой карты и поместите его на второй интерфейс. Затем вы можете запретить интерфейс на звуковой карте, что сохранит вам IRQ.
Если у вас нет второго интерфейса, то переключите интерфейс на звуковой карте (только не часть работающую со звуком) на использование IRQ15, как второй интерфейс. Это должно работать.
Если по некоторым причинам ваше устройство должно быть на так называемом
``третьем'' интерфейсе, или в случае других проблем возьмите ядро версии
1.3.x (например ядро 1.3.57 имеет такую поддержку), и прочитайте файл
drivers/block/README.ide. Там существует гораздо больше
информации.
Возьмите новую версию программы route и любую другую программу,
которая выполняет манипуляцию маршрутизацией.
/usr/include/linux/route.h (который является файлом в
/usr/src/linux) был изменен.
Обновите ядро по крайней мере до версии 1.2.1.
Не используйте файл vmlinux, созданный в
/usr/src/linux как образ загрузки; Правильным образом загрузки
является [..]/arch/i386/boot/zImage.
Измените слово dumb на linux в записи для консоли в
файле /etc/termcap. Вам также может понадобиться создать запись в
terminfo.
Исходные тексты ядра linux включают некоторое количество заголовочных
файлов (файлов, чьи имена заканчиваются на .h), на которые
ссылаются стандартные заголовочные файлы в /usr/include. На них
обычно ссылаются примерно так (где xyzzy.h должен быть чем-то в
/usr/include/linux):
#include <linux/xyzzy.h>
Обычно существует ссылка, названная linux в /usr/include
на директорию include/linux в исходных текстах вашего ядра
(/usr/src/linux/include/linux в обычной системе). Если эта ссылка
находится не там, или указывает на неправильное место, то некоторые вещи
вообще не будут компилироваться. Если вы посчитали, что исходные тексты ядра
занимают слишком много места на диске и удалили их, то это скорее всего
вызовет проблему. Другая проблема может возникнуть при неправильных правах
доступа на файлы; если ваш администратор установил umask в такое значение,
которое не позволяет другим пользователям видеть его файлы по умолчанию, и
вы разархивировали исходные тексты без опции p (сохранение прав
доступа), то эти пользователи не смогут пользоваться компилятором C. Хотя
вы могли бы воспользоваться командой chmod для исправления этого,
но вероятно более легко заново разархивировать заголовочные файлы. Вы
можете сделать это также, как и со всеми исходными текстами, но только с
дополнительным аргументом:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Замечание: ``make config'' заново создаст ссылки в
/usr/src/linux, если они отсутствуют.
Следующие несколько показательных команд могут быть полезны для тех кто не знает как увеличить некоторые программные предельные значения The following few example commands may be helpful to those wondering how to increase certain soft limits imposed by the kernel:
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages