On Saturday 08 January 2011 13:44:23 al...@verizon.net wrote: > On Thu, 2011-01-06 at 02:08 AM, Simon Geard wrote: > > ... udevd supports a couple of options that might help, --debug and > > --debug-trace. > > 1. FWIW, udevd-165 does not (no-longer?) have a "--debug-trace" option. > Maybe it's undocumented now (shades of "Undocumented DOS" of yore :) > Please see 'man udevd'. > > 2. For argument sake, udevd writes to sys.log and daemon.log > (identically). > > There are a few things that intrigue me (which might help in my > non-kdump troubleshooting, if answered positively): > > 2.1. Udevd is active way before the main partition becomes read-WRITE > (stemming from a chicken and egg situation, I suppose). > Be that as it may, where's the mechanism that writes the accumulated > udevd log from memory(?) to disk (/var/log/) ultimately (i.e. delayed)? > > 2.2. Can udevd (syslogd?) output be originally redirected to a different > partition where it can go instantaneously, so I can find it postmortem > and deduce the hardware element that bothers Udev? > syslogd started early for this test, etc. > > 2.3. More simplistically, can I temporarily mount the main partition > writable as soon as Udev discovers it and somehow start syslogd? > As I mentioned, the crash occurs a few "lines" before the end of Udev run, > i.e. long after Udev "sees" the partitions. > Would syslogd start writing udevd output to disk immediately? > That would involve creating an appropriate rule with some action in it, > etc. Maybe splitting the udevd logic in two phases..., etc. > > I'd appreciate your thoughts. > If 2.1-3 above too crazy, please disregard with my apologies.
While I was integrating udev into my test/dev version of Smoothwall, I had to go through some 'contortions' when the system was in early boot (running in the initramfs). At this point, syslogd is not running and there is no hard drive available; logging is pretty much WYSIWYG. What follows is 'generic' Linux boot processes and may not mesh well with how LFS is actually booted. You may have to get your hands *really* dirty. You can modify the initramfs image (unpack it, modify it, repack it, reboot) by changing its init script to direct udev's STDOUT and STDERR to a file (in the tmpfs, of course). After udev runs (in the initramfs' init script), you can run a shell to examine the file. The bootup process will be suspended until you exit the shell. But you say 'the crash'. If the system is crashing (I, red-facedly, haven't paid attention), then you might try populating the initramfs' /dev with device nodes for your hard drive and modifying the initramfs' init script to mount the hard drive. Then run udev as verbosely as possible and redirect its stdout and stderr to a file on the hard drive. Be warned that playing in initramfs (early boot) is almost a black art. Things we take for granted, like standard TTY features, standard device nodes, and ordinary debugging tools may not exist. It's not as limiting as having only 18 toggles on the front panel, but it's still a bother. If you are truly desperate, you can always put the entire LFS / tree into the initramfs image. It'll be slow to unpack, but you'll have all the tools at your fingertips. You *will* need a lot of RAM to do this, though. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
