Aprofondint un xic m�s en el problema, et copio un missatge que detalla el problema un xic m�s (q�esti� de timing)
----------------------------------------- I've just had problem with this on an FC3 machine. mkinitrd-4.1.18-2. Actually, two problems. First was that SCSI devices are detected asynchroniously, second was that udev seems to be working asynchroniously. Quick and dirty workaround was adding "sleep 10" after "insmod /lib/sym53c8xx.ko" line, and another "sleep 10" after "/sbin/udevstart" in init script (inside initrd image). Without the "sleep" lines, init script would simply load the modules, and execute udevstart withoug waiting for things be initialized properly. When raidautorun is called, the devices are not yet detected, so it fails to initialize RAID1 device that holds physical volume (under LVM) with root partition on it. I've asked about this on Linux kernel mailing list (LKML). I got answer that this should be delt within init script that is generated by mkinitrd. In short, PCI is hot-pluggable, and everything on it is asynchronious. When driver loads, it starts asynchroniously searching for devices, which sometimes can take long time. Making assumption that things are synchronious (as mkinitrd seems to be making) is simply wrong. It takes about 5 seconds for sym53c8xx driver to detect disk devices on my dual SCSI card (integragted into motherboard) after it is loaded. One person replied that FreeBSD is waiting 15 seconds for SCSI buses to initialize. Linux dosn't waste time waiting, nor init script does. I guess with most devices and drivers this race condition that exists in mkinitrd generated init script won't be hit (drivers are fast enough in detecting the hardware). But the race condition exists, and can be a problem on certain hardware configurations. The fix made in 4.1.4 dosn't seem to affect this case. The problem here is not non-existing device node, the problem is that SCSI driver is slow in detecting disks. Should this bug be reopened? --------------------------------------------- El que ja no s� �s si usant un kernel personalitzat, sense initrd i amb els drivers compilats est�ticament, aix� tamb� passaria. Q�esti� de provar-ho. Ah! una altre detall. No s� si saps que el directori /dev antic segueix tenint la seva exist�ncia (tot i que miserable i condemnada a l'extinci�) com a directori ocult a /.dev Una tercera opci� seria crear els dispositius a /.dev, i almenys no s'esborren cada vegada que arrenques. Llavors s'ha de modificar el fitxer de configuraci� del raid per tal que vagi a cercar a /.dev enlloc de /dev Apa, bona setmana santa. Orestes. > Acabo de donar una ullada als reports dels RCB i veig que efectivament no > acaben de posar-se d'acord alhora d'assignar-ho i de moment sembla que la > gl�ria se l'emporta el mdadm i un tal Samuel diu que a ell li ha funcionat > canviat la prioritat de manera que arrenqui l'mdadm abans de l'udev ... > > De moment ja tinc dues solucions que ja est� b� :) > > Gr�cies !!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
