This bug was filed against a series that is no longer supported and so
is being marked as Won't Fix. If this issue still exists in a supported
series, please file a new bug.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
It "just worked" after the upgrade. I didn't do any cleanup before the
upgrade to restore the system to a pristine state between the initial
installation of crashdump and the upgrade to 10.04, but I don't think I
really did anything but install the package.
--
You received this bug notification b
@ Rhomboid, did you have to change any configuration files to get
crashdump to work in 10.04, other than following the steps outlined on
the page:
https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Update: Upgrading to 10.04 seems to have fixed crash dumps, in that I
now get a core file and a .crash file gets made. Still working on the
actual crash but now I have something to work with.
--
linux-crashdump fails to record crash; reports memory not reserved
https://bugs.launchpad.net/bugs/321
I have tested the latest kernel 2.6.35-20-generic under Maverick Beta (on
2-core i686 virtual machine) with linux-crashdump installed. After "echo c >
/proc/sysrq-trigger", the system halts with a kernel panic:
[...] BUG: unable to handle kernel NULL pointer dereference at (null)
[...] IP: [] sys
Both the VM and native machines are one XFS filesystem (/).
--
linux-crashdump fails to record crash; reports memory not reserved
https://bugs.launchpad.net/bugs/321970
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mail
It was a while ago, and I didn't have time to finish looking at this,
but IIRC last I checked, the code in question seemed to make some
assumptions about the way the system was partitioned --- I think it
assumed everything was all in one big / partition. Is your VM
partitioned that way, but yo
I have 10 machines on dual core-i7 (amd64) with 16G RAM running 9.10.
They're randomly rebooting after months of stability with absolutely no
messages in the logs so I've assumed I've got a kernel panic and
installed linux-crashdump. I get no output in /var/crash, other than
once I had a log file t
Doesn’t work for me on Lucid amd64. I have 2 GiB of memory, and I have
crashkernel=384M-2G:64M,2G-:128M in /proc/cmdline, but the kernel
detects that I have ever-so-slightly less than 2 GiB of memory, and
therefore gives me a 64 MiB crashkernel:
[0.00] Reserving 64MB of memory at 32MB for
It may be obvious to some, but I should probably be more explicit in
pointing out that the test process I describe above triggers a dirty
shutdown, and can cause data loss if run on a system that contains
valuable data. Please run it on a test system where you don't mind
possibly losing data. (Of
I don't have time right now, but if someone want to see if this bug
still exists on Lucid, I think these are the steps:
1. apt-get install linux-crashdump
2. reboot
3. echo c > /proc/sysrq-trigger # triggers a kernel panic
4. Wait a bit for the system to collect the crash dump
The expected resul
I've not had any more kernel oops to test with. (The cause of the kernel oops
I saw was a hardware problem.)
I'm unlikely to figure out how to get upstream kernels to test this with.
--
linux-crashdump fails to record crash; reports memory not reserved
https://bugs.launchpad.net/bugs/321970
You
Hi Leigh,
This bug was reported a while ago and there hasn't been any activity in
it recently. We were wondering if this is still an issue? Can you try
with the latest development release of Ubuntu? ISO CD images are
available from http://cdimage.ubuntu.com/releases/lucid.
If it remains an issue
As more information regarding this, if you do as Nathaniel says above and use
the latest kexec-tools package with the "1...@16m" syntax, you can get past the
"Command line overflow" problem and load the crash kernel, but you may find
that when invoking the crash kernel you get a kernel OOPs in m
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
--
linux-crashdump fails to record crash; reports memory not reserved
https://bugs.launchpad.net/bugs/321970
You received this bug notification because you are a me
Fwiw, if I rebuild the kexec-tools package using the latest source in
jaunty (2009-2.0.0ubuntu3), kexec will get past the "Command line
overflow" problem and load the crash kernel, but the "crashkernel=384M-
2G:6...@16m,2G-:1...@16m" cmdline syntax still fails.
It almost looks like the intent
I'm seeing this too (also on intrepid; clean amd64 install in my cause,
though).
If I modify my grub config and change "crashkernel=384M-
2G:6...@16m,2G-:1...@16m" to "crashkernel=...@16m", kexec no longer
errors out with "please reserve memory ...".
I'm not familiar with that more complex crashk
** Attachment added: "dmesg.txt"
http://launchpadlibrarian.net/21686669/dmesg.txt
--
linux-crashdump fails to record crash; reports memory not reserved
https://bugs.launchpad.net/bugs/321970
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
18 matches
Mail list logo
