Bryan Kadzban <br...@kadzban.is-a-geek.net> wrote:
>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. Unfortunately, I think inevitably we'll have to add it, but we aren't there quite yet. I'm pretty sure upstream will eventually force it upon us. If a small /usr is in the initrd, it'll work. Does the /lib/udev/devices get a recursive copy? If so, then can't a minimal symlink tree be created to account for a particular device...and if not, then in rootfs before real / is mounted. --DJ Lucas -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
