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: