On Wednesday 08 March 2017 05:04 AM, Philip Prindeville wrote:
[...]
Tried something like that:
root@PowercodeBMU:/# kexec -p /boot/vmlinuz --reuse-cmdline --append="irqpoll
maxcpus=1 reset_devices 1"
Cannot get kernel page_offset_base symbol address
That you can ignore.
Following patch will change this error message into warning:
http://lists.infradead.org/pipermail/kexec/2017-March/018299.html
Cannot load /boot/vmlinuz
Humm..can you pl run with -d and share debug output.
root@PowercodeBMU:/#
[...]
"crashkernel=" *must* *not* be passed to crash kernel. It is only for the
primary kernel.
Okay. And --reuse-cmdline takes care of stripping that out for you, it looks
like. That option isn’t discussed in Documentation/kdump/ but it might be
handy to add something about it.
You should see about it in kexec-tools doc.
man kexec
[...]
And assuming that you’re using the same kernel, etc. how does the init.d
scripting on the crashdump (2nd instance of the kernel) know that it’s not the
nominal kernel? Do we use /sys/kernel/kexec_loaded for this purpose? Or do we
just look for the existence of /proc/vmcore?
Yep, you can find /proc/vmcore in 2nd kernel but not in 1st kernel.
/sys/kernel/kexec_crash_loaded should have 1 in 1st kernel while 0 in crash
kernel.
So far I’m seeing the opposite:
root@PowercodeBMU:/# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz block2mtd.block2mtd=/dev/sda2,65536,rootfs,5
root=/dev/mtdblock0 rootfstype=squashfs rootwait console=tty0
console=ttyS0,115200n8r noinitrd crashkernel=64M
root@PowercodeBMU:/# cat /sys/kernel/kexec_crash_loaded
0
Because your kexec -p did not succeed yet.
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
