On Thu Jan 6 2011 09:24 PM, William Immendorf wrote: > Intriguing. This is something that you should report to both > LKML and linux-hotplug (the Udev list). > Also, be sure to provide the kdump of that kernel, the log, > and the hardware that you think is causing the Udev issue.
Hi William, First, apologies for getting back to you so late. I deduce you are familiar with Kdump _and_ (B)LFS so maybe you can help me further, beyond sending me to LKML and Udev list (anybody can obviously chime in here with their thoughts): In a nutshell, the basic functionality of a Kdump is, as we all know, for the second,"dump-capture" kernel to boot as soon as the first, "system" kernel, crashes and then to capture the preserved memory of the first (crashed) system and write it somewhere for later analysis. So far so good. On an (B)LFS system I see two problems (issues, as they say): 1. On boot, the "dump-capture" kernel goes through the same steps as the original (system) kernel (mountkernfs, modules, UDEV, swap ...), finds a "corrupt" file system, fsck's it and then re-reboots into the first, bad, system, and all is lost. 2. In a particular situation like mine (as described in the intro to this thread), the crash happens early in the boot (at UDEV activation) which makes the possible interaction between the crashing system and dump-capture one even more intriguing. As an aside, I suspect these two complications may have something to do with the (B)LFS procedures seemingly not covering the system crashes. Thanks, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
