On Sat, 2007-12-01 at 21:52 -0500, Dave Jones wrote:
> On Sat, Dec 01, 2007 at 01:23:09AM -0500, David Zeuthen wrote:
>
> > I know that on Fedora (at least in the past) we play some really ugly
> > tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the
> > devices are in a specific order (scsi_wait_scan.ko etc.). Seems
> > literally like a waste of time; better fix the rest of the OS not to
> > rely on things like kernel names.
>
> We scsi_wait_scan for the root disk to come up.
Uhm no.
First, you hardly have to use a kernel module to wait for a device to
appear; come one, this is uevent 101: a single udev rule that
investigates the block device and exits the initramfs if it's indeed the
root fs will suffice. Or, if you want to rewrite all of udev like Peter
has done, just hook into the uevent event processing yourself.
Second, the point of scsi_wait_scan.ko is to make the SCSI stack wait
for all scans to have finished before uevents are generated. A side
effect of this is that the order is deterministic; e.g. since events are
only generated when all devices have been detected, one can send them in
order.
> We don't enforce any kind of ordering.
Reality also suggest otherwise. Just try an old livecd image (F8t3 will
do I think) using an initramfs from mayflower (using udev; waiting only
for the rootfs) vs. a newer one using an initramfs from mkinitrd. In
the former the devices are randomly assigned; in the latter they're
not...
As an anecdote, the former freaked Anaconda out as I wanted to install
to /dev/sdf (the hard disk in my box; /dev/sda through /dev/sde was my
disk tower). Which again confirms we do stupid things in the initramfs
because user space is just utterly broken.
In conclusion: scsi_wait_scan.ko is a stupid stopgap fix because some
people can't be bothered to fix their user space. Fedora is an example
of that. The price that we all pay is that it takes longer to boot for
_everyone_.
There's a host of other problems with mkinitrd that I won't go into
here.
David
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
