dbn.lists at gmail.com
Thu Jun 28 06:31:57 PDT 2007
On 6/27/07, alupu at verizon.net <alupu at verizon.net> wrote:
> 686-pc-linux-gnu (B)LFS, 220.127.116.11,
> On my system, there's plenty of 'modalias' files all
> over the place ('/sys/class', '/sys/devices')
> but not in '/sys/bus'.
> The document looks up-to-date (for example, the word
> "18.104.22.168" can be seen in a couple of places).
> What gives? Something wrong with my system?
I'm on 2.6.20 and there are still modalias files under
/sys/bus/*/devices/*/modalias. That may have changed in 2.6.21,
though. sysfs is not exactly stable and changes pretty often. The
version number you see is just a reference to the version of the
kernel used in the book. That text is not necessarily up to date.
> 2. In 'udev_retry':
> 'for file in /dev/.udev/tmp-rules--* ...'
> On my system '/dev/.udev/' contains subdirectories
> 'db', 'failed' and 'names', with occasional sightings
> of subdirectory 'queue' (during boot).
> What gives?
> Could my 'failed' be the elusive 'tmp-rules--*'?
> I didn't spot any rules there.
No. tmp-rules--* are needed only occasionally when the persistent
net/cdrom rules run. If your hardware hasn't changed, then the rules
don't need to be rewritten. Remove /etc/udev/rules.d/70-persistent*
and you should see the tmp-rules--* files on the next boot. So, long
as / is ro when the first udev script executes, though.
> 3. In 'udev' I noticed that appending '--timeout=3'
> to 'udevsettle' speeds up the boot considerably
> while not missing any devices in doing that.
> Obviously, the mileage may vary from "3" on
> another machine.
I don't recall exactly how udevsettle works, but if you specify a
timeout, that's exactly the maximum time udevsettle will run for. The
default is 180. Otherwise, udevsettle checks /dev/.udev/uevent_seqnum
and /sys/kernel/uevent_seqnum 20 times per second. It runs until the
value in /dev matches the value in /sys.
So, if it's much faster for you, then I don't think you've waited
until all the pending uevents have been processed. If you're curious,
you can set UDEV_LOG=info for udevsettle. This would show if the
timeout is reached or the queue is empty in syslog. If you don't
process all the events immediately, then it's entirely unknown whether
to proceed, although probably OK at that point.
More information about the lfs-support