Jozsef Kadlecsik wrote: >>> Just as a last resort. But the problem is so strange, I can't recall any >>> patch related to such a behaviour. >> Unfortunately, I just tried a kernel upgrade (which pulled in a new libc6) >> which totally hosed my RAID/LVM. It took me the better part of the evening >> to get the RAID working again on the old kernel, so now I'm quite wary of >> further kernel upgrades until/unless I figure out what happened there. > That can happen, unfortunately. It'd be good to know the kernel version, > however, which caused the problem with RAID/LVM. I was using 2.6.8 from Debian stable; the upgrade to 2.6.14 hosed the LVM. RAID actually was fine according to /proc/mdstat, but LVM was segfaulting on vgscan, which as far as I could tell was more of a sympton than the real problem. But I couldn't figure it out, and when I returned to 2.6.8, it still didn't work. After some combination of bringing the RAID up and down, flushing the LVM cache file, running the vg* tools, etc., it finally came back up, although I can't really tell you why. >> So are there no diagnostics, absent rebuilding with netfilters debugging on, >> for tracing a packet in between mangle PREROUTING and nat PREROUTING? > Without further aid, no. Okay, so I've rebuilt 2.6.8 with NETFILTER_DEBUG=Y. What would be the next step? From what I can tell, NETFILTER_DEBUG isn't something turned on and off in /proc/net or /proc/sys/net, it just is "on," but I'm not quite sure what sort of debug messages we should be trying to get and how. -- Adam Rosi-Kessel http://adam.rosi-kessel.org
Attachment:
signature.asc
Description: OpenPGP digital signature
