There is a new firewire stack in F7, but mkinitrd has not been fully updated to support it. This patch adds the waiting for fw-ohci and fw-sbp2 modules initialization, just like it's done for the older sbp2 module. This is necessary when e.g. booting from a firewire drive, so that DM/LVM doesn't get loaded too soon and fw-sbp2 doesn't try to initialize before fw-ohci finishes loading. I have tested it on my system (installed on an external firewire drive) and it seems to work.
Created attachment 158360 [details] fix mkinitrd to force waiting for fw-sbp2 initialization (same way as old sbp2 driver)
Why wait for driver initialization? Aren't you rather interested in _device initialization_?
Don't ask me, this is how things have always worked with older stack. I simply have updated mkinitrd to support the new module file and directory names. I need to boot the system from my firewire drive: propose some other method, and I can test it.
I am not familiar with Fedora's initrd, as I never used Fedora myself. I even switched all my PCs which had different (usually initrd based) boot sequences to initrd-less setups, thus never had the need to dig into the innards of any initrd. The thing with the old sbp2 driver is: *If* ieee1394 and ohci1394 were already up and running as early enough to have any SBP-2 devices already discovered as such, then the "modprobe sbp2" process would synchronously perform SBP-2 login, SCSI inquiry, and further SCSI stuff like asking for cache data and disk size until the /dev/sd* was ready. --- But if ieee1394 would come to know of the SBP-2 device just a little bit too late, then "modprobe sbp2" would return quickly, and the rest which I described would have been done later by a kernel thread. Now, the new drivers work a bit different: Similar things as about ieee1394 and ohci1394 can be said about fw-core and fw-ohci. But no matter if fw-sbp2 was kicked on before or after fw-core got to know about the SBP-2 device, fw-sbp2 will perform the SBP-2 login, SCSI inquiry and so on *asynchronously* as a delayed work, in the context of the kernel's event queue thread. In effect, the "modprobe fw-sbp2" process (or with mainline 2.6.22: modprobe firewire-sbp2) will always return quickly before all the SCSI setup was done. Or that's what I understood about the implementation. But again, whether "modprobe sbp2" would synchronously set up the respective /dev/sd* --- or would only prepare for deferred asynchronous setup --- has always been a matter of luck, depending on the timing of ohci1394 and ieee1394 and, notably, on the timing of the SBP-2 device's firmware and HDD mechanism itself. So, the only sane thing to do is to - load all modules which are necessary (ideally on demand per module alias as soon as the kernel detected a hardware), - wait until the desired /dev/sd* with the later root filesystem on it appears. However, the SCSI folks have implemented a mechanism which provides a synchronization point for initrds and the like. The mechanism works by loading a certain dummy module. (I am too lazy right now to look up this module's name. scsi_wait_scan or something like that.) This modprobe would block until all SCSI drivers which are integrated with this framework told the module that they finished scanning. I haven't looked into the details of this framework but it may be possible to add support for it in sbp2/fw-sbp2. I am using http://bugzilla.kernel.org/show_bug.cgi?id=3225 as my reminder to investigate this when I got time.
Fedora's initrd is using a custom "stabilized" function for firewire, usb and other things, which seems to check existence and mtime of its argument every once in a while (the default is 0.75 seconds). If these things haven't changed since the last check, it proceeds. I'm not sure how robust this apporach is, but that's how things worked with the old stack and it definitely fixes the problem for me in the new stack - maintainers simply forgot to update the module names. Check the patch for the actual paths that it's checking.
Actually, bug 238606 should be solved first, so I'm adding a dependency on that.
Comment on attachment 158360 [details] fix mkinitrd to force waiting for fw-sbp2 initialization (same way as old sbp2 driver) The bug 238606 has been solved with latest rawhide kernels, and the correct mkinitrd patch has been submitted to bug 231708, so this bug can be closed.
*** This bug has been marked as a duplicate of 231708 ***