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

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



On Tue, 29 Mar 2005 14:15:19 +0200
Frans Pop <aragorn@tiscali.nl> wrote:

> On Friday 25 March 2005 15:02, Ian Bruce wrote:
> > On Thu, 24 Mar 2005 20:38:28 -0500
> >
> > Joey Hess <joeyh@debian.org> wrote:
> > > The installer tries to load all modules in the same order that
> > > Debian will load them on boot, to avoid this kind of
> > > inconsistency. All I can think of is that there must be some
> > > difference between the modules that are loaded or the order they
> > > are loaded. This should be reflected in the kernel messages.
> 
> I have compared the load order by the installer and the order in the 
> loadmodules file. The order seems almost _reversed_, not the same at
> all. The third and sixth columns are cross-references to the other.

<lists deleted>

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.

> 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

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?

> > There is one other oddity I noticed, which may or may not be
> > related. When I retry the installation (as I have many times), at
> > the "Partition disks" stage (where I choose "manual"), the existing
> > ext3 partition on hda is never recognized, although the existing
> > swap partition on hdc is. I don't understand why that would happen.
> 
> What do you mean by "recognized"? The screen you get after choosing 
> "manual partitioning" should look something like [1] (only probably in
> English, not in Dutch ;-).
> 
> [1] http://home.tiscali.nl/isildur/d-i/nl/partman.html#09.03

I mean it sees the drive, but not the partition table, on hda, although
it does see the partition table on hdc. It looks something like this:

    IDE1 master (hda)   540MB
    IDE2 master (hdc)    85MB
        #1 primary       85MB   swap

I'll make one of those screenshots, if you'll tell me how.

The partition table on hda is quite definitely there; GRUB finds it with
no problem. It seems to me that this must be related to the reboot
failure, somehow.


-- Ian Bruce



Reply to: