NTFS-Парогон

imho - если это не x86 (т.е. ARM, MIPS, etc.) - то вы в пролёте. strip тут не при чём. логи:

> depmod -aq
> modprobe -v ufsd

в студию. и что насчёт install.sh? оно же при отработке выкидывает логи...

1)
x86 pentium3,pentium4
2)
bash-2.05b# depmod -aq
depmod: can't handle sections of type 17 /lib/modules/2.4.37.1/kernel/fs/ufsd/ufsd.o
bash-2.05b# 
bash-2.05b# modprobe -v ufsd
modprobe: Can't locate module ufsd
bash-2.05b# 
3)
с собой нет - в понедельник
приходилось править макефайлы и установочные скрипты - 
ибо там используется "uname -i"
bash-2.05b# uname -i
uname: invalid option -- i
Try `uname --help' for more information.
bash-2.05b# 

bash-2.05b$ uname --version
uname (GNU sh-utils) 2.0


ps
вот

cdfs-2.4.20-a
lm_sensors-2.9.1

cобираются без проблем

что если:

insmod /lib/modules/2.4.37.1/kernel/fs/ufsd/ufsd.o
?

>Парогон

И много они пара гонят? :)

bash-2.05b# insmod /lib/modules/2.4.37.1/kernel/fs/ufsd/ufsd.o
/lib/modules/2.4.37.1/kernel/fs/ufsd/ufsd.o: can't handle sections of type 17 /lib/modules/2.4.37.1/kernel/fs/ufsd/ufsd.o
bash-2.05b# 


ps
лог сборки
http://pastebin.com/m440e2b3a

хз. можно посмотреть (objdump -x, readelf -a) на другие модули и как-то сравнить хедеры (именно загадочные 17-е секции), но с такими заходами пока не сталкивался. возможно, что дело в каких-то модификациях именно 2.4.37 (это вроде как "новая" ветка) и оно тупо хочет что-то постарее, что было до возобновления поддержки ветки 2.4.

так что извиняй. из тупых идей - сменить компилер, но это вроде явно не тот случай.