Re: udev_retry
Andrew Benton wrote: > On Thu, 15 Sep 2011 21:46:08 +0100 Matthew Burgess > wrote: > >> So, based on the above, 5 is definitely something to look into I >> think. If that doesn't pan out, then I think option 2 is the next >> 'least worst'. > > Or you could set the time with a bootscript. Only if you know which RTC-class device the system is using. :-) (It's probably required to set the time with a bootscript if you're using NTP, though I don't know for sure. AFAIK there aren't any standard uevents for "the network has been configured" that could be used as a trigger.) > Same with alsactl restore. run them after udev has finished and > everything's mounted. Why do these things have to be done by udev? Originally, they would pollute the udev database with failed events, until those events were retried. Of course, that's not relevant anymore, and even when it was, it was just a couple extra zero-byte files in a tmpfs. Upstream (at least, udev upstream) is *really* pushing hard for everyone to use something like systemd, though, where everything is event-driven. I don't think that's a good idea (except as a hint for now) for LFS, but I don't think it's too bad to go that route where it makes sense. 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
Re: udev_retry
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> Or sysconfig, or wherever similar scripts are put in Bruce's new setup.
>
> Just to mention the layout, what I have is:
>
> /lib/services (network service scripts)
> /lib/lsb(symlink to /lib/services/, init-functions)
>
> /etc/sysconfig (All config files here, no subdirectories)
> /etc/init.d (symlink to /etc/rc.d/init.d/ for
> compatibility/convenience)
>
> /etc/rc.d/{init,0..6,S}.d (standard bootscript directories)
So /etc/sysconfig/udev_retry.conf (or udev_basic.conf, if we opt to run
the uevents for just the block subsystem, and replay everything in what
we call udev_retry today) would work.
Looks good to me.
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
Re: udev_retry
DJ Lucas wrote: > > Bryan Kadzban wrote: > >> 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. Probably. :-) > 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. It'd work in /lib/udev/devices/disk/by-blah/, yes. Though a static symlink there would require that the kernel never change the sd* device ordering (otherwise the symlink will point at the wrong block device). This is a *very* theoretical corner case anyway, though, because nothing today (at least in upstream rules) uses the usb-db program to create disk symlinks. It's only used for TTY device and NIC descriptions (which only set an entry in the udev database; they don't use this entry for anything), and sound cards (and the comments imply this is only used by pulseaudio). 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
Re: udev_retry
On Fri, 16 Sep 2011 19:30:58 +0100 Matthew Burgess wrote: > > And, as mentioned before, you want to run the alsactl restore stuff on > device discovery in order to support hot pluggable sound devices. If > it's done as a one-shot bootscript, manual configuration would be needed > if you plugged in a sound device after boot. > Hot plugging a sound device is a corner case that is easily covered with a udev rule. The udev rule would fail during boot if /usr is on a separate partition but a boot script that runs alsactl restore after /usr is mounted would work. Why not have the best of both worlds; a boot script to set sound levels and a udev rule to cover hot plugged devices? Incidentally I used to use an amplifier with a usb sound card in it. This udev rule used to reset the sound levels if the amplifier was turned on after boot: ACTION=="add", DRIVERS=="snd-usb-audio", RUN+="/usr/bin/alsactl restore %n" Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev_retry
On 16/09/2011 19:09, Bruce Dubbs wrote: > Andrew Benton wrote: >> On Thu, 15 Sep 2011 21:46:08 +0100 >> Matthew Burgess wrote: >> >>> So, based on the above, 5 is definitely something to look into I think. >>>If that doesn't pan out, then I think option 2 is the next 'least worst'. >>> >> >> Or you could set the time with a bootscript. Same with alsactl restore. >> run them after udev has finished and everything's mounted. Why do these >> things have to be done by udev? > > You want to set the time as early as possible because some undesirable > things may happen, like unnecessary fsck of partitions. This can > especially be a problem for those users that have their time set as > local time. And, as mentioned before, you want to run the alsactl restore stuff on device discovery in order to support hot pluggable sound devices. If it's done as a one-shot bootscript, manual configuration would be needed if you plugged in a sound device after boot. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev_retry
Andrew Benton wrote: > On Thu, 15 Sep 2011 21:46:08 +0100 > Matthew Burgess wrote: > >> So, based on the above, 5 is definitely something to look into I think. >> If that doesn't pan out, then I think option 2 is the next 'least worst'. >> > > Or you could set the time with a bootscript. Same with alsactl restore. > run them after udev has finished and everything's mounted. Why do these > things have to be done by udev? You want to set the time as early as possible because some undesirable things may happen, like unnecessary fsck of partitions. This can especially be a problem for those users that have their time set as local time. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev_retry
Bryan Kadzban 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
Re: udev_retry
On Thu, 15 Sep 2011 21:46:08 +0100 Matthew Burgess wrote: > So, based on the above, 5 is definitely something to look into I think. > If that doesn't pan out, then I think option 2 is the next 'least worst'. > Or you could set the time with a bootscript. Same with alsactl restore. run them after udev has finished and everything's mounted. Why do these things have to be done by udev? Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
