The Linux Kernel Oops website collects kernel errors from all over the World helping kernel developers finding issues occurring in the wild but they cannot help if no one sends reports to them.
The Kerneloops client used to be part of Debian releases but it has been removed from the archive due to not working with the new collector site.
When I started observing oopses on my machine I first thought of submitting a bug against the linux package in BTS, but looking at the numerous bugs opened already I looked for a more automated solution which would also help others. Reviving the kerneloops package involved switching it to the new submission URL, fixing a few memory allocation bugs in C (this is the first package I found using Valgrind by default for running tests) and ensuring that upstream was still active. The last step took the most of the time but finally Anton Arapov kindly accepted my patches and everything was set for the new upload.
The package is now available from unstable and if you feel so (especially if you experience oopses) please give it a try and report any problems you find. I’m also happy to receive success stories about oopses fixed after discovering and collecting them with the client. 🙂
Pingback: Links 26/10/2015: GUADEC 2016 Plans, Solus’ Budgie Desktop | Techrights
Sounds great! Please don’t forget to fuzz whatever is collecting that kernel oops. And whatever is processing it. It’s not fun to be owned through a malicious kernel oops 🙂
Hi Mate,
Kerneloops is shipped with all hardening features even with PIE and immediate binding which are enabled only critical software in Debian:
$ hardening-check /usr/sbin/kerneloops/usr/sbin/kerneloops:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes
Having it fuzzed would also be nice and if I can find time for that I’ll check it but probably not in the next weeks. If someone runs fuzz tests on kerneloops please copy me if it seems to be clean or report the issues to BTS/upstream.
Is there any chance for backport? I mean, can I get kernel-oops package from jessie-backports, please?
Sure, I plan backporting it but it needs some testing in unstable and testing first. Making the applet work with Gnome 3 would also be great before backporting it.
It took some time but now kernel-oops is available in jessie-backports, too.
So if I disable kernel-oops in Ubuntu 20.04 will it:
1. Collect the information and automatically send it without asking for permission
or
2. Not collect information and not send it because it’s not running?
If I disable it, I don’t want stuff sent without my knowledge.
Howto disable it ?