Bug 56938

Just as with 2.2.19-6.2.1 you have to make an initrd and use that in lilo.conf...
can you check if you have done that ?

Sorry I didn't mention it in my first post: I did make an initrd file and 
configured lilo.conf to use it. 
I do not know hot to check if everything went fine with initrd creation and/or 
if the system is using it during the boot sequence.
I can send you the output of mkinitrd -v command:

[root@myhost /root]# mkinitrd -v /boot/initrd-2.2.19-6.2.12.img 2.2.19-6.2.12
Using modules:  scsi/atp870u.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.26227/bin/sh
/sbin/insmod.static -> /tmp/initrd.26227/bin/insmod
/lib/modules/2.2.19-6.2.12/scsi/atp870u.o -> /tmp/initrd.26227/lib/atp870u.o
Loading module atp870u with options

I cannot see any sign about DAC960 module; the command instead includes the 
driver of the 'other' SCSI card installed: but that one is only used for a SCSI 
tape, not for booting. 
Do you think I should try to include DAC960 in the initrd file using the --with 
switch? I was thinking at something like
mkinitrd /boot/initrd-2.2.19-6.2.12.img 2.2.19-6.2.12 --with=DAC960 --omit-scsi-
modules

mkinitrd uses /etc/modules.conf to see which scsi modules need loading; can you 
check if the dac960 driver is listed in that ?

[root@myhost /root]# cat /etc/modules.conf
alias scsi_hostadapter atp870u
alias eth0 rtl8139
alias scsi_hostadapter1 DAC960

Hrm. That should be enough to get mkinitrd to put it in the initrd... sigh
The --with DAC960 switch is worth a try

This morning I rebooted the machine using the new initrd file created using --
with=DAC960 switch: everything is working fine now.

If I can help you to further investigate the problem with mkinitrd please let 
me know. 
From now on I will (try to) remember to use the switch whenever I will install 
a new kernel.

As this appears to be a mkinitrd bug, I'm changing the component of the bug to
mkinitrd as the kernel isn't going to fix that ;)

true -- hopefully massimo is still around?

if so, could you try running mkinitrd without --with, but add -v to i, and post
the output here?

This is the output of mkinitrd -v that ewt requested

# mkinitrd /boot/test.img 2.2.19-6.2.12 -v
Using modules:  block/DAC960.o scsi/atp870u.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.15518/bin/sh
/sbin/insmod.static -> /tmp/initrd.15518/bin/insmod
/lib/modules/2.2.19-6.2.12/block/DAC960.o -> /tmp/initrd.15518/lib/DAC960.o
/lib/modules/2.2.19-6.2.12/scsi/atp870u.o -> /tmp/initrd.15518/lib/atp870u.o
Loading module DAC960 with options
Loading module atp870u with options

I also tried
mkinitrd /boot/test2.img 2.2.19-6.2.12 --with=DAC960 --omit-scsi-modules -v
Using modules:  block/DAC960.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.15820/bin/sh
/sbin/insmod.static -> /tmp/initrd.15820/bin/insmod
/lib/modules/2.2.19-6.2.12/block/DAC960.o -> /tmp/initrd.15820/lib/DAC960.o
sed: can't read /etc/conf.modules: No such file or directory
Loading module DAC960 with options

So apparently mkinitrd is looking for /etc/conf.modules, but I only 
have /etc/modules.conf

Hope this helps

Hmmm... mkinitrd should prefer modules.conf to conf.modules.. don't know where
that's coming from.

Could you run both of those with "sh -x mkinitrd <your-options>" and mail the
output, along with the resulting initrd images, directly to me at ewt?

I have just emailed you the info requested

Got it -- thanks.

You're running a very old version of mkinitrd (it looks like version 2.3, which
is from 1999)... The conf.modules problem you're seeing is a relic from that as
far as I can tell.

I don't know if either of the test images you sent me work or not; I'm guessing
that the one created with the --with switch works, and the other one doesn't?

The only difference between them is that the disk created w/ --with does not try
to load atp870u. I suspect this is actually a bug, but it's pretty irrelevant.
If the module that tries to load atp870u prevents your system from booting, it's
a problem with that module being loaded so early in the boot
sequence.

Please let me know if the initrd created w/o the --with=DAC960 doesn't work
while the other one does. If that is the case, this is a kernel bug with that
module. If neither works, it's probably still a kernel bug.

Guess things work? Closing bug due to inactivity.