On Tue, 23 Mar 2010 04:56:05 -0400 (EDT), Arthur Marsh wrote:
> Stephen Powell wrote, on 2010-03-23 00:50:
>> 
>> OK, there are a couple of things to check.  First of all, make sure
>> you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.
> 
> grep -v \# /etc/initramfs-tools/initramfs.conf|uniq
> 
> MODULES=most
> 
> BUSYBOX=y
> 
> KEYMAP=n
> 
> BOOT=local
> 
> DEVICE=eth0
> 
> NFSROOT=auto
>

Good.

>> Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.

> $ ls /etc/initramfs-tools/conf.d/driver-policy
> ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
> file or directory
>

Good.

>> Generally, this file only exists if, during installation, you said
>> you wanted an initial RAM file system with only what is required
>> to boot the system.  If this is the case,
>> /etc/initramfs-tools/conf.d/driver-policy will likely exist and
>> specify MODULES=dep.  And that overrides what is specified in
>> /etc/initramfs-tools/initramfs.conf.  Change
>> /etc/initramfs-tools/conf.d/driver-policy to specify
>> MODULES=most too.  For now, do *not* list eata in
>> /etc/initramfs-tools/modules.  Then re-run update-initramfs,
>> re-run lilo (if lilo is your boot loader), shutdown and
>> reboot.  Let me know the results.
> 
>
> I ran:
> 
> update-initramfs -u -k 2.6.32-3-686
> 
> then rebooted with break=mount
> 
> cat /proc/modules
>
> showed lots of modules but *not* eata.
>

What happens if you don't use break=mount?
Are you using dependency-based booting?

There are four ways I know of for a kernel module to get loaded during boot:


(1) The modules can be loaded by the kernel because they are referenced,
    directly or indirectly, during the boot process.  Whether these modules
    need to be in the initial RAM filesystem or not depends on when
    during the boot process they are referenced.  If they are first referenced
    before the permanent root filesystem is mounted, they need to be in
    the initial RAM filesystem.  If the first reference is after that point,
    they don't.


(2) You can list them in /etc/initramfs-tools/modules and re-run
    update-initramfs.  This technique is used for modules which *must*
    be explicitly loaded *before* the permanent root file system is mounted.
    These modules must be in the initial RAM filesystem.


(3) The modules can be loaded by the hot-plug system.  These modules are
    loaded because an alias of the module matches an identification
    sequence of the device.  For example, on my IBM ThinkPad 600, module
    snd_cs4236 is loaded because it has an alias, pnp:dCSC0000, that matches
    an identification string for the ISA plug-and-play sound chip CS4237B.
    A card's identification string can be listed by utilities such as
    lspnp, lspci, lspcmcia, etc.  There are two kinds of module aliases:
    internal and external.  Internal aliases can be listed by the modinfo
    command.  For example: "modinfo snd_cs4236".  External aliases are
    listed in one or more files in the /etc/modprobe.d directory.  The
    ACPI "discover" process can also load modules.  This automatic loading
    can be defeated by listing a module in a "blacklist" statement.  For
    example, on my IBM ThinkPad 600, I define the following two blacklist
    statements in a file I call /etc/modprobe.d/local:
    
       blacklist snd_cs4232
       blacklist snd_wavefront

    This tells the hotplug system to ignore the internal aliases of kernel
    modules snd_cs4232 and snd_wavefront, which causes them not to be
    loaded by the hotplug system, even though they both have an alias of
    pnp:dCSC0000, which also matches my CS4237B sound chip.  snd_cs4236
    is the correct driver in my case; I don't need the other two.

    This is the preferred method for loading kernel modules that are device
    drivers for hardware devices.  Whether they need to be in the initial RAM
    filesystem or not depends on when the corresponding devices are detected.
    Things like SCSI adapters, IDE controllers, etc. are generally probed for
    *before* the permanent root filesystem is mounted, for obvious reasons.
    Things which are not likely to be required to mount the permanent root file
    system, such as sound chips, may be probed for afterward.  Typically,
    at this stage the permanent root file system is mounted read-only, but
    has not yet been mounted read-write.

    At the moment, I do not have access to a 2.6.32 kernel for the i386,
    ia64, or amd64 architectures; but on a 2.6.26 kernel for i386 I issued
    "modinfo eata" and it does not report any internal aliases.  So
    unless the module has an external alias defined in a file listed in
    /etc/modprobe.d that matches an identification string for your SCSI
    adapter, I would not expect it to be loaded automatically.  On my IBM
    ThinkPad 600, I created an external alias for the Mwave® 3780i Digital
    Signal Processor (DSP) chip used by the internal modem so that the
    corresponding kernel module, mwave, would be recognized as its device
    driver:

         alias pnp:dIBM3760 mwave


(4) Finally, a module can be listed in /etc/modules.  These modules will
    be loaded *after* the permanent root file system has been mounted
    read/write, but before any other filesystems (/home, etc.) have been
    mounted.  These modules do not have to be in the initial RAM filesystem.


So you have three options: (1) list eata in /etc/initramfs-tools/modules
and rebuild your initial RAM filesystem.  (2) you can define an external
alias for eata in a file in /etc/modprobe.d (and rebuild your initial RAM
filesystem, just in case).  Obviously, if the kernel tries to load it
before mounting the permanent root file system then the module must be
included in the initial RAM filesystem.  (3) list eata in /etc/modules.

Figure out which method works and use it.  With no internal aliases and
no aliases defined in /etc/modprobe.d, I see no reason why the kernel
would load it automatically.  eata has a dependency on scsi_mod, but
no module has a dependency on eata; so indirect loading won't happen
either.

-- 
  .''`.     Stephen Powell    <zlinux...@wowway.com>
 : :'  :
 `. `'`
   `-


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1031746955.21081791269356366755.javamail.r...@md01.wow.synacor.com

Reply via email to