On Wednesday 08 March 2017 05:04 AM, Philip Prindeville wrote: > [...] > > Tried something like that: > > root at 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 at 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 at 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 at PowercodeBMU:/# cat /sys/kernel/kexec_crash_loaded > 0 Because your kexec -p did not succeed yet. ~Pratyush
