Bug#271038: Work around
I saw that in one of the earlier messages and actually tried it - still
If you build the initrd.img with -k it leaves the temporary files behind
and the loadmodules on my system contains:
modprobe -k vesafb > /dev/null 2>&1
modprobe -k fbcon 2> /dev/null
modprobe -k unix 2> /dev/null
modprobe -k aic7xxx
modprobe -k sym53c8xx
modprobe -k sd_mod
It still results in the above mentioned kernel panic. I even tried
assuming it was some kernel dependancy stuff that failed and loaded
scsi_mod manually too - still the same.
So - is this problem something completely different? Fact is I got 5 of
these machines in various hard to access locations (10000 km from where
I prefer to be physically located myself) and they have all been running
upgrades with NO problem whatsoever until the 2.6.8 - and also this is
the only type of machine I've had problems with. The only different I
can think of is that all other machines I've been updating have been
booting from IDE drives - whereas this is the only one booting from SCSI.
By the way - here's my current working kernel version + /proc/scsi:
ucndb:/proc/scsi# uname -a
Linux ucndb 2.6.7-1-686-smp #1 SMP Thu Jul 8 06:08:37 EDT 2004 i686
ucndb:/proc/scsi# ls -lsa
0 dr-xr-xr-x 4 root root 0 Sep 28 12:04 .
0 dr-xr-xr-x 134 root root 0 Sep 27 14:53 ..
0 dr-xr-xr-x 2 root root 0 Sep 28 12:04 aic7xxx
0 -r--r--r-- 1 root root 0 Sep 28 12:04 device_info
0 -r--r--r-- 1 root root 0 Sep 28 12:04 scsi
0 dr-xr-xr-x 2 root root 0 Sep 28 12:04 sym53c8xx
Interesting part is this is build with an EMPTY /etc/mkinitrd/modules on
the 2.6.7 kernel. So I think this problem might be different.
Any ideas? Or any other information I can provide? As mentioned before
- I've got full online access to these machines - only tricky part is if
they hang during reboot.