ORG

Mam następujący problem.
Mam zainstalowanego Slacka 10.0 na dysku Seagate Barracuda 160 GB i działa sobie do tej pory na kontrolerze ATA33 wbudowanym w płytę główną. Dokupiliśmy z shr kontroler ATA133 i tutaj pojawia się właśnie problem.
Namęczyłem się dość długo żeby skompilować sterownik, bo oczywiście sterowników pod slacka nie dołączyli. Szukałem cały dzień źródeł (które w Makefile'u miały błąd, OCZYWISCIE :D), skompilowałem. Jak podłącze do kontrolera jakiś inny dysk to po wcześniejszym załadowaniu
insmod /usr/src/linux/drivers/scsi/iteraid.o # (oryginalny sterownik)
mogę go normalnie zamontować. (mount /dev/sda1 /mnt/kaka)
Odłączyłem drugi dysk, a ten 160 GB podpiąłem do kontrolera ATA133. Później

dodałem w /etc/rc.d/rc.modules na końcu linijkę:

insmod insmod /usr/src/linux/drivers/scsi/iteraid.o

zmieniłem w /etc/fstab:

hda1 -> sda1

hda2 -> sda2

oraz dodałem drugi wpis w lilo.conf

image = /boot/vmlinuz

root = /dev/sda2 # (sda1 - swap)

label = apfrr

read-only

oraz zmieniłem boot=/dev/sda
Reboot systemu, wybieram opcję 'apfrr' i już niedługo otrzymuję komunikat, że

'root=' w lilo jest źle ustawione no i piękny i powszechnie znany:

'kernel panic: Unable to mount...'
Co robię nie tak?

Ewentualnie jak zainstalować linuxa prosto na dysk podłączony do kontrolera?

Instalator slacka bootowany z płytki nie ma sterowników do tego kontrolera i nie za bardzo chce wykrywać ten dysk wtedy.

Help?
P.S. Yaboll wybacz. :D

Rozkladam raczki bo nigdy si nie bawilem z kontrolerami zewnetrzymi...
Zdaje mi sie jednak ze zaladowanie modulu do tego kontrolera jest robione za pozno.
Kopnij posta na jakas grupe linuxowa

pl.comp.os.linux

albo

alt.pl.comp.os.linux.slackware
Z naciskiem na ta pierwsza bo na slackwareowej sie malo dzieje.

Napisałem na www.linux.com.pl/forum/ i mi koleś odpisał, że moduł ładowany za późno i żebym albo wkompilował do jądra albo użył initrd. Z initrd chodzi o dodanie w lilo.conf

initrd=/usr/src/linux/drivers/sci/iteraid.o

czy moze o cos bardziej skomplikowanego? Nigdy tego nie uzywalem do tej pory :).
Dzieki za odp. jak zwykle ;)

nie

initrd musisz sobie wygenerowac.
Pogoogluj na necie jest duzo opisow :)
Albo poczytaj dokumentacje /usr/src/linux/Documentation/initrd.txt

Wgrywam do katalogu moduł ze sterownikiem i uruchamiam z tego samego katalogu mkinitrd, potem w lilo.conf dodaje linijkę initrd=/boot/initrd.gz, to starczy?

Póki co przerobiłem config.in i Makefile w kernelu żebym miał podczas konfigurowania kernela dostępny ten sterownik do wyboru i jak jutro będę w Poznaniu to spróbuję to naprawić w ten sposób.
Thx za info.
Poza tym to pozostaje nam już tylko jeden problem ;). Co jakiś czas system przyjmuje kernel panic i nie wiemy czemu. Komunikat shr widział tylko raz, ale nie spisał. Nie mogliśmy go odczytać, bo działo się to zawsze jakoś w nocy, że zanim się skapnęliśmy to zdążył się wygasić monitor, a że klawa nie robi nic poza mryganiem capslockiem i scrolllockiem (nie reaguje na przyciski) to nie mogliśmy monitora zmusić żeby coś wyświetlał. Znalazłem już na google jak wyłączyć wygaszanie monitora to może się uda coś wykombinować w weekend :).
Edit: Shr się udało spisać co się pojawia:
server login: kernel BUG at filemap.c:936!

invalid operand: 0000
<0>Kernel panic: Aiee, killing interupt handler!

In interrupt handler - not syncing

Poradziłem sobie z tymi sterownikami. Wkompilowałem je na stałe do jądra. Wyłączyłem kontroler na płycie głównej, wyjąłem zbędne urządzenia i system chodzi już 17 godzin bez kernel panica. Zdaje mi się, że kontroler na PCI miał konflikt z kontrolerem na płycie głównej, bo wczesniej nie mieliśmy takich historii. Czas pokaże ;-).