On Sat, Apr 09, 2005 at 02:49:56AM -0400, Greg Folkert wrote: > > Bad news... I can't reproduce this problem, even on your machine. :) Can > > you tell me what kernel you were running at the time you saw the problem? > > Your initial report was from a machine that was running 2.4.27-1-smp, so I > > assume you got this kernel working using MODULES=most in mkinitrd.conf and > > then reported the bug; does that agree with what you recall of the > > situation? > Well, that kernel that is currently running also has this problem. > You need to compare the modules sym53c8xx and sym53c8xx_2, you will see > they are the same module, different location. I understand that from your earlier mail. But please see the contents of /tmp/mkinitrd.29466/, which was created using MODULES=dep, and properly includes the copy of the module named sym53c8xx_2.o. :) > > I suspect this problem was caused by a module name change in the kernel, > > where earlier you might have been using sym53c8xx instead of sym53c8xx_2, so > > the wrong driver name was detected based on which module was currently > > running. Fixing this in initrd-tools therefore probably means introducing > > some special-casing to mangle this module name according to the selected > > kernel version. > This is probably what the problem is. But, I still have noticed, that > installing any kernel still gets this error. You can go ahead and remove > and re-install any kernel you want. If you do this, I am sure you should > be able to discover it. I can recover with tftp booting, so it shouldn;t > be to bad. > > If you are still able to reproduce this bug on your system, please let me > > know how it's manifesting, in case I'm overlooking something. > I am sure, that (re)installing any kernel will give you the problem. > I have given you sudo access and in the sudo group. > I only ask that you don't screw up /home if you need to I can re-back it > up. Pretty much the whole reason I couldn't let you in, was the firewall > changes would have made a service interruption for us. I had to open > undead up to more than one external host for ssh. > You realize, the reason it is called undead, the machine was built on > July 10, 1994 shipped to the company I worked at. I have been the admin > for that machine since then. They took it out of commission and gave it > to me. > If you still cannot reproduce it, lemme know, I should be able to. Yep, still can't reproduce it. See the contents of /boot/initrd.img-2.4.27-1-smp, built with dpkg-reconfigure kernel-image-2.4.27-1-smp after setting MODULES=dep in /etc/mkinitrd/mkinitrd.conf. You're welcome to inspect it to your satisfaction, boot to it, etc. The only scsi driver being pulled in is sym53c8xx_2. Building a similar initrd with MODULES=most gave an equivalent /loadmodules file, though of course it included many more kernel modules on the image. The previous version of this image has been saved as /boot/initrd.img-2.4.27-1-smp.bak. Also, the initrd.img-2.4.27-2-smp that you have on there, created Mar. 22, contains a correct /loadmodules file that references sym53c8xx_2; so I'm pretty sure this isn't a magic fingers effect. :) Of course, I know that trying to reconfigure the 2.6 kernel you have on there would give an error, because the module name has been changed *back* to sym53c8xx in 2.6 even though it's in a subdir named sym53c8xx_2; but the original problem you reported had to do with 2.4.27, so I'm pretty sure that's the change-of-preferred-driver problem I described. Thanks, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature