Hello, Le 22/01/2013 18:52, Stefan Bader a écrit : > On 01/21/2013 02:43 PM, Bouchard Louis wrote: > 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 >
Good to hear ! Turns out that there is nothing missing in Quantal, but rather a bug with makedumpfile that doesn't support the change of format of the kernel log buffer from byte-stream to variable-record format introduced in the 3.5 kernel. I'm working on an upstream patch on this change, already fixed in 'crash'. Then I will modify kdump-tools to make use of this functionality. Kind regards, ..Louis -- Louis Bouchard Backline Support Analyst Canonical Ltd Ubuntu support: http://landscape.canonical.com -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
