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