On 11 July 2013 13:10, Vivek Goyal <vgoyal(a)redhat.com> wrote:
On Thu, Jul 11, 2013 at 12:42:16PM -0600, Stephen John Smoogen
wrote:
[..]
> > > Issues I ran into was:
> > >
> > > 1) kdump needs to write to an unencrypted disk space. I tried a USB
disk
> > > and various other places but the best ability I got was reinstalling
the
> > > laptop and making a /var/crash partition.
> >
> > Is your root encrypted? USB should have worked. Otherwise try dumping
> > to NFS partition. Or ssh the dump out to a different machine. All of
> > these should work.
> >
> >
> The USB was the ones I tried but couldn't get to work correctly. NFS and
> SSH were not going to work because the problem is with RHEL-5 talking
over
> the bridge and my laptop has wireless.
[ I am ccing devel list again. So that if people have ideas about how
to get serial console on laptop, that will help ]
What do you mean by "NFS and SSH were not going to work because the problem
is with RHEL-5 talking over the bridge"?
Well the system hard crashes the laptop when I am on wireless. I expect
that this is an untested scenario and since most of the time I am sitting
on some cafe's wireless trying to push 8 GB of dump to somewhere would not
be the most useful way to try.
I have never tested kdump with wireless. As I always tried to make
these
work on servers and always assumed etherhnet connectivity is there.
Anyway, USB case is interesting. I have to admin I have never tried
dumping to USB disk either. But in theory it should work.
I tried USB direct dump and USB ext3. kdump said it could see the USB disk
in the logs and then nothing would get written.
Right now it does not work with encrypted disks. Given the fact that
dumping to root disk is easiest on a laptop, I think it is reasonable
to try to make it work with encrypted disks.
I really can't see a way to do encrypted disks in a secure way. Basically
everything I thought of required it have the password stored somewhere
which is wrong on many levels. So I don't mind having to have an
unencrypted space.
> This did not happen. The system froze completely.
We need to have serial console to debug things here. Without console we
have no idea where things might have gone wrong.
Sadly the laptop is USB only so I am not sure if this will be possible. I
will defer to someone with a lot more hardware knowledge but I was under
the assumption that unless I had a UART any console hooked up would really
be a "software" versus "hardware" console and so data sent to it went
through a lot of corruptible stacks :/. [Ah for a nice old x86 with UART.]
--
Stephen J Smoogen.