Nathan Coulson wrote: > Another thought (one I have not actually tested, forgive me if It's > not possible) is trigger only block devices in the first pass, then > try devices/subsystems on the 2nd pass?
DJ Lucas wrote: > Can we not simply re-trigger all known affected subsystems with a > subsystem match? Ooo, interesting. I believe either of these should work fine. (It would also be possible to make udev_retry blindly retry *all* events, but that will make it take slightly longer to finish the settle call, as well. :-) ) > Now, if that would work well enough, then just add a configuration > file for the udev_retry bootscript so that it can be extended in BLFS > for say ALSA, and then parse the list. Yeah. It would also work to make the pre-checkfs/pre-mountfs udevadm trigger call have a list of subsystems to trigger, of course, if we triggered just the block subsystem by default (as Nathan suggested). > for SUBSYSTEM in `grep -v '^#' /etc/udev_retry.conf` Or sysconfig, or wherever similar scripts are put in Bruce's new setup. But yeah. > you could even write a message for each one if you wanted to have > more verbose output in the event of a failure, or a stepping like we > do in mountvirtfs. I like the mountvirtfs / modules scripts' approaches, with a config file containing a list of things to process. At that point it's only a question of whether we want to use this method to decide what devices are necessary for checkfs/mountfs, or we want to use this method to decide what devices might need to be retried. I think that finding the devices necessary for checkfs/mountfs might be a bit more fragile, actually; we would have to ensure that none of the udev rules for the storage devices require anything else. (They should not, since those might be the first events triggered, but who knows what might happen in the future, if upstream lives in a world where every system runs an initramfs that mounts these FSes for them.) Although, hmm. Either way here, there's a possible problem, with symlinks for disk devices. If the USB ID file isn't present, then it's possible that the /etc/fstab entry for /usr refers to a symlink that relies on this file. Of course, in that case you're just as screwed even if you have an initramfs that does this mounting (since the initramfs doesn't have the file either), so it's probably not worth defending against.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
