On Sun, 2005-04-10 at 01:20 -0700, Steve Langasek wrote: > 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. :) Correct. It is doing everything right. Except for when it reboots. The module it WANTS to load at boot-time is sym53c8xx.o, which just so happens is not there. But sym53c8xx_2.o is, but won't load it. Therefore, the way I got around this was to copy the sym53c8xx_2.o and replace sym53c8xx.o in the proper place. If you do the dpkg-reconfigure, it will still pull the sym53c8xx_2.o and not sym53c8xx.o. Causing boot problems again. I did have to add /etc/mkinitrd/files with the full path to the module to get around this. I did remove this file. > > > 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. Okay, I am working to reproduce this right now, but I'll need to be in my office to boot it. I'll let you know > 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 for all your work on Debian and this problem, Steve. -- greg, greg@gregfolkert.net The technology that is Stronger, better, faster: Linux
Attachment:
signature.asc
Description: This is a digitally signed message part