[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#300870: install report: Debian-Installer fails on old IBM PC

Ian Bruce wrote:
> It turns out that in the mkinitrd script there is a function called
> "print_ide_modules()" which is responsible for most of the contents of
> this "loadmodules" file. It doesn't appear to do any kind of hardware
> detection. It just runs "find" on the
> /lib/modules/<version>/kernel/drivers/ide/pci directory, the output of
> which depends only on the order that the files in that directory were
> originally copied into it.
> Notice that both of the lists you quoted are (mostly) alphabetically
> ordered, the first in reverse. This is undoubtedly a result of modules
> being copied into various directories in that order; "for x in *" would
> do it. The implication is that neither the installer nor mkinitrd is
> particularly concerned about the order in which IDE modules are loaded.

Right.. I should have said that the installer tries to match the load
order of the installed system within blocks for a single subsystem --
things like loading ethernet interface modules in the same order, and
loading ide-core after all the pci ide chipset drivers. Necessities of
the installation may result in it loading network modules before ide
drivers or the like.

Here's a reworking of Frans's lists that may make this more clear:

installer			reboot
---------			------
3c59x				(unsure what part of the initrd loads these)
(pci ide chipset drivers)	(pci ide chipset drivers)
piix				pdc202xx_new
via82cxxx			adma100
trm290				aec62xx
triflex				alim15x3
slc90e66			amd74xx
sis5513				atiixp
siimage				cmd640
serverworks			cmd64x
sc1200				cs5530
rz1000				cy82c693
pdc202xx_old			generic
pdc202xx_new			hpt34x
opti621				hpt366
ns87415				ns87415
hpt366				opti621
generic				pdc202xx_old
cy82c693			piix
cs5530				rz1000
cmd64x				sc1200
cmd640				serverworks
amd74xx				siimage
alim15x3			sis5513
aec62xx				slc90e66
adma100				triflex
(misc others)			(misc others)
ide-detect			ide-detect
ide-disk			ide-disk

BTW, you're right that there's a high correlation between the order the
modules are on disk/ramdisk and the load order for the pci ones, since we do
use find. The reversal of the order is interesting; they're in the udeb
in the same order that find finds them on disk from the kernel package.
Also, the correlation is not perfect, somehow piix is loaded first instead
of later by the installer (unless you loaded piix first by hand).

> > In this case the problem could well be the reversed load order of the
> > piix and generic modules.
> I tried hacking the mkinitrd script to reverse the relative order of
> these two modules, and I also tried eliminating all the other IDE
> modules except those. Neither change fixed the problem.
> modprobe -k  vesafb > /dev/null 2>&1
> modprobe -k  fbcon 2> /dev/null
> modprobe -k  unix 2> /dev/null
> modprobe -k  piix > /dev/null 2>&1
> modprobe -k  generic > /dev/null 2>&1
> modprobe -k  ide-detect
> modprobe -k  ide-disk

So it's not an ordering problem at all..?

> The installation floppies still have no difficulty at all with this
> hardware. What file on them controls module loading? Perhaps some module
> parameters are required? I could change mkinitrd to produce exactly the
> same module load order as during installation, but it's not clear
> to me that this will work either. Any suggestions?

Most module loading, except for a few exceptions such as getting the
frame buffer and essential acpi stuff loaded as the installer boots, is
performed by /bin/hw-detect. We don't pass any parameters to ide pci
modules unless the user tells us to (in expert mode). ide-detect and
ide-disk don't get any special params by default either.

SEE Shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: