[sisyphus] depmod failed on the custom kernel

["Peter V. Saveliev" <peet@eltel.net>]

...

Приспичило собирать своё ядро (нужна была поддержка serial console и
vserver).

Последовательность действий была такая:

$ rpm -ihv kernel24-2.4.20-alt7.src.rpm
$ cd /usr/src/RPM/SOURCES
// установил исходники

$ cp /home/peet/patch-2.4.20ctx-17 .
// патч vserver.
// название совсем не по ALT, но это пока проба пера :)

$ cd ../SPECS $ mcedit kernel24.spec 
// добавил патч, проследил, с кем конфликтует, убрал конфликтную цепочку

$ rpmbuild -ba kernel24.spec
// прервал до make, но после применения патчей (кстати, это, наверное,
// можно сделать ключами...)

$ cd ../BUILD/*
$ cp ../SOURCES/*config .
// дальше долго и нудно линковал очередной конфиг в .config, делал make
// menuconfig, ставил галку для консоли, сохранял

$ mv *config ../../SOURCES/*
$ cd ../../SPECS
$ rpmbuild -ba kernel24.spec
// собрал, сложил в локальный репозитарий, сказал genbasedir. Всё.

Что в итоге:
[root@ap001 root]# depmod -a
depmod: *** Unresolved symbols in /lib/modules/2.4.20-peet0.1-smp/kernel/fs/jfs/jfs.o
depmod: *** Unresolved symbols in /lib/modules/2.4.20-peet0.1-smp/kernel/fs/nfs/nfs.o


Отсюда вопросы:
1) как это можно было сделать более правильно?
2) как можно проследить за тем, чтобы не было unresolved symbols?

К сожалению (или к счастью :) - может, научусь чему), кроме меня в
контексте задачи этим заняться некому, а сборка vserver или ядра с
serial console для Сизифа не то чтобы очень была нужна, наверное.
Поэтому приходится делать своими скудными силами.

Возможно un* symbols могли взяться как результат наложения vserver +
отключения ряда патчей (это задело radeonfb и matrox, а также ещё ряд
девайсов, которых на сервере у нас никогда не будет). Однако, подобное у
меня возникло и просто при пересборке linus-ядра для включения serial
console.

Заранее большое спасибо за помощь.

-- 
Sincerely, Peter V. Saveliev

E-mail: peet@eltel.net
Jabber: peet@jabber.ru