The system just crashed once again with the 2.6.32-22-generic (linux-image-2.6.32-22-generic 2.6.32-22.33) kernel.
When the kernel crashes, the system is rebooted (kexec? -- probably due to the kerneloops stuff I installed), but then only has 64 MiB of RAM, which is probably due to what kerneloops did to grub.cfg:
linux /vmlinuz-2.6.32-22-generic root=/dev/mapper/vg0-dirichlet--root ro crashkernel=384M-2G:64M,2G-:128M quiet splash
What am I supposed to be doing when this happens? Logging into the Gnome UI with 64 MiB of RAM took me some hours (...) a week ago, and then nothing was submitted automatically. Running kerneloops / kerneloops-applet / kerneloops-submit manually, and letting it run for some minutes didn't have any observable effect either.
I'm now switching to the mainline kernel build linux-image-2.6.34-020634-generic 2.6.34-020634 and will report back if I'm still seeing this -- which is difficult, of course, as the crash only happens every few days / weeks.
The system just crashed once again with the 2.6.32-22-generic (linux- image-2. 6.32-22- generic 2.6.32-22.33) kernel.
When the kernel crashes, the system is rebooted (kexec? -- probably due to the kerneloops stuff I installed), but then only has 64 MiB of RAM, which is probably due to what kerneloops did to grub.cfg:
linux /vmlinuz- 2.6.32- 22-generic root=/dev/ mapper/ vg0-dirichlet- -root ro crashkernel= 384M-2G: 64M,2G- :128M quiet splash
What am I supposed to be doing when this happens? Logging into the Gnome UI with 64 MiB of RAM took me some hours (...) a week ago, and then nothing was submitted automatically. Running kerneloops / kerneloops-applet / kerneloops-submit manually, and letting it run for some minutes didn't have any observable effect either.
I'm now switching to the mainline kernel build linux-image- 2.6.34- 020634- generic 2.6.34-020634 and will report back if I'm still seeing this -- which is difficult, of course, as the crash only happens every few days / weeks.