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, [EMAIL PROTECTED]
The technology that is
Stronger, better, faster: Linux
signature.asc
Description: This is a digitally signed message part
