F20 System Wide Change: Enable kdump on secureboot machines

Vivek Goyal vgoyal at redhat.com
Thu Jul 11 18:13:05 UTC 2013


On Thu, Jul 11, 2013 at 11:58:56AM -0600, Stephen John Smoogen wrote:
> On 11 July 2013 05:40, Jaroslav Reznik <jreznik at redhat.com> wrote:
> 
> > = Proposed System Wide Change: Enable kdump on secureboot machines =
> > https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot
> >
> > Change owner(s): Vivek Goyal <vgoyal at redhat.com>
> >
> > Currently kexec/kdump is disabled on machines with secureboot enabled. This
> > feature aims to enable kexec/kdump on such machines.
> >
> > == Detailed description ==
> > /sbin/kexec prepares a binary blob, called purgatory. This code runs at
> > priviliged level between kernel transition. With secureboot enabled, no
> > unsigned code should run at privilige level 0, hence kexec/kdump is
> > currently
> > disabled if secureboot is enabled.
> >
> >
> My question is "Does kdump work even without secureboot?"

Yes it works. Kdump user space bits rotted for a while in Fedora and
it did not get enough care and attention. But things have changed now. 
We first put everything in Fedora and test it before we try to pull
the same bits in rhel.

> In trying to debug a crashing bug with older kernels and F19 I enabled kdump
> to try and
> get a crashing image for the developers to work. I ran into a ton of issues
> and when asking on #fedora-kernel was given the strong impression that
> kdump was not expected to work by the various kernel developers.

We have been testing F18 and F19 in our virtual machines and things work
for us.

I think this is a wrong impression. Kdump should work in Fedora. For a
long time I got the feedback that fedora users don't care about kdump
working. But I think kdump is an important debugging facility and is
very useful for enterprise distro. So at times it should be useful for
fedora users too.

So now I am trying to make sure things work well in Fedora.

> 
> 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.

> 2) kdump didn't seem to dump for anything than the forced dump in the
> instruction manual.

You mean dump did not trigger after panic or it did not complete after
panic?

If kdump kernel is loaded, and panic happens or oops happens and
panic_on_oops is set, we should transition in to second kernel and capture
dump.

If it did not work, there must have been some kernel issue. Please open
bugs for these issues.

> 
> In the end the kernel developers got me a kernel with enough oops detection
> to help find the problems but how do we get kdump to be more useful?

I think testing and bug reporting will help. I would love to have kdump
enabled by default in Fedora. But it eats around 128MB of memory by
default which keeps sitting and not used. So lot of people might not like
it.

Thanks
Vivek


More information about the devel mailing list