On 01/21/2013 02:43 PM, Bouchard Louis wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Le 10/01/2013 20:54, Stefan Bader a écrit :
At UDS we had a session about this [1] and I finally found some
time to write up that mail I really wanted to come up with a bit
sooner...
So right now the kernel-team produces the linux-crashdump
meta-package will will pull in kexec-tools and makedumpfile. The
kexec-tools package contains some init scripts which will create an
apport crash report from the memory dump taken by the kexec-crash
run and submits it.
For various reasons (see blueprint) we would like to move to use
kdump-tools and remove everything related to create dump files from
kexec-tools. So that package only provides means to use kexec.
Beside other changes this will initially cause the apport crash
reports no longer to be produced. But then the general question
was: do we really want them to be what they are today? If I have
not understood this wrong, we send several megabytes of memory dump
out, then on our side pull in even more megabytes of kernel debug
packages to look at the panic trace which comes from the dmesg
buffer which is only a tiny part of the core file.
So one outcome I would like to get from this discussion is to
understand better what parts and how exactly those memory dump
reports are used. I think apport will ask about sending it but not
sure whether is tells you that "by the way this is 20MB of data and
may contain sensitive information". I doubt the average user really
wants this, let alone business users.
My rough idea of how this could look in the end would be: - we
remove the dump functionality from kexec-tools - we replace the
kexec-tools dependency in linux-crashdump with kdump-tools -
kdump-tools would by default produce dumps but no reports (this
probably needs some thoughts about where to place those and how to
make sure they don't overflow the fs). - we can figure out a way to
extract information we need for reports locally and then only
report things with as little data as possible (maybe require a
setting to enable this).
One option to extract some reporting information could be to extract
the content of the dmesg in a separate file and include only this in
the apport report.
makedumpfile has a --dump-dmesg option that can do that in a separate
pass. While this works well on Debian, it fails on Quantal so maybe
some more information might be needed in our kernel to achieve this.
Only a few more lines are required in /usr/sbin/kdump-config which is
part of the kdump-tools package. If this sounds reasonable, I will
investigate our kernel requirement so this can work on Ubuntu as well.
Any comment ?
After talking to Evan today, this (extracting dmesg) would be the right thing to
do there. In a second step this would then get piped into something that creates
some reporting. I will look into extracting the useful pieces of that from
kerneloops. So if you can look into what is missing in Quantal, that would be
great. I will let you know how to cause the reports as soon as I got that piece
ready.
-Stefan
Kind Regards,
...Louis
- --
Louis Bouchard
Backline Support Analyst
Canonical Ltd
Ubuntu support: http://landscape.canonical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD9VA4ACgkQDvqokHrhnCzn3gCg9R5UrxNnI93wjaKvOvMzFKs8
/qEAoLOkO17o7QX1DvA+wG3U6w3z2W/k
=7xoP
-----END PGP SIGNATURE-----
--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
