On Wed, Feb 11, 2015 at 12:39:48PM +0100, Karel Zak wrote:
[..]
I'm not sure if I good understand the original problem, but
I'm sure
that care about bind mounts is mistake ;-) If the problem is that
dump is not in the filesystem root then you can try to check if the
root of the filesystem is mounted somewhere else, but maybe the best
would be avoid such fragile setup at all.
Hi Karel,
So problem in a nutshell is figuring out where to dump the core when
second kernel boots. As we are in second kernel, we have lost all the
context of first kernel (including bind mount relations) and that means
we need to sort out all the information in first kernel and store it
so that kdump can parse it in second kernel.
Now what's the information we are looking for. Primarily we are looking
for what disk do we want to dump to and what path with-in disk we should
dump to.
For example, by default kdump dumps to /var/crash/ directory. Now one
could bind mount /var/crash to say /dev/foo[/foo-subdir]. Now the question
is when second kernel boots, where should we put crash dump.
Should it go in /var/crash of root disk or should it do in /foo-subdir of
/dev/foo disk?
In simple case we could say that we always put it in /var/crash of root
disk but one could argue that it should put it on /dev/foo disk in
foo-subdir.
To handle more complicated case, kdump script will have to have find a way
where given a path (/var/crash/ by default), it can traverse through whole
path, figure out what components are mounted/bind mounted where and finally
zoom on to final disk and path with-in disk and then ask dracut to mount
that disk.
Thanks
Vivek