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

Bug#263169: initrd-tools orphaned?

On Wed, Sep 15, 2004 at 05:28:22PM +0200, Harald Dunkel wrote:
> >The right solution in general is to establish a way to get the list of
> >SCSI drivers loaded in the system sorted in the order by which they
> >were loaded.
> This sequence is written down nowhere, AFAIK, so there is nothing
> to get.

It is (was) written down in /proc/scsi.  The ordering of the subdirectories
correspond directly to their load order.  The ordering in /proc/modules
is fine as well, except that you need to reverse it.

However, /proc/modules is fundamentally broken because it prevents
someone from installing an initrd kernel while running a kernel with the
driver built-in.

> Probably you would agree that it is sufficient to generate the
> same load sequence for all IDE, SCSI, and SATA devices on each
> reboot. If all these modules are loaded by the initrd boot script,
> then this sequence is completely under control of the initrd-tools,
> regardless of the module load history of the currently running
> kernel.

You can't assume that they are all loaded by the initrd.  You must
consider users with the drivers built-in as well users who load
modules after root has been mounted.  How else is someone going to
install an initrd kernel while running a non-initrd kernel?

> The scsi modules found via /proc/modules are _appended_ to
> the list of modules found so far. The sequence of modules
> found before mkinitrd looked into /proc/modules is not changed.
> It doesn't get worse, AFAICS. ALATBSOL.

This is broken.  For example, on a machine that boots of SATA while
also having another SCSI card with a disk attached, doing this will
cause the non-SATA SCSI disk to become /dev/sda.
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Reply to: