FS#13079 - USB images - why did we need usbdelay?

Attached to Project: Release Engineering
Opened by Gerhard Brauer (GerBra) - Sunday, 01 February 2009, 14:19 GMT
Last edited by Gerhard Brauer (GerBra) - Thursday, 30 July 2009, 06:07 GMT
Task Type Bug Report
Category ArchISO
Status Closed
Assigned To Aaron Griffin (phrakture)
Gerhard Brauer (GerBra)
Dieter Plaetinck (Dieter_be)
Architecture All
Severity Low
Priority Normal
Reported Version 2009.01-beta
Due in Version 2009.08-RC
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

We should research why we need the usbdelay parameter do really detect and access the usb device in archiso hook. Normally this should be handled from udevadm trigger and settle functions.
Maybe its a result of new software we use since 2008.06 (kernel26, udev,...).

Reported bug (and fixed with usbdelay) for 2009.01 was  FS#12896 
This task depends upon

Closed by  Gerhard Brauer (GerBra)
Thursday, 30 July 2009, 06:07 GMT
Reason for closing:  Implemented
Additional comments about closing:  New method of boot device detection since 2009.08-beta1 makes the usbdelay function and parameter obsolete. New cd iso and usb images don't have it anymore.
Comment by Aaron Griffin (phrakture) - Wednesday, 04 February 2009, 23:13 GMT
Well, it's because of the crappiness of usb-storage. usb-storage may actually detect a device, but the device may not be "ready" at that time. This makes sense for actual external hard drives that need to "spin up" and the like. So, usb-storage includes a delay of 5 seconds (default) before adding a node in /dev.

This means that udev trigger/settle doesn't work, as the uevent is handled by usb-storage, it's just sitting there sleeping. udev doesn't know that, and thinks everything is fine.
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 19 July 2009, 13:42 GMT
Can we come up with a proper fix on the short term, or do we stick to the delay for now?

Loading...