Bug#263169: initrd-tools orphaned?
Martin Michlmayr wrote:
* tbm <tbm@cyrius.com> [2004-09-15 11:57]:
I don't think that patch is right, but I just noticed I've never
forwarded it to Herbert. I've asked him for comment now.
Right, I got a response:
"""
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.
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.
Of course, if the user adds or removes a device, then all kinds
of strange things can happen. But this is the case for the current
initrd-tools, too.
(Currently your root sata disk /dev/hdx disk might become /dev/sdy,
if you move from kernel 2.4.x to 2.6.8. Without partition labels and
LABEL=myroot in fstab there is no chance to do a clean upgrade.)
At the moment mkinitrd does this by looking in /proc/scsi. So you can
either find out why these SATA modules aren't showing up there, or use
/proc/modules as proposed.
I had sent an EMail to the kernel developers about this some
months ago, but there was no response.
The downsides to the /proc/modules solution are:
1) You lose the loading order, so sda can become sdb etc.
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.
2) Running mkinitrd from a kernel with drivers built-in won't work.
2) is no longer as important since recent 2.6 kernels have castrated
/proc/scsi so running mkinitrd from a vanilla upstream kernel won't
work anyway.
Regards
Harri
Reply to: